Git的工作流程

常见的基于Git的软件开发的工作流程有三种，第一种是git的工作流程，第二种是github的工作流程，第三种是基于trunk的开发工作流程。

git 分支模型的工作流程

Git-branching-model.png
在这种工作流程下，有两个主要的分支：main和develop。master分支是production-ready的分支，也就是每个节点都是产品可以发布的节点。develop分支表示最新开发的，将要交付给用户的，为了下一次release的修改。当develop到达一个比较稳定的点，可以向外发布的点后，就会重新merge回master分支。
除了两个主要的分支以外，我们还有三种提供支持的分支

• feature branch: 用来开发新feature的，我们对新feature的修改都会在这个分支上完成。都新feature完成后，会merge到develop分支上。feature分支应该只在开发人员的repo里，不应该在origin里。
• release branch : 是为了产品发布新版本而创建的。当我们完成新feature的开发，并且将新feature的代码merge到了develop分支上，这时候意味着产品已经将要准备发布，这时，我们创建release，用于新版本发布的准备工作。在这个分支上，我们还会提交一些对于新feature的bug的修改。
• hotfix branch：当我们已经发布给客户的代码出现了致命的bug后，这时候，我们就应该发布一个hotfix版本来帮助客户解决问题。这个分支就是干这个用的。
  这种工作流程一目了然，各种分支的用途清晰明确。但是，由于分支比较多，merge会变成一个比较繁杂的操作。

GitHub 的工作流程

githubflow-online
整个GitHub的工作流程都是基于分支的。所以，工作的开展都是由创建一个新的分支开始的。一条规则：在master上的所有commit都应该是可部署的（deployable）。
创建完分支后，我们就开始在新创建的分支上进行工作，然后提交修改。记住，每一个commit都应该有一个详细的commit message来描述你所做的事情。这样方便其他人理解。
提交修改后，你需要创建一个Pull Request（拉取请求），这个拉取请求的含义是，请求别人将你的修改合并到特定的分支。当对方同意了你的Pull Request后，你就可以使用merge命令就你的代码合并到特定的分支了。在这个Pull Request的过程种，别人会review你的代码，给你提出一些建议，或者你们会讨论一些事情。总之，当你们能够达到意见统一时，别人就会同意你的Pull Request。
最后，就是可以部署你的代码了。
PS：自从被微软收购了以后，感觉GitHub充满了活力，新的功能越来越多。但是，国内的墙的问题，总感觉clone代码太慢。

trunk based development

trunk1b.png
trunk1c.png

我们刚才在讨论git branch modeling的时候，提出了它存在的一个问题，就是merge比较多的情况。说出来可能大家不信，某些公司里有一些人时专门做merge的，当然，这些人一般都是技术大佬，对代码都很熟悉。

参考

[1] a successful git branching model
[2] Understanding the GitHub flow
[3] trunk based development