Skip to content

Latest commit

 

History

History
68 lines (61 loc) · 6.83 KB

pro-git.markdown

File metadata and controls

68 lines (61 loc) · 6.83 KB

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.