book-notes

Pro Git

from http://progit.org/book/

Chapter 1: Getting Started

In distributed version control systems, clients don’t just check out the latest copies of files, but fully mirror the repository.
When you commit, or save the state of your project in Git, it takes a snapshot of all files instead of computing their differences.
The entire project history is saved locally, so most operations in Git need only local resources and work quickly.
The working directory is a checkout of one version of the project; these files are pulled out of the compressed git directory, or repository.
A staged file is modified in the working directory and marked as part of your next commit snapshot to the git directory.

Chapter 2: Git Basics

Tracked files were in the last snapshot; untracked files are everything else, or files not in your last snapshot or staging area.
The add command tracks and stages an untracked file, and stages a tracked and modified file, overwriting any staged copy.
Running diff shows what you’ve changed but not yet staged; adding --staged shows what you’ve staged and will commit next.
Running diff compares files in the working directory with their staged copies, not those in the repository.
Passing --cached to rm only removes a file from staging, so it is untracked; omitting it also removes the file from the working directory.
The --stat option for log shows summarized diff stats for files; --graph shows branch and merge history and is useful with --pretty.
To limit the output of log to specific files and paths, append them to the command, preceded by a double dash.
Run commit with --append to overwrite your last commit; without adding any files, you will simply overwrite your commit message.
The fetch command doesn’t merge new data with your own; git pull will try to automatically merge, and works if you’ve run clone.
When running git push origin master, origin is the server to push to, and master is the branch to push.
Annotated tags are recommended over lightweight tags; they’re stored as full objects, are checksummed, and include a message.
If you forget to tag immediately after a commit, specify the commit checksum or its unique prefix at the end of the command.

Chapter 3: Git Branching

The git branch command creates a new brach, but the HEAD pointer does not refer to the new branch until you use checkout.
To create a branch and switch to it at the same time, run the checkout command with the -b option.
Without a clean working state when switching branches, conflicts may arise; using stash and commit amending can help.
If a conflict arises while merging, you must manually edit the file and then use add to put it in the staging area.
It is safe to delete unstarred branches listed by git branch --merged; branches listed by --no-merged cannot be deleted yet.
Topic branches are short-lived branches you create and use for a single particular feature or related work.
Remote branches refer to the state of branches on remote repositories, which move upon any network communication.
A fetch retrieves new remote branches as read-only pointers prefixed with origin/, which you manually merge to make editable.
Tracking branches are local branches directly associated with a remote branch, so git pull and git push work without arguments.
Using rebase replays changes from one line of work onto another, so the log will show a linear history instead of a parallel one.
Don’t rebase commits that you’e pushed to a public repository, as others will base work on commits that you’ve rebased.

Chapter 6: Git Tools

Passing --abbrev-commit to the git log command will use unique SHA-1 prefixes in the output.
The reflog only contains changes to your local repository; after you’ve cloned a repository, your reflog will initially be empty.
Using ^{n} a the end of a reference refers to its nth parent; using ~{n} traverses n parents up the ancestry tree.
The double-dot shows commits only reachable by the latter reference; the triple-dot shows reachable by either, but not both.
Running git add in interactive mode with -i and selecting 5 or p allows staging parts of files; when done, use git commit.
The stash command takes the dirty state of your working directory and saves it on a stack of unfinished changes you can reapply later.
To restage files that were staged when you created a stash, run stash apply with the --index option.
Using stash branch branches from the commit you were on when you stashed your work, then applies and drops the stash.
Amending a commit is like a very small rebase, so don’t amend your last commit if you’ve already pushed it.
To modify a commit farther back, run rebase in interactive mode to rebase them onto the HEAD they were originally based.
The filter-branch command allows rewriting your history easily, but don’t use it if other people have based work off those commits.
Passing -C to blame tries to figure out where snippets of code within the file came from if they were copied from elsewhere.
After you run bisect, don’t forget to run bisect reset to reset your HEAD to where you started, or you’ll end up in a weird state.
Submodules are recorded as the exact commit they’re at; this way, the environment an be recreated exactly.
Subtree merging maps one project as a subdirectory of the other and vice versa, and fixes many problems of submodules.
To get a diff between the branch of a subproject and the superproject it’s merged into, you must run diff-tree instead of diff.

Chapter 9: GIt Internals

Low-level git commands are called the plumbing commands; those you use at the command line are porcelain commands.
Git stores trees and blobs; a tree contains blob or subtree entries, where each entry has a mode, type, and filename.
Trees capture the content of your staging area or index; commits annotate a tree with who saved the snapshot, when, and why.
References or refs are files that store SHA-1 values of commits; HEAD isn’t another SHA-1 value, but a reference name.
The tag object is like a commit object, containing a tagger, date, message, and pointer, but points to a commit and not a tree.
While files are normally stored in a “loose object format,” pack files that contain delta values are created occasionally.
All references under refs/heads on the server are written to refs/remotes/origin locally; branches can be qualified with the latter.
A refspec mapping remote branches to local references cannot have partial globs, but namespacing achieves the same ends.
If you reset and lose commits, the reflog tracks changes to HEAD, so branching from a reflog entry can surface them again.
Deleted large files still take up space because the entire history is stored; amending this is destructive to your commit history.