很早以前就发过一篇Git教程。如果你不会使用Git，可以在公众号的底部菜单中找到教程合集，里面有Git教程索引。今天我们不讲基本用法，而是讲如何使用Git？我们知道，相比于Svn，Git最好的地方就是它的分支，非常灵活，但是如果缺少一个使用套路，就会显得杂乱无章，尤其是在团队合作中，如何玩转Git分支？我们不发明任何轮子，也不设计任何新流程。本文主要介绍三种常见的工作流：GitFlow、GitHubFlow和GitLabFlow。介绍完了再说说宋歌的一些经历吧。1.GitFlow我们先来看看GitFlow。GitFlow是最早和广泛使用的工作流。在GitFlow中，有两个永远不会被删除的长期存在的分支：master和develop。这两个分支中，master主要用于发布稳定的新版本。该分支经常保持软件可以正常运行的状态。由于维护这个状态的需要，不允许开发者直接修改master分支的代码。并提交，其他分支的开发工作在其他分支的开发工作进展到可以发布的时候会合并到master分支，并且只有在release发布的时候才会进行这个合并，Git标签版本号的一部分将附加到版本中。develop用来存放我们新开发的代码。这个分支是我们开发过程中代码的中心分支。该分支也不允许开发者直接修改提交。程序员应该从develop分支开始创建一个新的feature分支，在feature分支中开发新的功能或者代码修正，也就是说develop分支维护了开发过程中的最新代码，这样程序员就可以创建feature分支为了自己的工作。注意developing合并时，不要使用fast-farwardmerge。建议加上--no-ff参数，这样master上会有merge记录。关于两者的区别，可以参考松哥之前的Git教程。这里我就不细说了。除了这两个永久分支外，还有三个临时分支：feature分支、hotfixes和release分支。我们分开来看：featurebranches就是特性分支，也叫功能分支。当需要开发新特性时，可以新建一个feature-xxx分支，在其中开发新特性。这也是我们日常工作的基础。开发完成后，会合并到develop分支，如下图所示：hotfixesbranches这个分支根据名字是用来修复bug的。当我们的项目上线后，发现有bug需要修复，然后从Master拉一个名字为fixbug-xxx的分支，然后进行BUG修复。修复完成后，将代码合并到Master和Develop两个分支，然后删除hotfix分支，如下图：releasebranches这是发布release时拉取的分支。当我们所有的功能完成后，准??备将代码合并到master中时，我们从develop拉一个release-xxx分支。这个分支一般处理发布前的一些提交和客户体验后的小bug修复（BUG修复也可以合并到develop），不要在这开发功能，pre-release结束后合并分支到develop和master，然后删除release，如下图：大概就是这个意思。宋大哥在工作中其实使用了类似GitFlow的工作流。为什么相似？我们的项目主要保证master、develop和release三个分支。在此基础上，其他可选。2.GitHubFlowGitHubFlow比GitFlow简单多了。GitHubFlow也是GitHub上使用的工作流。如果你想参与GitHub上的开源项目，不妨看看GitHubFlow。GitHubFlow官方流程如下：它的流程是这样的：当你需要开发新功能或修复bug时，从master拉取一个新的分支。新分支开发完成后，或者遇到困难无法继续开发时，可以发起pr（PullRequest）。pr不仅提交代码，还可以让其他同事审查你的代码。在此过程中，您可以继续提交pr。最后你的pr被接受并合并到master中。GitHub工作流虽然使用起来非常简单，但它的问题也很明显，就是没有提供常见工作场景问题的解决方案。3.GitLabFlowGitLabFlow结合了GitFlow和GitHubFlow的优点。它没有像GitFlow那么多容易让新手迷惑的分支，能够适应不同的开发环境。GitLabFlow最大的原则叫做upstreamfirst，中文翻译为“upstreamfirst”：即只有一个主分支master，是所有其他分支的upstream，只有upstream分支采纳的代码变更可以应用到其他分支。对于“持续发布”的项目，除了master分支，我们还可以创建不同的环境分支。比如开发分支是master，预发布分支是pre-production，生产分支是production。这里开发分支是预发布分支的上游，预发布分支是生产分支的上游。代码更改必须从上游开发到下游。比如生产环境出现bug，就必须新建一个功能分支。首先合并到master确认没有问题，然后cherry-pick到pre-production。进入生产之前这一步没有问题，如下图所示：只有在紧急情况下，才允许跳过上游，直接合并到下游分支。当有稳定版本需要发布时，我们会从master拉一个新的分支作为发布版本时的分支。不应在这些分支上开发新功能，只有在修补错误时才可以。对于“版本发布”项目，推荐的做法是，对于每一个稳定版本，都要从master分支中拉取一个分支，比如2-3-stable、2-4-stable等。以后只有修复了bug才允许将代码合并到这些分支中，此时需要更新minor版本号。4.总结好了，以上就是Git常用的三个好玩的进程。其实我们在自己的开发上大可不必如此死板。三个分支的功能也和前面介绍的GitFlow一致。在此基础上，其他基本没有太多限制，相对自由。参考：https://www.cnblogs.com/sloong/p/5868292.htmlhttps://medium.com/@lf2lf2111/%E4%B8%89%E7%A8%AE%E7%89%88%E6%8E%A7%E6%B5%81%E7%A8%8B-29c82f5d4469https://cloud.tencent.com/developer/article/1646937本文转载自微信公众号《江南一点雨》，可以使用以下二维码关注。转载本文请联系江南一点鱼公众号。
