git分支初学指南

         本文由 伯乐在线 - unblock 翻译自 java code geeks。欢迎加入技术翻译小组。转载请参见文章末尾处的要求。

git的分支是“日常用品”，软件的各种功能可在隔离的分支里开发。这是合理的，因为合并的过程有时会不受控制。如果你在默认主线上开发，而一个提交了的功能被推迟使用，你就要在完全不一样的功能上开发，而在此之前，你要还原你在主线上的修改。功能分支能让你隔离变化并使合并的过程简化，不过，一旦你开始使用功能分支，你就会发现命令行不再是无所谓的。想要正确地理解git并成功地使用它，就该首先掌握它的命令。

为什么要git

专利软件塑造了版本控制系统（VCS）来适应如下需求：

1. 项目有严格的发布时间
2. 团队是搭配好的的
3. 有明确的主任务，没什么支线剧情
4. 分支是为不同的发行版，或有风险的功能而准备的
5. 集中的（源码）服务器是与世隔绝的

以上是集中式VCS的诞生背景。但集中式VCS （例如 Subversion）对于开源项目的如下特点，就不适合了：

1. 发布时间不定
2. 贡献者可能遍布全球
3. 欢迎各种创意，不管它是彻底颠覆的，或是旷日持久的
4. 分支是必须的，因为开发者们着眼于不同功能点，而非同一目标
5. 代码全世界可见

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 <[e-mail]> 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://[e-mail]': 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://[e-mail]': Everything up-to-date

现在去GitHub看下结果：

为了提醒产品所有者我做的贡献，我们需要发个pull request。

产品所有者可以审核我的修改，并决定是否和合适merge到主线。在审核期间，他可能会叫你再作修改，才准merge，所以你要：

1. 在本地metrics线commit新的修改
2. 把新修改和就修改压在一起
3. 强push到远程（例如 git push -f）

有个经验法则，你不应经常将commit的历史重写。因为这会影响其他以你的分支为起点的贡献者。但你的分支也不一定会被其他贡献者使用。

想更了解git，你可以看下网上免费的Pro Git ，或者这个不错的compact guide 。

原文链接： java code geeks   翻译： 伯乐在线 - unblock
译文链接： http://blog./60241/
[ 转载必须在正文中标注并保留原文链接、译文链接和译者等信息。]