git分支初学指南
git的分支是“日常用品”，软件的各种功能可在隔离的分支里开发。这是合理的，因为合并的过程有时会不受控制。如果你在默认主线上开发，而一个提交了的功能被推迟使用，你就要在完全不一样的功能上开发，而在此之前，你要还原你在主线上的修改。功能分支能让你隔离变化并使合并的过程简化，不过，一旦你开始使用功能分支，你就会发现命令行不再是无所谓的。想要正确地理解git并成功地使用它，就该首先掌握它的命令。
为什么要git
专利软件塑造了版本控制系统（VCS）来适应如下需求：
- 项目有严格的发布时间
- 团队是搭配好的的
- 有明确的主任务，没什么支线剧情
- 分支是为不同的发行版，或有风险的功能而准备的
- 集中的（源码）服务器是与世隔绝的
以上是集中式VCS的诞生背景。但集中式VCS （例如 Subversion）对于开源项目的如下特点，就不适合了：
- 发布时间不定
- 贡献者可能遍布全球
- 欢迎各种创意，不管它是彻底颠覆的，或是旷日持久的
- 分支是必须的，因为开发者们着眼于不同功能点，而非同一目标
- 代码全世界可见
git是软件工程理念的精粹。如果工具不适合你的个案，你就自创工具。git是分布式版本控制系统（DVCS），用于解决开源项目与传统VCS之间的阻抗失配。
UI像Tortoise SVN这样的subversion是令人满意的，我也很少用到他的命令行。基于主线的开发方式只需简单的版本控制，所以在图形化界面就能操作。
git有多种workflow styles可供选择。你也可以继续按使用基于主线的开发（这篇博文的代码例子就是这样管理的），但如果你想为开源项目做贡献，你就得熟悉一下“功能分支”。
为什么要功能分支
git的分支是“日常用品”，软件的各种功能可在隔离的分支里开发。这是合理的，因为合并的过程有时会不受控制。如果你在默认主线上开发，而一个提交了的功能被推迟使用，你就要在完全不一样的功能上开发，而在此之前，你要还原你在主线上的修改。功能分支能让你隔离变化并使合并的过程简化，不过，一旦你开始使用功能分支，你就会发现命令行不再是无所谓的。想要正确地理解git并成功地使用它，就该首先掌握它的命令。
一个功能分支的例子
我决定给Bitronix Transaction Manager 添加一个Metrics 支持，所以第一步就是添加一个metrics分支。
首先检查下目前有什么分支：
|
1
2
|
D:\wrk\vladmihalcea\btm>git branch
* master
|
我只有一个主线，所以创建一条新线来容纳我的修改：
|
1
2
|
D:\wrk\vladmihalcea\btm>git checkout –b metrics
Switched to a new branch ‘metrics’
|
以上的命令干了两件事：
- 创建了一条本地的metrics线
- 它将工作目录切到这条新线
我们可以看到当前的分支指向改变了：
|
1
2
3
|
D:\wrk\vladmihalcea\btm>git branch2
master
* metrics
|
通常在最后版本之前，你会做多次的commit。但为了简化merge过程，你需要压缩commit，就像这样：
|
1
2
3
4
5
6
7
8
9
|
commit f75838a7cf8cfdb9ceeb364a0f0faae24642d39e
Author: vladmihalcea <mih_vlad@yahoo.com>
Date: Thu Jan 23 11:57:16 2014 +0200
add metrics support (Codahale)
add PoolingDataSource connection wait time histogram
add PoolingDataSource in–use connections histrogram
|
所有之前的改变都只存在我的本地库，因此我要将它公开。这个过程叫创建远程分支，是这样做的：
|
1
2
3
4
5
6
7
8
9
10
11
|
D:\wrk\vladmihalcea\btm>git push —set–upstream origin metrics
Username for ‘https://github.com’: vladmihalcea
Password for ‘https://vladmihalcea@github.com’:
Counting objects: 56, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (32/32), done.
Writing objects: 100% (34/34), 7.64 KiB | 0 bytes/s, done.
Total 34 (delta 15), reused 0 (delta 0)
To https://github.com/vladmihalcea/btm.git
* [new branch] metrics -> metrics
Branch metrics set up to track remote branch metrics from origin.
|
现在，我的metrics的本地分支都push到了远程分支。
|
1
2
3
4
|
D:\wrk\vladmihalcea\btm>git push
Username for ‘https://github.com’: vladmihalcea
Password for ‘https://vladmihalcea@github.com’:
Everything up–to–date
|
现在去github看下结果：
为了提醒产品所有者我做的贡献，我们需要发个pull request。
产品所有者可以审核我的修改，并决定是否和合适merge到主线。在审核期间，他可能会叫你再作修改，才准merge，所以你要：
- 在本地metrics线commit新的修改
- 把新修改和就修改压在一起
- 强push到远程（例如 git push -f）
有个经验法则，你不应经常将commit的历史重写。因为这会影响其他以你的分支为起点的贡献者。但你的分支也不一定会被其他贡献者使用。
想更了解git，你可以看下网上免费的Pro Git ，或者这个不错的compact guide 。
关于作者：unblock
转载自：http://blog.jobbole.com/60241/
