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.
pg 48
A branch in Git is simply a lightweight movable pointer
pg 50
a special pointer called HEAD…is a pointer to the local branch you’re currently on
pg 52
Creating a new branch is as quick and simple as writing 41 bytes to a file (40 characters and a newline).
pg 53
To create a branch and switch to it at the same time…git checkout command with the -b switch
pg 61
To see the last commit on each branch, you can run git branch -v
pg 69
git checkout -b [branch] [remotename]/[branch]
is the same as
git checkout --track [remotename]/[branch]
pg 81
Git protocol…listens on a dedicated port (9418)
pg 82
The Git protocol is the fastst transfer protocol available.
pg 111
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.
pg 116
git log --no-merges origin/master ^issue54
pg 121
Compare origin changes with local changes before merging:
git log origin/featureA ^feature
pg 126
git merge --no-commit --squash featureB
pg 130
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.
pg 131
git apply --check
check to see if a patch applies cleanly before you try actually applying it
pg 134
git log contrib --not master
To find common ancestor of both branches
git merge-base contrib master
git diff [sha1 from previous command]
pg 135
git diff master...topic
shows you only the work your topic branch has introduced since its common ancestor with master.
pg 140
tagging releases with signed keys
pg 141
generating a build number with your tags
preparing a release as a tarball
pg 142
Show work by author since a specific time
git shortlog --no-merges master --not v1.0.1
pg 144
Git can figure out a short, unique abbreviation for your SHA-1 values
git log --abbrev-commit --pretty=oneline
wolves paragraph
pg 145
Find out the SHA1 of a branch
git rev-parse [branch]
pg 146
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}
pg 147
^ 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
pg 148
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
pg 155
Tells the stash command to try to reapply the staged changes
git stash apply --index
pg 156
Create a branch from a stash, testchanges
git stash branch testchanges
pg 157
…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
pg 158
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).
pg 160
…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
pg 164
was wondering how to automate the good/bad declaration
pg 168
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.
pg 172 (subtree merging)
You want to pull the Rack project into your master project as a subdirectory
git read-tree --prefix=rack/ -u rack_branch
pg 175
global git config /etc/gitconfig
user global git config ~/.gitconfig
local repository git config .git/config
pg 182
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
pg 184
To tell Git to treat a specific file as binary data, add the following line to your .gitattributes file:
*.extension -crlf -diff
pg 185
…one of the most annoying problems known to humanity: version-controlling Word documents (LOL)
pg 192
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
pg 194
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'
pg 196
See what files have been modified in a single commit
git log -1 --name-only --pretty=oneline:'' [SHA-1]
pg 198
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
pg 224
Git is a content-addressable filesystem
hash-object (plumbing command)
pg 221
Pull the content back out of Git
git cat-file -p [SHA-1]
pg 226
Git will tell you what type of object it is [blob, tree, tag, commit]
git cat-file -t [SHA-1]
pg 231
Git compresses the new content with zlib
Posted
Apr 05 2010, 12:17 AM
by
Jason Meridth