项目组织中常见Git工作方式

Git工作流分类

• 使用Git作为代码托管工具，一般在项目组进行开发的时候，大致可能使用到的Git工作方式就是：
• 集中式管理
  • 几乎可以理解为用git作为项目托管，管理模式与svn一样的工作方式
• Git Feature工作流
  • 采用Git的分支特性，主干或者分支作为Git的远端仓库管理，本地开发中采用新的本地分支，再进行合入主开发分支，进行提交
• Forking 工作流：
  • 可以理解为github提交的方式，一般对于审核严苛的情况才会采用，因为太影响开发的效率了，对审核的要求也比较高，一般的项目组难以实现这个层次的代码管理

工作中的Git工作模式

• 在以Git作为代码托管方式之后，平时的开发过程中更为常用的应该是集中式+Feature混合使用，一方面有比较清晰的分支作为主版本以及Release版本进行开发合并，另一方面对于开发人员而言，如果是小的修改直接在与远端分支一致的分支上进行开发提交，如果涉及到大的系统才会考虑本地开一个新的分支，等完全开发完成了再进行合入 。

分支合并问题

• 在最近的开发过程中，因为有别的部门的人提交，在commit信息里我竟然发现了"merge master of xxxx onto master"，我真是惊了一呆，自己合入自己干嘛，另外这个节点的提交其实就是之前的提交，查看修改变更也比较不方便，所以我特地找上对应开发人员去了解情况，解决这个奇怪的提交节点，然后制定了之后的提交要求

Git Merge VS. Rebase

• 发生了上述提交节点的问题，其实是在Pull 采用自动Merge的情况产生的。在开发初期，分支orign/main的提交节点有 A->B->C三个历史记录，此时开发人员A在本地main进行开发有A->B->C->Da，并且开发人员B也在那个远端节点情况下进行开发有A->B->C-Db，这个时候B用户优先提交，当前的origin/master就变成了A->B->C->Db，此时开发人员A已经做好了测试并进行了commit然后进行push，因为远程节点在本地的代码节点之前，所以要先进行一次git pull操作，如果此时A用户是直接使用默认Git Pull，这种情况下的pull采取的步骤其实是git fetch && git merge，所以就会产生了一个Merge Main xxx onto Main的commit信息，也就是出现了怪异情况的原因。
• 解决这个问题也很简单，要么就是手动git fetch && git rebase，要么就吧 pull 的rebase设置为true，默认使用rebase的方式来进行git pull的操作，这样的节点只会把当前的提交重新rebase在origin上，再进行提交，如果此时出现了冲突，那么就必须要解决冲突再进行提交，等A用户提交玩，origin/master就变成了A->B->C->Db->Da了，从git的log记录来看也清晰多了。

Git Rebase 与 Cherry Pick

• 这里特别提到一下rebase与cherry pick的原因是，在进行这两个操作的时候，实际上是把指定的节点又重新生成了一个新的节点去做相应的处理，换句话说，如果我当前的提交有A，B，那么在进行rebase的时候，实际上是新生成了一个A’，B’两个节点信息，同样的Cherry Pick指定的节点C，D，再进行合入的时候其实已经是新的节点C’，D’了，所以在看git的流线图的时候要特别注意

总结

• 网上关于Git的操作方式的科普文已经很多了，具体操作细节可以参考官方说明，目前公司项目组比较常用且实际的Git管理模式就是“集中式+Feature”开发的模式，在进行git pull的时候要选择使用Rebase，另外再合并别的分支的时候建议使用–no-ff可以查看有一个清晰的Feature完整变动记录。
• rebase与cherry pick都会产生一个与原节点内容一样，但是新的一个节点，所以查看记录的时候要注意