聊聊我司的git工作流......

最近新来了个萌新，一顿操作猛如虎：有时直接把其他同事的代码给覆盖没了，有时忘了把代码合并到要投产的分支，有时直接改投产分支代码……

分析原因：

一是公司没有对新人进行相关培训，或者哪怕就给个规范文档；

二是之前的git工作流也没有形成规范，大家就各自按照自己的理解去操作(不理解的就瞎操作=o=)。

今天就聊聊我们团队不规范的git工作流。

我们的项目里日常一般有这么些分支：

• feature-日期：这个日期是以发版日期来确定的，比如每月的8号、22号是发版日，那么就会在上一个版本发完后拉下一个发版日期的分支，如feature-20210722；主要用于提测、封板、投产部署；这个分支的生命周期只到发版那天，发版完成就会被delete；
• 多个feature-xxx：根据不同的项目需求和开发者进行区分(实际上很多人为了省事经常在自己的feature分支直接提测)，功能开发并提测通过后delete；
• master：主分支，一般是发版完成后再从dev合并进来；
• dev：开发分支，一般是发版完成后再从feature-日期分支合并进来；
• test：测试分支，实际上并没有用到。
  简单画个图：

目前的git工作流
这里的封板指的是打release tag（不要问我为什么要打在feature-发版日期分支上，我也不知，估计是历史原因）

目前这套流程可能存在的问题：

• 提测和投产都是基于feature-发版日期分支进行，需要频繁维护发版分支，而master、dev和test基本没什么卵用；
• 因为开发人员可以随时merge分支到feature-日期分支中，导致提测代码很不稳定；
• 有些项目时间跨度比较大，比如上一个发版分支还没完成，就要先拉代码进行开发，这时候应该基于哪个分支？是基于master，还是dev，还是上一个发版日期分支？之后如何规范化操作？这些都没有形成规范。
• 开发人员对分支的操作权限过于自由，基本没有代码review，想怎么merge就怎么merge。
  那么，合理的git工作流应该是什么样的？

有几条通用准则可供参考：

When evaluating a workflow for your team, it's most important that you consider your team’s culture. You want the workflow to enhance the effectiveness of your team and not be a burden that limits productivity. Some things to consider when evaluating a Git workflow are:

• Does this workflow scale with team size?
• Is it easy to undo mistakes and errors with this workflow?
• Does this workflow impose any new unnecessary cognitive overhead to the team?

https://www.atlassian.com/git/tutorials/comparing-workflows

简单翻译一下：

为团队选择工作流时，最重要的是要考虑团队文化，要让工作流「提高团队效率」而不是成为负担。

要考虑以下几点：

• 这个工作流是否是可扩展的，当团队规模越来越大的时候，这个工作流是否还能适用？
• 这个工作流是否可以轻松地撤销失误或错误操作？
• 这个工作流是否会给团队成员带来新的不必要的认知开销？

可见，选择工作流最关键的是要达成「全体成员的共识」。同时，在合理的范围内，尽量避免操作层面的大改动，以免增加团队成员的学习成本。

那么，如何解决目前git工作流存在的问题？

修改后的工作流：

1. 充分利用各个分支的特性，让各分支各司其职。

• master只负责投产，只有可投产的代码才能merge到master分支；

• test负责测试，只有可提测的代码才能merge到test分支；

• feature(不加日期)负责开发，所有功能分支都从feature拉取，并最终merge到feature（实际上应该是叫dev分支，但是为了减少迁移成本，保留了之前feature的命名，仅只去掉日期）；

• 各个具体功能需求的feature-xxx分支，和之前的操作基本保持一致，都从feature分支拉取，最终merge到feature分支。

2. 各分支只能与上下级别的分支交互，不可跨级操作。只能在feature-xxx和hotfix分支上开发，其他分支只能做merge/pull这类操作。

3. 如果有遇到同一个项目分不同日期发版的特殊情况，只允许最早投产的分支合并到feature，其他分支如果因为排期问题需要提测，则先在自己的feature分支上提测，并且最终merge后如果有冲突最好再次提测，确保功能的正确性。

4. 各分支代码merge之前最好至少邀请一个团队成员进行review，最好是通过后再merge。代码冲突时必须及时通知相关团队成员review。

5. release tag仅只打在master分支上。

6. hotfix分支从master拉取，修改完成后merge到master，test和feature依次rebase。

以上仅为个人建议，真正实行就需要团队全员经过商榷后再确定。