Pro Git

by Scott Chacon

Version control is a system that records changes to a file or set of files over time so that you can recall specific versions later.

Using a VCS also generally means that if you screw things up or lose files, you can easily recover. In addition, you get all this for very little overhead.

Git thinks of its data more like a set of snapshots of a miniature filesystem.

Git thinks about its data more like a stream of snapshots.

This makes using Git a joy because we know we can experiment without the danger of severely screwing things up.

Git has three main states that your files can reside in: committed, modified, and staged. Committed means that the data is safely stored in your local database. Modified means that you have changed the file but have not committed it to your database yet. Staged means that you have marked a modified file in its current version to go into your next commit snapshot.

For example, to correct the usability problem you encountered with unstaging a file, you can add your own unstage alias to Git: $ git config --global alias.unstage 'reset HEAD --' This makes the following two commands equivalent: $ git unstage fileA $ git reset HEAD fileA

Tracking branches are local branches that have a direct relationship to a remote branch.

There is no difference in the end product of the integration, but rebasing makes for a cleaner history. If you examine the log of a rebased branch, it looks like a linear history: it appears that all the work happened in series, even when it originally happened in parallel.

Do not rebase commits that exist outside your repository.

Rebase When You Rebase

If you rebase commits that have already been pushed publicly, and people may have based work on those commits, then you may be in for some frustrating trouble, and the scorn of your teammates.

run git diff --check, which identifies possible whitespace errors and lists them for you.

When you’re thinking of integrating new work, it’s generally a good idea to try it out in a topic branch—a temporary branch specifically made to try out that new work.

git diff master...contrib

Now you want to release a build. One of the things you’ll want to do is create an archive of the latest snapshot of your code for those poor souls who don’t use Git.

Most GitHub projects think about Pull Request branches as iterative conversations around a proposed change, culminating in a unified diff that is applied by merging.

fetch = +refs/heads/*:refs/remotes/origin/* fetch = +refs/pull/*/head:refs/remotes/origin/pr/*

For more information on how to write webhooks and all the different event types you can listen for, go to the GitHub Developer documentation at: https://developer.github.com/webhooks/

git stash show -p stash@{0} | git apply -R

git config --global alias.stash-unapply '!git stash show -p | git apply -R'

Put the following line in your .gitattributes file: *.docx diff=word This tells Git that any file that matches this pattern (.docx) should use the “word” filter when you try to view a diff that contains changes. What is the “word” filter? You have to set it up. Here you’ll configure Git to use the docx2txt program to convert Word documents into readable text files, which it will then diff properly.

Client-side hooks are triggered by operations such as committing and merging, while server-side hooks run on network operations such as receiving pushed commits.

git hash-object -w test.txt

You can have Git tell you the object type of any object in Git, given its SHA-1 key, with cat-file -t:

You can run the count-objects command to quickly see how much space you’re using:

Rather than remove a specific file with something like rm file, you have to remove it with git rm --cached—you must remove it from the index, not from disk.

Git as a content-addressable filesystem is a very powerful tool that you can easily use as more than just a VCS.

The git diff command is used when you want to see differences between any two trees. This could be the difference between your working environment and your staging area (git diff by itself), between your staging area and your last commit (git diff --staged), or between two commits (git diff master branchB).