版控图

本篇文章只是要探索一下 git 工作流程，这篇文章只会使用 git 有关的内容，因为我对其他版控生态不熟。

我自己在工作上常使用的 git-flow 是 production base，然後有另一大主分枝 staging，然後透过 PR Merge 的方式 commit 到这两大分枝，由於这一大流程遇到了大规模重构，所以 production 版本跟 staging 相差甚远，每次发特定功能的 PR 都必须要帮 staging, production 各 merge 一版。

在考虑使用不同的工作流之前，还是得先考虑一些问题:
1. 团队之後规模是否会变大，如果会，这个流程适用未来吗?
2. 现在选用的工作流，要是有个工作 commit 错误，是否容易恢复或修正?
3. 这个工作流程是否会给团队带来任何不必要的负担?

集中工作流

集中工作流是最常见的工作流，就等於只有一个 branch ，大家都共用这个 branch，如果有 A, B 两人在工作，则 A 做 git push 之後，如果 B 也要 push，则需要先 pull 下来才能 push，假设两个人正好都在改同个档案，则需要先协调让某个人先 push 上去，另一个人 pull 下来解决冲突。

延伸阅读还可以参考 rebase [1]。

我在做小型游戏开发的时候会采用这样的模式，主要是觉得在 Unity 开发游戏时，很多时候脚本不同步会造成场景控制的麻烦，倒不如统一，并时常讨论 pull 城式下来。

工作流就会像这样，每次的蓝箭头回去都是 merge。

功能分支工作流

功能分支工作流，是希望每一个功能都能开出分支，分支也会有管理者 (或采用 Code Review)，A, B, C… 很多人都要开发工作，每个人根据自己工作的主题开出一个 branch (这个 branch 要从某个主线开出去) ，最後完成工作後发出 PR 合并请求。

根据自己工作主题开出 branch:

git checkout -b feat/your-feature main

这个意思是基於 main branch 开出一个 feat/your-feature 的分支。

开发工作流就会像这样，开出很多分枝，最後合并。 (要节省 branch 了话， feat 合并之後就可以把 branch 砍了。)

事实上这就是目前我工作上使用的工作流，虽然现在都是分别 staging, production 分开开发，但是最终是需要让 staging 合并到 production 的。

假设你的版本跟 develop 现流版本差异太大，可能需要时常拉 merge 才能让你发 PR 时不需要一次解决一大堆冲突问题，不过这是一个双面刃，假设你像我一样需要同时 PR 到 production 跟 staging，staging 的 commit 中如果有某些暂时不可以推送上去的功能，则使用 merge 会造成合并困扰 (则需要用 cherry-pick 处理等，但也要注意此方法会让你的版控变得很难看)

Gitflow 工作流

Gitflow 工作流是分出主要分支跟开发分支 (现在你有 Main, Develop 两个分支)，每当要开发一个功能时，就开一个 branch: Feature (功能)，等到功能完成时，发 PR 到 develop 上测试 (而不是直接合并到 main)。

等到累积到一定程度的功能後 (或是有周期性的发布时间) ， 就要进入准备发布阶段，此时会将 develop 分支再开一个分支 release/0.0.1 这样的名称出来，然後再合并到主分支。

合并流程就会像上图，并请参考下图解释红色就是从 develop 分支一路开出 release 再合并到 main:

参考 [2]，gitflow 有 cli 工具可以处理这件事情。

这与上一小节的流程不一样，例如我的工作上不会特别做 release 分支出来合并到 main 。

Forking 工作流

Forking 工作流，就是让每个人各自去 Fork Repo 到自己的 Repo 工作，也就是说你的 Repo 其实是独立的，等到开发完功能再发 PR 上去主专案，这个工作流程正是 GitHub 做其他专案贡献的方式。

References:
[1] https://www.atlassian.com/git/tutorials/comparing-workflows#centralized-workflow
[2] https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow
[3] https://www.oreilly.com/library/view/git-pocket-guide/9781449327507/ch01.html
[4] https://www.gitkraken.com/learn/git/git-flow
[5] https://medium.com/i-think-so-i-live/git%E4%B8%8A%E7%9A%84%E4%B8%89%E7%A8%AE%E5%B7%A5%E4%BD%9C%E6%B5%81%E7%A8%8B-10f4f915167e