Pragmatic Version Control Using Git（笔记）

git config --global user.name "Travis Swicegood"
git config --global user.email "development@domain51.com"
git config --global --list
git config --global color.ui "auto"
cd mysite && git init
git commit -m "add in hello world HTML" //SHA1哈希
git branch RB_1.0 master //创建分支
git checkout RB_1.0 //？？似乎没有到另外一个目录？？我个人怀疑这样做的效率（不过，也许Linux的ext3文件链接处理起来比较方便？）
git tag 1.0 RB_1.0 //tag：标记一个特殊的时间点。。。
rebase：合并分支上的修改到主线
1. git checkout master
2. git rebase RB_1.0 //试图replay所有变更。。。
3. git branch -d RB_1.0 //一旦合并到主线，则可以删除掉分支
4. 但是，删除了分支后怎么恢复呢？可以从tag：git branch RB_1.0.1 1.0 这只是为了fix特定状态发布的补丁
git log --pretty=oneline
git archive --format=tar --prefix=mysite-1.0/ 1.0 | gzip > mysite-1.0.tar.gz
git clone git://github.com/tswicegood/mysite.git mysite-remote //远程仓库
git add -i //交互模式？
git add -p //导出patch文件（这个比较赞，其他svn、hg都没见过这么方便的）
显示差异（1）what‘s in your working tree, （2）what‘s staged and ready to be committed, and （3）what‘s in your repository：git diff |--cached|HEAD
add .*.swp to the .gitignore ...
分支重命名：git branch -m old new
One of the hardest parts of branches is figuring out when to create a branch. It’s an art, not a science
1. Experimental changes
2. New features
3. Bug fixes
checkout -b（创建新分支同时checkout）
Merging：（注意，merge后还需要提交！）
1. Straight merge：合并2个分支：在主线上执行git merge branch即可
2. Squashed commits：压缩分支上的多个提交，转换为另一个上的单个提交（？），git merge --squash branch
3. Cherry-picking：直接将一个分支上的一个提交送到另一个分支上（这个太酷了，mecurial好象不支持~~）git cherry-pick 321d76f（分支上的commit编号）
  1. -n选项：to do the merge but stop before creating a commit
git reset --hard HEAD^
查看历史：git log（可以追加额外的参数指定范围，略）
追踪特定文件中行的变更情况：git blame -L 12,13 hello.html //注意：可以12,+2或13,-2描述（微型语法~~）
revert：重写历史... Break one commit into multiple commits？？
git fetch：保持与远程仓库up-to-date
git branch -r
git push
git diff：查看2个版本之间的修改情况（显示为一个差分提交，这个功能Mercurial/Hg是没有的，SVN可以做出比较），而git log将显示所有提交的历史
Beyond the Basics（略）：
1. git gc：Compacting your repository history
2. git archive：Exporting your repository
3. git rebase：Rebasing a branch‘s history against its parent
4. Using the reflog to fix your repository
5. Bisecting your repository to find what change introduced a bug