分支可以改变你的生命

这个标题的确有点让人震撼，不过，至少我是这样认为的。事实上这并不夸张，有效地使用分支功能（branching）真的可以帮助你改善每一天的工作，让你成为一个更专业的程序员或者设计师。

首先，如果你已经拥有了一些在其他版本控制系统上的使用经验，那么我诚恳地请求你忘记那些你以前对分支（branching）和合并（merging）的认识。其实， Git 并没有做出什么新的发明，和其他很多版本控制系统一样都使用了分支这个理念。然而， Git 的分支概念在这个领域中的确是独一无二的，特别是在易用性和效率方面。

现在，让我们来看看为什么分支功能是如此重要。

工作在不同的背景中

在每一个项目中，我们要完成的所有工作都拥有有它不同的主题，并且它们都处在一个特定的上下文（context）背景环境下。开发每个功能，修复每一个错误，进行每一个设计上的尝试，甚至于你所开发的产品自身它们都应该被看作一个个独立的主题，并且在它所处的上下文环境中，这个主题与其他主题都毫无关系。 这样就有了在每个上下文环境中所对应的独立主题。但是，最起码你至少应该拥有一个最主要的主题，那就是你要给客户开发的产品本身，其次就是一些其他的开发主题，比如添加新的功能，修复错误，改动尝试等等。

在真实的项目中，所有的开发工作总是同时进行的，并且其每一个主题都处于一个特定的上下文环境下：

• 当你为了完成一个新的用户需求，你对这个页面准备了2套设计方案（主题 1，主题 2）……
• 同时你也想尝试的去修复一些错误（主题 3）。
• 另一方面，你还想升级一下你的 FAQ 页面（主题 4），或者……
• 团队中的另外一些开发人员正在为在线购物车添加一些新的功能（主题 5）……
• 还有其他一些同事正在尝试开发一种新的用户登录功能（主题 6）。

一个没有分支的世界

如果不清楚地区分在不同工作主题中每一个特定的上下文环境，那么就会产生一系列的问题：

• 如果你的客户只喜欢第二种设计方案，但是在你完成这个方案的同时，另外那个方案的改动也被实施了，那么你该如何保留你的这个有用的改动，并且撤销掉那些没有被采纳方案的改动呢？
• 如果客户改变了他的需求，我们不得不把那个为在线购物车添加的新功能删除掉，我们要如何清除这些代码呢？
• 如果那个新的用户登录功能已被证明不能被运用到真正的产品中去，而可能在这时它已经夹杂着很多其它不相干的改动了，那么我们该如何把这个功能剔除出我们的项目呢？
• 在不影响到其他的团队开发人员和开发主题的同时，你该如何去跟踪你的改动呢？

当你尝试着在一个单一上下文背景环境中同时进行多个主题的开发时，事情只会变得越来越糟糕：

作为一个临时的解决方案，你可以为每一个主题建立一个目录，并且拷贝整个项目到这些目录中去。但是这样又会产生很多其它的问题：

• 你绕过了版本管理系统，因为这些新的目录没有被纳入版本管理系统中。
• 没有了版本控制，你就不能简单地共享你的改动给其它人了，并且不能进行有效的团队协作了。
• 进行完成后的整合（特别是在整合这些改动回到项目中去）就会非常困难，而且非常容易出现错误。

简单来说，如果你想要进行更为专业的操作，你就必须找到一种专业的方法来解决这种多主题并行开发时带来的麻烦。

用分支来解决

你可能已经猜到了吧，利用分支功能就是来解决这些所有问题的最好方法。因为一个分支就代表了一个项目开发过程中的一个主题，并且它们之间是相对独立的。

你在任何时间的所有的更改只适用于你所工作的当前活动（currently active）分支，所有其他的分支都不会受到影响。这样一来整个团队就有了很多自由空间来对不同主题进行同步开发，更重要的就是那些带有实验性质的改动，当然你不想为此把整个项目搞砸！如果出了问题，你可以随时重新来过，也可以放弃它或者切换到另一个主题。

非常幸运的是分支功能（branching）在 Git 中被设计得非常简单和方便。当你要开始一个新的主题时，无论这个主题是大是小，你都必须为它创建一个新的分支。

黄金法则

#3: 使用分支功能

分支是 Git 一个非常强大的功能，当然不是偶然的，自始至终， Git 的宗旨就是提供一个即快速又简单的的分支功能。它是一个优秀的工具，并且可以帮助解决开发人员在日常团队开发中存在的代码冲突的问题。因此分支功能应该被广泛地运用在不同的开发主题中。比如添加新功能，修复错误，尝试新的想法等等。