作为开发者，每天都需要提交代码，但是你真的了解代码提交吗？本文引导大家熟悉常用的代码提交方式，大家可以根据自己公司的开发模式进行打卡。代码提交方式可以用一个专业术语来描述：代码工作流。SVN时代，大家会使用集中式的工作流，大家都会把代码合并到一个主库分支；随着技术的演进，诞生了以Git代码管理工具为代表的分布式工作流，并在Git的基础上逐渐出现了多种代码管理工作流：功能分支工作流、Gitflow工作流、Forking工作流。搬完小板凳，下面我们一一讲解。CentralizedWorkflowCentralizedWorkflow是用过SVN的同学一定非常熟悉的一种工作方式。让我们想想SVN下的协作体验。不同的开发同学需要将本地修改一一提交到服务器。如果有冲突，先解决本地冲突再提交。在这个过程中，远程服务器就像一个中心化的管理者，管理着大家的代码提交，所以SVN的开发协作过程是一个典型的中心化工作流。如果改用Git来维护代码仓库，而开发者又不熟悉Git的分支模式，是否可以使用Git来实现类似的集中式工作流？答案是当然可以。每个开发人员将远程仓库中的代码克隆到自己的本地仓库中。提交代码时先提交到本地仓库，再推送到远程仓库。这种模式与SVN相比，只是多了一个本地仓库。有SVN经验的开发者可以很快熟悉这种模式。前几年，很多公司都把Git当作SVN来使用。从提交记录来看，集中式工作流程通常是直线前进的，如下图：一切，类似于用倚天剑，用龙刀切菜，太浪费了。功能分支工作流的集中式工作流存在很大问题。随着团队人数的不断增加，大家每次提交代码都可能会遇到冲突。提交代码解决冲突需要一分钟，一小时。为了方便大家并发工作，通常会在master主干分支的基础上拉取若干个feature分支。每个开发人员都专注于自己的分支。提交代码时，他们直接提交到本地库的feature分支。在合并到主分支之前通常会拉取最新的代码。如果有冲突，则在本地解决冲突，提交MR申请，将feature分支合并到主分支。功能分支工作流在功能分支工作流下，代码不会直接合并到主分支（master），MR（MergeRequest）通常是通过其他分支提交，这使得集成一些自动化操作变得简单可行。提交MR后，团队成员开始观看您编写的代码。他们可以提交codereview和投票（vote），teamcommitter会据此合并或拒绝你的MR。代码提交过程的大量新功能合并到master分支后，很容易造成master分支的质量不稳定。不稳定有什么问题？比如网上突然有bug需要解决。可能只修改一行代码就可以解决，但是master分支已经加入了大量的新特性，测试人员还没来得及测试。最稳妥的办法就是把代码回滚到上面一个版本发布的时间节点修改一行代码是不是太麻烦了？为了解决这些问题，VincentDriessen根据开发实践总结出一套Git分支管理流程和规范，下面将详细介绍。Gitflow工作流Gitflow工作流是目前非常成熟的解决方案。它围绕项目发布定义了一个严格的分支模型。通过为代码开发、项目发布和维护分配独立的分支，使项目的迭代过程更加顺畅。与以往的集中式工作流和功能分支工作流相比，Gitflow工作流有两个常驻分支：主分支master和开发分支develop。与功能分支工作流相比，Gitflow工作流没有增加任何新的概念或命令。它将特定角色分配给不同的分支机构，并定义它们应该如何以及何时进行交互。除了功能分支之外，单独的分支还用于准备发布、维护发布和记录发布。Gitflow常用分支：开发主分支：master分支master分支的代码可以直接部署到生产环境。为了保持稳定性，一般不会直接在这个分支上修改代码，而是从其他分支合并而来。开发主分支：developbranchdevelop分支是主要的开发分支，包含所有要发布到下一个版本的代码，主要是从feature分支合并而来。临时分支：特性分支特性分支主要用于开发一个新的特性。一旦开发完成，会合并到develop分支，feature分支会立即删除。临时分支：release分支当需要发布新的release版本时，会在develop分支的基础上创建release分支，经过测试人员全面测试后，合并到master分支和develop分支。临时分支：hotfix分支当生产环境发现新的bug，需要紧急修复时，会创建一个hotfix分支，经过全面测试后，合并到master和develop分支，然后分支将被删除。分支机构如何协同工作？(1)master/develop分支原则上，master分支上的所有commit都应该打上tag，因为一般情况下，master上是没有直接commit的；devlop分支是基于master分支创建的，与master分支相同。被删除。develop从master拉取后，会独立开发，不会直接和master挂钩。主分支的工作流程(2)特性分支通常一个独立的特性会在develop的基础上拉一个特性分支，特性分支之间没有交互，互不影响。特性分支一旦开发完成，会立即合并到develop分支（使用mergerequest或pullrequest），特性分支的生命周期也随之结束。特性分支工作流程(3)发布分支通常一个迭代上线时会拉取一个发布分支。开发人员开发完所有代码后，已合并到develop分支。这时会在develop分支的基础上拉出一个release分支，测试人员会在这个分支的基础上进行测试。发布分支工作流程(4)hotfix分支hotfix分支是在master分支的基础上创建的。开发完成后需要回master同时开发branch，同时在master上打一个tag。Hotfix分支工作流程分支命名规范团队可以就每个分支的命名风格达成一致。这里有一个例子，可以参考：feature分支：以feature_开头，如feature_orderrelease分支：以release_开头，如release_v1.0hotfix分支：以hotfix_开头，如hotfix_20210117tag：如果是release分支合并，从release_开始，如果是hotfix分支合并，从hotfix_开始。Forking工作流Forking工作流是以Github为代表的一种代码协作方式。开发人员通过克隆（fork）源代码仓库来编写代码。完成后会发起pullrequest，源仓库作者可以选择是否接受PR。下面通过Github详细讲解Forking工作流模式。随便在Github上找一个开源项目，https://github.com/smileArchitect/JavaMap右上角有三个按钮：Watch,Star,ForkWatch表示关注，点击后会立即收到通知您对项目的任何更改；Star类似于点赞的意思，对开源项目多点赞，鼓励作者；Fork本意是分叉，实际上是克隆的意思。点击之后，就会把项目复制到仓库中自己的githubremote中。fork示例在本地执行gitclone命令将代码克隆到本地，修改操作后提交代码推送到个人远程仓库，然后在界面发起pullrequest，项目原作者会看到你提交的PR，根据Submitted的质量，作者可以选择接受或者拒绝。Github工作流程Forking工作流程非常适合Github这样的开源项目，任何开发者都可以通过fork+pullrequest的方式为项目贡献代码。总结文章介绍了四种工作流程，分别是中心化工作流程、功能分支工作流程、Gitflow工作流程和Forking工作流程。集中式工作流在SVN时代比较普遍，转用Git后不推荐使用这种方式。特性分支工作流程通常是一个主干主干分支+多个特性分支，一般适用于小团队开发。Gitflow工作流是在功能分支工作流的基础上进一步演化而来的。采用master+develop双master分支加多个临时功能分支。这是一种非常成熟的代码协同管理方式，推荐大家使用。Forking工作流主要采用fork+pullrequest的模式进行协作，主要用于开源项目。最后：这四种工作流方式各有特点，开发团队可以根据自己的特点进行选择。他们不必严格拘泥于某种方法，适合自己的才是最好的。你学会了吗？
