These are my notes from reading Scott Chacon’s Pro Git
I highly suggest buying this book if you are serious about using the Git version control tool.
A branch in Git is simply a lightweight movable pointer
a special pointer called HEAD…is a pointer to the local branch you’re currently on
Creating a new branch is as quick and simple as writing 41 bytes to a file (40 characters and a newline).
To create a branch and switch to it at the same time…git checkout command with the -b switch
To see the last commit on each branch, you can run git branch -v
git checkout -b [branch] [remotename]/[branch]
is the same as
git checkout --track [remotename]/[branch]
Git protocol…listens on a dedicated port (9418)
The Git protocol is the fastst transfer protocol available.
The Git project provides a document that lays out a number of good tips for creating commits from which to submit patches—you can read it in the Git source code in the Documentation/SubmittingPatches file.
git log --no-merges origin/master ^issue54
Compare origin changes with local changes before merging:
git log origin/featureA ^feature
git merge --no-commit --squash featureB
git apply
It’s almost identical to running a patch -p1 command to apply the patch, although it’s more paranoid and accepts fewer fuzzy matches then patch.
git apply --check
check to see if a patch applies cleanly before you try actually applying it
git log contrib --not master
To find common ancestor of both branches
git merge-base contrib master
git diff [sha1 from previous command]
git diff master...topic
shows you only the work your topic branch has introduced since its common ancestor with master.
tagging releases with signed keys
generating a build number with your tags
preparing a release as a tarball
Show work by author since a specific time
git shortlog --no-merges master --not v1.0.1
Git can figure out a short, unique abbreviation for your SHA-1 values
git log --abbrev-commit --pretty=oneline
wolves paragraph
Find out the SHA1 of a branch
git rev-parse [branch]
To see reflog information inline with your normal log information
git log -g master
Because reflog is a log, it will show you where the HEAD pointer was 2 months ago – if the repo is older than that
git show HEAD@{2.months.ago}
^ is the first parent of the current commit ^2 is the second parent of the current commit (only works if the current commit is a merge commit, where first parent is the branch you on when you merged, second was the other) ~ is the first parent ~2 (or any number) is the grandparent(s) of the current commit only on the current branch or branch you were on when you merged
Shows you any commits in your current branch that aren’t in the master branch on your origin remote
git log origin/master..HEAD
Git substitutes HEAD if one side is missing (git log origin/master..)
Just like above command and example shown on pg134
git log refB --not refA
Tells the stash command to try to reapply the staged changes
git stash apply --index
Create a branch from a stash, testchanges
git stash branch testchanges
…don’t amend your last commit if you’ve already pushed it (git commit —amend command)
git rebase -i HEAD~3
Don’t include any commit you’ve already pushed to a central server—doing so will confuse other developers by providing an alternate version of the same change
It’s important to note that these commits (interactive rebase) are listed in the opposite order (oldest first, newest last) than you normally see then using the log command (newest first).
…make sure no commit shows up in that list (git log -4 —pretty=format:“%h %s”) that you’ve already pushed to a shared repository
was wondering how to automate the good/bad declaration
git submodule update You have to do this every time you pull down a submodule change in the main projects. It’s strange, but it works.
You want to pull the Rack project into your master project as a subdirectory
git read-tree --prefix=rack/ -u rack_branch
global git config /etc/gitconfig
user global git config ~/.gitconfig
local repository git config .git/config
git config --global core.autocrlf input
This setup should leave you with CRLF endings in Windows checkouts but LF endings on Mac and Linux systems and in the repository
To tell Git to treat a specific file as binary data, add the following line to your .gitattributes file: *.extension -crlf -diff
…one of the most annoying problems known to humanity: version-controlling Word documents (LOL)
post-receive hook…This scripts can’t stop the push process, but the client doesn’t disconnect until it has completed; so, be careful when you try to do anything that may take a long time
Is practically the git log command…it prints out only the SHA-1 values and no other information
git rev-list [SHA-1]..[SHA-1]
Get the commit message from each of these commits to test
git cat-file commit [SHA-1]
Incantation:
git cat-file commit [SHA-1] | sed '1,/^$/d'
See what files have been modified in a single commit
git log -1 --name-only --pretty=oneline:'' [SHA-1]
anything your script prints to stdout will be transferred to the client
pg 200
Get your file listing from the staging area
git diff-index --cached --name-only HEAD
Git is a content-addressable filesystem
hash-object (plumbing command)
Pull the content back out of Git
git cat-file -p [SHA-1]
Git will tell you what type of object it is [blob, tree, tag, commit]
git cat-file -t [SHA-1]
Git compresses the new content with zlib
Thanks for the compilation!
Ricardo: You’re welcome
You’ve convinced me to buy this book now.
@Simon:
Awesome. It’s worth it’s weight in gold.