分支的工作流程

分支的工作流程要取决于它的使用背景，我们可以将它分为两个主要的方面。

(A) 短期分支（Short-Lived）/主题分支（Topic Branches）

在本书前面的章节中已经提到了我对建立分支的一些建议，例如：对应新功能的分支，修复错误的分支 以及 进行代码尝试所建立的分支。这些分支都有两个重要共同特征：

• 它们只涉及一个单一主题，而且它包含的代码要和它的主题相对应。例如，你不应该建立一个关于购物车功能的分支，并且再在这个分支上去提交一些有关于邮件订阅功能和错误修复的改动。
• 它们都只有非常短暂的生命周期。通常情况下，这个生命周期只维持到这个开发主题的结束之后（例如当错误被修复，新功能被完成……），这个分支的改动就会被整合到项目的大环境中去，并且这个分支也会被随之删除掉。

(B) 长期分支 Long-Running Branches

相对于那些基于一个单一开发主题或是一个错误修复的短期分支来说，这类分支被定义在更高的层面上。它们代表了在整个项目生命周期的一种状态（比如：“产品”，“测试”，“研发”状态）。它们在项目中保存的时间比较长，甚至可能是整个项目的生命周期。这类分支有如下一些典型特点：

• 你不应该直接在这个分支上工作。但是你可以整合其他的分支（例如功能分支或是其他的长期分支）到这类分支中来，尽量不要对它直接进行提交。
• 一般来说，在长期分支之间也存在不同的等级。例如 “master” 分支一般被定义为最高等级。它应该只保存产品代码（production code）。在它之下应该存在一个 “开发（development）” 分支。它会被用来进行真正的开发和测试工作，然后整合入 “master” 分支……

我们应该为项目建立哪些长期分支呢？该如何使用它呢？这并不能一概而论。这在很大程度上取决于开发团队的规模，开发风格和项目的需求，甚至于不同的客户。这个规则必须被很清楚的定义出来，并且要得到整个开发团队的认同和遵守。

一个简单通用的分支策略

我们已经讲到了，不同的开发团队必须定义合适自己的分支策略。然而，还是有一种简单通用的流程，它应该适用于大多数的开发团队。

仅仅使用一个长期分支

虽然你可以在你的开发流程中引入多个长期分支，但是这样也会存在很多不利因素。最为显著的是会让你开发流程变得非常复杂！在你的工作流程中仅仅定义和使用一个单一的长期分支可以避免很多不必要工作，并且使项目的开发变得比较简单。

主题分支

每当你开始着手开发一个新的功能的或是修复错误时，你都应该对应不同的主题建立一个新的分支。这是一种很通用的做法，并且也要成为你的一种习惯。

如果在你的项目仓库中只存在一个长期分支，那么所有的主题分支都必须基于这个 “master” 分支。当你所开发的功能完成后，或者是错误被修复后，这些所对应的改动就理所当然的要被合并回 “master” 分支。

在你开发你的新功能的同时，团队的其他开发人员已经把各自完成的改动整合回了 “master” 分支。在这种情况下，你就必须经常性地把那些在 “master” 分支上的改动合并到你的工作分支上来。这就确保了你的工作分支一直处于最新的状态,并且当你要把已完成的改动整合回 “master” 分支上时，可以减少可能出现的冲突和风险。

请不要忘记这个简单的黄金法则：只有正确和稳定的代码才能被整合到 “master” 分支上来！如何确保这些代码正确性呢？这就依靠你和你的团队了。例如使用单元测试（unit tests），代码审查（code reviews）等等。

保持远程同步

在 Git 中，远程和本地仓库可能彼此毫无依赖关系。不管怎样，本地和远程的分支必须被一致对待。

但是这样也并不代表你必须要发布你的 每一个 本地分支，拥有一些完全属于你的私有分支也是非常必要和有意义的。例如当你单独的研究一些新功能，或是尝试调试一些新的技术时。
不管怎样，当你要发布你的一个本地分支时，你就应该给它对应的远程分支一个相同的名称。例如，如果你有一个本地分支被命名为 “login-ui”，当你要发布它时，在远程仓库上它也必须拥有 “login-ui” 这个名字。

频繁推送

保持与远程分支的同步并不是只停留在结构层面上，经常性地通过 “git push” 命令发布你的改动可以有助于团队里的其他的开发人员看到和使用你的最新开发成果。附带的还有一个最大的好处是，它可以作为你的远程备份。

其他分支策略

上述策略是最适用于小型的开发团队。而一个较大的开发团队可能会需要更多的规则和更复杂的结构。
在网络上搜索其他开发团队的策略将为你提供更多的选择。这是其中一个非常流行并且可能是值得尝试的一种工作流程 “git-flow”。