在 Git 里面 分支 (Branch) 是个非常重要的机制，使用上也必须特别小心，因为专案总不能无限制的「分支」下去，最终总是要合并的，但合并是日后的议题。今天「畅想资源」就来向大家略略介绍一下Github分支的基本概念

介绍

在版本控管中使用「分支」机制，最主要的目的就是用来解决开发过程中版本冲突的问题。笔者认为，有许多曾经用过任何版本控管机制的人，都会认为「分支」是个「产生版本冲突」的元凶，因为当你开始分支之后，一定就会想到合并的议题，而当分支之后，若是有人跟你一样修改到相同档案的相同一行时，就会引发「版本冲突」，而只要发生冲突，就必须费心解决。

当冲突发生时，有时可以很轻易的决定要用自己的版本或是对方的版本，但有时却没那么容易，复杂的时候还要依据冲突的片段，找到当初改过这几行的人出来，协调出彼此的变更对系统的影响，最后决定要怎样合并，诸如此类的问题非常繁琐，也因此很多人会尽力避免「分支」的情况发生，以免发生「冲突」。

不过，若是开发团队越来越大，系统功能越来越多，就算你不对版本做分支，大家的冲突情况一样也会层出不穷，有时候还不是冲突的问题，而是 A 写好一个功能，但被 B 的后续版本给盖掉了，然后没有任何冲突发生，这也不是大家所乐见的。然而，这也是一种「无形的冲突」状况。

以前在集中管理的 Subversion 版控机制中，也有分支的概念，也可以运作的很好。当然，如果你的软体架构不够好，如果你对分支的概念、工具的使用也不是很清楚，我相信使用「分支」时也不会多顺利，这是个必然的结果，这世界绝不会有「免学、无痛、自然学会分支」的这种版本控管工具出现，事在人为，人的观念不对，用什么工具都不会顺的

由于 Git 属于「分散式版本控管机制」，在分散式版本管理的使用情境中，最不想做的事情就是「管理」，所以 Git 很少有所谓的管理机制或权限控管机制，它唯一想做的仅仅是让大家可以顺利的「分支」与「合并」而已

举个例子：从我们使用 git clone 指令开始，其实就是「分支」的开始，你从远端储存库复制一份完整的储存库下来，然后开始在自己的本地端建立版本，等软体修订到一定程度后再「合并」回去，只是这时合并的指令叫做 git push 而已

这种分支与合并的情形，在 Git 版本控管的过程中无所不在，远端的储存库可以有分支，本地的储存库可以有分支，你可以从远端任何一个分支合并(pull)到本地分支，也可以将本地的分支推向(push)远端的分支，你当然也可以从本地任何一个分支合并(merge)到本地的另一个分支。可以想见，如果「分支」没有一套良好的控管逻辑，最后可以组合出各种极其复杂的版本控管使用情境，这也不是大家所乐见的。因此，好好学会「分支」与「合并」真的非常重要。例如 git-flow 就是一套广受欢迎的分支管理模式，这不是一套工具，而是一种管理分支的逻辑，这部分在我未来的文章中将会加以说明

Linux kernel 发展的过程，在全世界有成千上万的开发人员共同参与，为了管理这么大量的开发团队，Git 俨然而生，这是套分散式的版控机制，每个人都有完整的版本，版本散出去之后，大家必须管好自己的版本，然后遵照团队的要求合并回来。然而，在合并回来之前，这套机制确保每个人都能够顺利的开发，不受任何其他开发人员的版本而影响，而 Git 确实做到了这点，同时又降低了版本控管的复杂度

当然，我也必须讲，如果参与软体开发的团队只有两三人，而且这些人还都聚在一起，那确实不一定要使用 Git 版本控管，使用 Subversion 也是个很好的选择，简单又直觉，开发的过程中若遇到问题，前后左右协调一下就能解决，这比让整个团队都来了解 Git 来的方便很多

如果你的团队有点规模，或大家并没有坐在一起工作，又要做版本控管的话，或许 Git 是个不错的选择，但工作团队之间拥有一致的版控观念或习惯，也是非常重要的一件事

版权信息

本文转载自“第 08 天：关于分支的基本观念与使用方式”，并由“超级efly”整理（原作者版权所有）

历史上的今天

2013年：注册「免费」Apple开发者帐号（11条评论）