【Git】分支的意义

我是2010年参加工作的，当时，有件小事，我是印象相当深刻的。那时，公司为我指定了一位导师，负责辅导我快速进入角色并胜任工作。我便跟着导师合作项目，以他为主导，后来我发现，每次他说他做好了什么功能时候，我总是在代码里找不到相应地功能，等我去问他，他说，“哦，我没有提交代码”，如此数次后我问他，为什么不提交代码，导师回答我，那样会产生太多的版本号（当时我们使用的是SVN，会产生revision号）。听到这句话，即便经验浅薄，我还是震惊了！

事实上，我接受到的本科教育，都是通用教育，进入到工作岗位上后，也没有接受过公司提供的关于代码版本控制的培训，好像公司方面觉得，这是每个程序员天然应该会的东西，而事实呢，大部分程序员，甚至连版本控制的核心理念都不知道，更别提与之相关的最佳实践，工程项目管理等等。

在这里，我不得不重申，版本控制的第一个理念，是保护程序员创造性的劳动成果，简单来说，便是：只要写下来的代码，就应该被妥善保管。无论这些代码是庞大的，细小的，功能完备的，还是有缺陷，不完整的，都应该避免丢失。大家在从事编码实践过程中，最害怕的应该是写好的代码丢了，而不是别的什么。别的问题，都有别的方法来解决。

时代发展到今天，软件工程项目，大都非常复杂，可能一个程序员，一整天，都没法完成一个功能。如果，因为代码无法运行，而不敢提交到版本库，那这段代码就面临丢失的风险。但是，不提交代码，肯定是不对的。

应该有一个地方，保管总是可以正确运转的代码，就是我们常说的“主线”（trunk）或者在 Git 里叫 master（现在 master 遭到了一部分人唾弃，叫 main 也是可能的）；而与此同时，应该另有一个地方，保管开发到一半的代码，或试验性的代码。这就要用到“分支”（branch）这个功能。分支，其实是一个相对的概念，因为相对分支的“主干”其本质上也就是一个特殊的分支而已。

分支是一种很有效的工具，用来保存代码的所有变更。一般也都会提供“比较”和“合并”等功能，主要用于将一个开发完毕的分支，重新合并到主干。在我们使用SVN的时候，因为版本库在云端，所以，新建一个分支，就是发往云端的一个命令。程序员的本地环境，只是服务器的一个工作拷贝，如果，需要在某个分支工作的话，一般需要“切换（switch）”。

而在Git里面，分支的使用成本无限地降低了。因为 Git 的分布式设计，我们的所有版本库，都在本地有个完整的备份，所以，分支得创建就是一个本地动作，而且在 Git 里面使用文件的 hash 来唯一标记一个文件的，如果没有修改的文件，基本可以认为不会占用额外的存储空间。切换分支也变成了一个非常简单而且低成本的动作。

在 Git 里面是非常鼓励使用分支的。如果你有一些进行到一半的工作，你最好将其保存在一个分支里，你要决定的是，是否把这个分支“推送”到公共的版本库去，如果确实是一个 broken 的功能，无法正常运行，你完全可以不要推送到大家共同 share 的中央库去，保证了代码的私密性。

对于像整个团队或者整个社会开放的公共版本库，里面的每个分支是否可以正确运转，可能取决于这个项目的一些约定。但是这不会影响一个程序员在本地创建和使用分支。这就给分支的使用带来了极大的自由度，也关注了代码的安全。

甚至，在没有与其他人共享的时候，你可以随意修改你分支里的 commit，合并一些 commit，像文初我第一位导师那样担心自己的 commit 过多的极度洁癖也轻松可以解决。时代真的是不同了，而且进步了。

— 完 —