Git协同开发的那点事

随着分布式和开源这些概念的不断普及，现在有大部分的开发者都在用Git管理开源项目、个人项目和公司的项目开发。本篇博客主要是研究实际在使用Git进行多人协作开发过程中的一些场景和解决方案。

引言

Git是一个开源的分布式版本控制系统，可以有效、高速的处理从很小到非常大的项目版本管理。

网上有许多介绍Git的博客等，下面就附上链接：

• Git(百度百科)
• 为什么用Git
• Git和SVN的区别

协同开发场景分析

场景一：开发分支错误

项目来了个需求1，从develop分支中拉分支A进行开发；开发的中途，又来了一个紧急需求2，于是我就直接在A分支中开发需求2；直到发现不能在A分支中开发需求2的时候需求2的代码已经commit了几次了。

如下图提交：

m1-m2-m3-m4-m5

m1、m2、m5是需求1的代码，m3和m4是需求2的代码

解决方案：

假设m3和m4是commit id为0bda20e和1a04d5f

利用cherry-pick和revert:

1. 从develop分支创建新分支B：git checkout B
2. 将A分支中的需求2的commit复制到分支B：git cherry-pick 0bda20e 1a04d5f
3. 撤销在A分支中开发的需求2：git checkout A 和 git revert 0bda20e 1a04d5f

附上cherry-pick和revert的一些博客：

• git cherry-pick
• git引发的血案（cherry-pick找回丢失的commit)
• git revert 用法

场景二：分支进度不一致

m1-m2-m3-m4-m5-m6(master)
       \
       f1-f2-f3-f4-f5(feature)

多人协作开发时，你需要开发一个新功能，于是你从master上的commit3开始拉了一个分支feature，可是这个新功能开发周期很长，等到你完成的时候，master已经提交到m6了。如上图所示。

解决方案：

使用rebase：

1. 切换到分支feature：git checkout feature
2. rebase到master：git rebase master
3. 有冲突解决后执行：git rebase --continue

分支树则变成(如下图所示)

m1-m2-m3-m4-m5-m6(master)
                \
                f1-f2-f3-f4-f5(feature)

附上rebase的一些博客：

• git rebase简介(基本篇)
• git rebase让时光倒流
• cherry-pick, merge, rebase
• git-rebase(认真看，分析很到位)

暂时先发这么多，到时再补上。有错误的地方麻烦各位指正。谢谢！