Git分支管理小团队实践

Posted on   |   In   |     |   visitors

最近实验室的项目终于开始正式撸代码了，前期一直处于各种七七八八的设计阶段，项目成员主要就是我们实验室同届的加上我一共五个，虽然之前一直代码管理用得就是Git，但是关于Git的分支管理一直很混乱，甚至没有任何规约。
实验室同学之前在项目中分支管理的方法是有一个dev分支和master分支，然后另外每个人凡参与项目都得新建一个自己的分支，合并代码在自己的分支上，而且自己的分支是不会被删除的，按照这种方法就是每个人得维护自己的分支。
询问了同学他们之前为什么这么做，他们也不清楚，只是其他人这么做，他们于是就跟着做了。我觉得这种方法每个人都得维护自己的分支，分支太多容易混乱不利于后期代码管理，而且思路不清晰，便想着重新启用一套比较简洁成熟的分支管理策略，适合我们这种小团队项目开发。

分支管理策略

上网查了一些相关资料（参考资料链接放在文章末尾），决定采用如下的分支管理策略：

  • 主分支master
    一个代码库有且仅有一个主分支，主分支主要用于大的版本更新，一般很少更新master分支。

  • 开发分支dev
    主分支只用来分布重大版本，日常开发应该在另一条分支dev上完成。我们把开发用的分支，叫做dev。如果要对外发布大版本，如果想正式对外发布，就在master分支上合并dev分支上代码。

    1
    git merge dev

  • 临时分支
    master分支和dev分支都是主要分支，长久存在，属于常设分支。我们也决定只设master分支和dev分支两个常设分支。
    但是，除了常设分支以外，还有一些临时性分支，临时性分支就是应对一些特定的版本开发，比如完成某些功能模块、修复一些bug等等都是属于临时性分支。阮一峰老师博文当中给了三个临时性分支，功能分支、预发布、修补分支，但是考虑我们团队的实际情况，我们在实际开发中可能只会用到功能（feature）分支，而修补bug（fixbug）分支与功能（feature）分支也并没有去严格去区分开来，我们不搞预发布这个环节当然也不去建预发布（release）分支了。
    最后临时性分支具体体现在我们团队中就是每个人在要开始一个新的功能模块的时候会去建个自己的分支比如：cgs分支，开发完之后在dev分支上合并自己分支cgs，合并完删除，下次再开发另外的功能，再重新新建cgs，这样代码库的常设分支就只有dev和master了，其他都是临时分支。

Git分支工作流程

以上就是我们团队的Git分支管理策略，经过实践感觉还是不错的，下面通过git操作命令模拟一个完整的流程，假设我现在要开始进行加入项目开发：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
# 项目clone就不说了，假设项目已经切换到了dev分支
# 新建一个功能分支，名字随便取可以叫做feature-xxx,也可以叫自己的名字缩写cgs,并切换到新的分支
$ git checkout -b cgs
# 开发了一段时间，代码完成了，需要合并到dev分支上。
# 1.先在cgs分支提交代码
$ git add .
$ git commit -m "提交信息"
# 2. 切换到dev分支
$ git checkout dev
# 3. 在dev分支合并临时分支cgs
$ git merge cgs
# 另外：这是可以通过下列操作，查看尚未合并到当前分支的branch
$ git branch --no-merged
# 或者通过下面查看已经合并的分支
$ git branch --merged
# 4.解决merge的冲突之后
$ git add .
$ git commit -m "提交信息"
# 5.提交本地dev分支到远程dev分支，这期间如果有其他人push过，则需要git pull origin dev操作，然后再push
$ git push origin dev
# 6.合并完之后，原来的cgs分支任务使命已经完成，这个时候就可以删掉原来的分支了
# 有一种情况就是如果cgs分支中还包含着尚未合并进来的工作成果，简单地用 git branch -d 删除该分支会提示错误
$ git branch -d cgs
# 如果不管有没有包含合并进来的改动，强制删除分支，则是下面这个，但是一般情况下，如果需要合并还是要合并干净，防止丢失改动。
$ git branch -D cgs

这样一次功能性开发就完成了，至于发布用户版本的过程就不说了，只是在master分支合并dev代码而已，操作跟上面大同小异。

总结

这样看来我们的分支管理策略就很简洁了，只有master和dev两个常设分支，也是主要维护的分支，其余的都是临时分支，平常合并代码在dev分支上，临时分支用完可删，也可随时基于dev分支新建，管理起来方便很多，思路也更清晰了，达到了团队预期的目的。

参考

阮一峰：Git分支管理策略
分支管理策略
Git 分支 - 分支的管理

-EOF-