使用Git，与其他版本控制系统最大的不同在于，Git是一个分布式系统，每一份仓库里，都是全量代码，因此协作中，冲突是常有的事。 我们来看看三种Git开发模型。

git flow

git flow 属于第一代git开发流程，它分为 develop 和 master 两个分支，所有的开发都在 develop 上切分支，然后定期合并到 master。master 代表的是 production ready 的代码。这种模型的主要问题在于需要不断地把代码从 develop 分支合并到 master，因此很容易遗漏。

• 当需要开发新功能时，从 develop checkout 出来，开发完成时，merge 回 develop 分支
• 当需要发布时，从 develop checkout 出来，当功能稳定后，需要把 release-* 分支分别 merge 回 develop 和 master 分支。
• 当需要hotfix时，从 master checkout 出来。当修复完成后，需要把 hotfix-* 分别 merge 回 develop 和 master 分支。

github flow

Github 提出了 github flow，把上面的情况简化了，Github的流程在于，master 分支总是 production ready 的。当你需要进行任何 操作时，从 master checkout 出来，进行开发，然后提交PR，最后合并到 master，进行发布。

这种模型特别适合持续部署，因为我们认为 master 总是最新的 production ready 的代码。

gitlab flow

Gitlab 提出了他们自己的流程。Gitlab 提出两种模式。

持续交付模型

我们按照环境来划分分支，例如我们通常会有三个环境：开发环境，staging环境，prod环境。

我们将 master 代码持续部署到开发环境，当代码准备好时，我们从 master checkout 出来，部署到 staging 环境，当需要hotfix时， 在 master 修复，随后 cherry-pick 到对应的分支。发布时，在对应的提交上打上tag。

版本发布模型

例如iOS应用，我们通常是要进行发版操作的，因此流程提出，我们要进行发版的时候，从 msater checkout 出来，当有hotfix 时， cherry-pick 到对应的发布分支。

squash

上文中提到了，很多时候，我们都需要进行pick，或者是revert，而这两个操作，一次都只能操作一个commit，在PR中，我们通常会含有 不止一个commit。那怎么办呢？我建议打开Github中的 squash merge 选项，打开这个选项之后，会把PR中的多个提交合并成一个 提交，这样当我们需要进行 cherry-pick 或者是 revert 时，操作就会非常方便。

总结

本文中我们介绍了三种git工作流，分别看了一下他们是如何工作的，最后我们介绍了 squash，这样我们可以更方便的进行 cherry-pick 和 revert。

ref:

• https://docs.gitlab.com/ee/topics/gitlab_flow.html
• https://docs.github.com/en/get-started/quickstart/github-flow
• https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/incorporating-changes-from-a-pull-request/about-pull-request-merges
• https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/configuring-pull-request-merges/configuring-commit-squashing-for-pull-requests
• https://nvie.com/posts/a-successful-git-branching-model/