Book: Pro Git
- Read: March 2012
- Rating: 9.0/10
Pro Git by Scott Chacon is the best way to really learn Git. Scott has obviously been using Git for a very long time, and he knows the internals, backwards and forwards. If you don’t know the difference between rebase and merge or when to use what command, then you should read this book. Knowing how to use your tools to the best of your ability is incredibly important, and Git is no exception. The book can also be read free online at: http://progit.org/book/.
I’m not really going to get into the pros/cons or the history of Git here, mostly just technical notes. Feel free to check out “why Git is better than X”:http://whygitisbetterthanx.com/ if you’re interested in pros/cons.
Setting up Git:
Modify configuration file:
- ~/.gitconfig OR .gitconfig in $HOME on Windows
git config --global user.name "David Parker"
git config --global user.email firstname.lastname@example.org
git config --global core.editor emacs
git config --list
Any of the following commands work:
git help <verb>
git <verb> --help
Creating a repository:
Cloning a repository:
git clone <url> <optional different directory>
git clone https://github.com/davidwparker/opengl-3defense.git <optional different directory>
- This will clone a git repository into your working directory in directory opengl-3defense
- Or add a different directory by adding the directory name after the
Checking the status of files:
Lifecycle (status) of files:
- untracked | unmodified | modified | staged
untracked => add => unmodified
unnmodified => remove => untracked
unmodified => edit => modified
modified => stage => staged
staged => commit => unmodified
git add <filename>OR
git add *.<type>
Commit new files:
git commit -m 'inline commit message'
- A staged file is a file that has previously been committed and has since been changed.
Commit staged files:
- Same as commit new files
- touch .gitignore
The rules for the patterns of what can be in the .gitignore file:
- Blank lines or lines starting with # are ignored
- Standard glob patterns work
- You can end patterns with a forward slash (/) to specify a directory
- You can negate a pattern by starting with an exclamation point (!)
- git diff is used for multiple reasons, but the most common is to see what has changed but not yet staged.
git diff --staged
- If you’ve added files to staging, and you’d like to see what the diff of those changes, simply use the following:
git rm <file>
- Note that the file is removed from the filesystem as well (can be kept with —cached flag)
git mv <file> <newfile>
- This is the same as running the commands: git rm —cached orig; mv orig new; git add new
- By default, git log lists commits in a repository in reverse chronological order.
Other awesome logging stuff:
- —pretty=format:“YOUR FORMAT”
- Very powerful way to specify own log output format
- -p = shows diff introduced in each commit
- -# = shows only the last # commits.
- —oneline = shows commits one one line
git log --oneline
- many, many more!
Changing last commit:
git commit --amend
Unstaging a staged file:
git reset HEAD <filename>
Unmodify a modified file:
git checkout -- <filename>
- Warning: this overwrites the file, so you will lose any changes that you made. You sparingly.
Working with remote:
- You can also see the URL git has stored:
git remote -v
git remote add <shortname> <url>
git remote add origin email@example.com:davidwparker/git.git
git push <remote name> <branch name>
git push origin master
- Pushing will be rejected if someone else has since pushed upstream
git fetch origin
- Fetching from a remote will pull down data you don’t have yet.
- It pulls the data into your local repository, but it doesn’t automatically merge it with any of your work, or modify what you’re currently working on.
git remote rename <old> <new>
- You can easily rename a remote
git remote rm <name>
- Or remove a remote
- Tagging allows Git to forever remember a snapshot of a repository.
- There are two types of tags in Git:
- Lightweight: a pointer to a specific commit
- Annotated: full objects in the Git database
- It is recommended to use annotated tags.
git tag -a <tagname> -m 'a message'
git tag -s <tagname> -m 'a message'
- This uses GPG (GNU Privacy Guard)
- The GPG signature can be seen using:
git show <tagname>
You can verify a signed tag as long as you have the signer’s public key:
git tag -v <tagname>
git tag <tagname>
- This will create a lightweight tag. Lightweight tags cannot use the -a, -s, or -m flags.
git log --pretty=oneline
- If you forgot to tag, you can check your commits with:
git tag -a <tagname> <checksum>
- And then tag using the checksum:
- Tags aren’t pushed when doing a push, you need to specify them
git push origin <tagname>
git push origin --tags
- Use the latter to push all tags
- One of Git’s most powerful features is its branches.
- Git’s branches are incredibly lightweight, and it is nearly instantaneous to switch back and forth between branches.
- Git encourages a workflow that branches and merges often, even multiple times a day.
- A realistic workflow may be as follows:
- Working on an app
- Create a branch for a story you’re working on
- Do some work
- Then, you get a call for critical hotfix needed:
- Revert back to production branch
- Create branch for hotfix
- Test hotfix and merge the branch, push to production
- Switch back to original story and continue work
Creating a branch:
git branch <branch name>
- This creates a pointer to the same commit you’re currently on.
git checkout <branch name>
Checkout a branch when creating:
git checkout -b <branch name>
git branch -d <branch name>
Merging branches (fast forward):
git merge <branch name>
- If you don’t edit a branch, and then merge another branch where you have changed things, then Git performs a fast forward.
- If you do edit a branch, and then merge another branch where you also have made edits, then Git performs a three-way merge: the common ancestor snapshot, the merged branch, and the merging branch.
- If you edit a branch, and attempt to merge another branch where you have edited the same part of the same file, you may end up with a conflict.
- You can see what has changes with git status
- Open this file in your editor and you can see where the conflict is:
- Changes made in HEAD are above ======= and changes made in branch are below.
- After you change the file as you like, remove thing
<<<<<<<, =======, and >>>>>>>lines, then you can add the file normally with git add.
- Now that we have merged, if we do a log, we can actually see the branches (in ASCII, on the left):
git log --pretty=oneline --graph
You can easily see what branches you have already merged with your current branch:
git branch --merged
Or not merged:
git branch --no-merged
- Remote branches work similarly to local branches, except that they take the form
- In general, you must remember to
git fetchfrom remote to get the latest.
- From there, you don’t get that work in your working directory, but you can merge it with
git merge origin/<new branch>
- And you must
git pushto push the latest to the remote repository.
Rebasing is another tool that allows you to integrate changes from one branch to another.
Rebasing allows you to take all the changes that were committed on one branch and replay them on another branch.
At this point, you can go back to master and fast forward.
git checkout rebased
git rebase master
git merge rebased
The most often usecase for rebase is to make sure your commits apply cleanly to a remote branch.
Rebasing is great for cleaning up when you have made a ton of ‘unnecessary’ commits.
If you follow the previous workflow, you’ll be ok.
Otherwise, a warning: do not rebase commits that you have pushed to a public repository.
When you rebase, you’re abandoning existing commits and creating new ones that are similar but different.
Only rebase commits that you haven’t push publicly.
Git on the Server:
- To run a Git server, all you need is to choose protocols you want your server to communicate with:
There’s much more on specific Git tools, including revision selection, interactive staging, stashing, rewriting history, debugging, submodules, subtree merging, Git configuration, Git attributes, and Git hooks, which I won’t be blogging about here. I personally don’t use a lot of these (right now), with the exception of stashing.
The chapter on Git internals is also very interesting, which discusses plumbing and porcelain, Git Objects, Git References, packfiles, and more. It’s also worth checking out if you’d like to see what the git commands are really doing.
In all, I can’t recommend the book enough, especially for those interested in, or those who use but don’t really understand, Git.