git is a version control system that allows you to track changes in a code base, referred to as a repository. With git, collaboration/coding becomes infintely times smoother.
Once you commit a file then you can always go back to it if you should want to do so!
Some common arguments one would add to git when using the command line is as follows:
Undo "local" changes
Reset "local" changes
When working in github, you can copy a repository to your suite of repos by 'forking the repo'
submitting a pull request to a user means to ask the user to merge changes you made into his repo
When you want to help with the code you would generally do the following:
When would you want to use a remote repository rather than keeping all your work local?
There are many reasons for this, among the most common I've found to be are:
Why might you want to always pull changes manually rather than having Git automatically stay up-to-date with your remote repository?
You might want to make conflicting changes to code.
Describe the differences between forks, clones, and branches. When would you use one instead of another?
What happens when you initialize a repository? Why do you need to do it?
Tells git to track files/subdirectories in that directory
How is the staging area different from the working directory and the repository? What value do you think it offers?
Gives you a chance to confirm files you want to commit to repository.
How can you use the staging area to make sure you have one commit per logical change?
Commit one file at a time, with unique commit message for each update
What are some situations when branches would be helpful in keeping your history organized? How would branches help?
Branches give you the freedom to experiment with new features for your code. Once you test a feauture effectively you can merge it to main branch with no 'garbage' commits.
How do the diagrams help you visualize the branch structure?
The diagrams tells you what are 'unreachable' commits ie. which commit belongs to a different branch entirely.
What are the pros and cons of Git’s automatic merging vs. always doing merges manually?
Git will prevent future commits if there is an unresolved merge conflict. This ensures less mistakes.
How did viewing a diff between two versions of a file help you see the bug that was introduced?
Git diff shows the changes made, similar to unix's diff but much more powerful. If previous commit was stable you can see all the changes you made to spot the error.
How could having easy access to the entire history of a file make you a more efficient programmer in the long term?
Good for debugging, going back to previous working versions of code. Git encourages creating new features with these safety features.
What do you think are the pros and cons of manually choosing when to create a commit, like you do in Git, vs having versions automatically saved, like Google docs does?
Why do you think some version control systems, like Git, allow saving multiple files in one commit, while others, like Google Docs, treat each file separately?
Git is created to track changes for bigger projects.
How can you use the commands git log and git diff to view the history of files?