点击原文进行投票
作为开发者我必须每天提交代码，你真的知道代码提交吗？ 本文介绍了常用的代码提交方法。 大家可以根据自己公司的开发模式就座。
代码的提交方法可以用专业术语描述。 代码工作流，SVN时代大家都使用集中式工作流，全员分支到一个主库进行代码合并； 随着技术的发展，以Git为代表的分布式代码管理工具应运而生，基于Git，出现了各种代码管理工作流，包括功能分支工作流、Gitflow工作流和Forking工作流。 移动长椅，下面逐一说明。
集中式工作流集中式工作流的工作方式，我想使用过SVN的学生都很熟悉。 考虑一下在SVN上的合作吧。 某些开发人员可能需要将本地更改依次提交到服务器。 如果存在冲突，请在解决本地冲突后提交。 在此过程中，远程服务器就像一个集中的管理员，负责管理所有人的代码提交，因此SVN开发合作过程是一个典型的集中工作流。
如果切换到Git并维护代码屋，但开发人员不熟悉Git分支模式，Git是否可以提供类似的集中式工作流？ 答案当然可以。
各开发商将远程仓库的代码克隆成自己的本地仓库，提交代码时先提交本地仓库，然后推送至远程仓库。
这种机型与SVN相比只增加了一个本地仓库，有了SVN的经验，开发者也很快就习惯了这种机型，不久前有很多公司将Git作为SVN使用。
从提交记录来看，集中化工作流通常按如下图所示一直进行。
集中提交代码的流程总结：不建议使用此模型。 因为完全没有Git的作用，就像用李天剑屠龙刀切菜一样，太可惜了。
功能分支工作流集中式工作流存在很大问题。 随着团队中人员的增加，每次提交代码时都可能发生冲突，提交代码一分钟即可解决冲突一个小时。
为了让大家同时工作，通常根据master的主分支采取一些特性分支。 每个开发人员都关注自己的分支，需要提交代码时直接提交到本地库的特性分支，并在合并到主分支之前获取最新代码。 如果有冲突，首先在本地解决冲突，解决MR申请的提交，将特性分支合并到主分支中。
功能分支工作流位于功能分支工作流的下面，它通常通过另一个分支提交合并多个自动化操作，而不是将代码直接耦合到主干分支(master )。
提交MR后，团队成员可以开始看你写的代码，然后进行“查看意见”(code review )，“投票”(vote )，团队committer据此合并或拒绝你的MR
代码发送过程的新功能大量集成到主分支后，主分支的质量容易不稳定，不稳定会有什么问题？ 例如，如果在线上突然出现错误，可能只需修改一行代码就可以解决，但master分支已经内置了许多新功能，测试人员还来不及进行测试。 最稳妥的方法是将代码返回到上次发布的时间节点，并根据该节点修改另一行代码。 是不是太麻烦了？
为了解决这些问题，Vincent Driessen大人物根据开发实践总结了Git分支管理的流程和规范，现详细介绍如下。
Gitflow工作流Gitflow工作流是一个非常成熟的方案，它定义了以项目发布为中心的严格分支模型，并为代码开发、项目发布和维护分配独立的分支，从而实现项目迭代过程与以前的集中式工作流和功能分支工作流不同，Gitflow工作流驻留的分支有主干分支主节点和开发分支Devver
与功能分支工作流相比，Gitflow工作流没有添加新概念或命令。 Gitflow工作流为不同的分支分配特定的角色，并定义它们应如何和何时交互。 除了功能分支之外，还分别使用了不同的分支来准备发布、维护发布和记录发布。
Gitflow 常见分支
ng>：开发主分支：master 分支
master 分支的代码是可以直接部署到生成环境的，为了保持稳定性一般不会直接在这个分支上修改代码，都是通过其他分支合并过来的。
开发主分支：develop分支
develop 分支是主开发分支，包含所有要发布到下一个release的代码，主要是由feature分支合并过来的。
临时分支：feature 分支
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）feature 分支
通常一个独立的特性都会基于 develop 拉出一个 feature 分支，feature 分支之间没有任何交互，互不影响。feature 分支一旦开发完成后会立马合入 develop 分支（采用 merge request 或者 pull request），feature 分支的生命周期也随之结束。
feature 分支工作流程（3）release 分支
通常一个迭代上线会拉一个release 分支，开发人员开发完毕所有的代码都已合入 develop 分支，这时候会基于 develop 分支拉出一个 release 分支，测试人员基于该分支进行测试。
release 分支工作流程（4）hotfix 分支
hotfix分支基于master分支创建，开发完后需要同时回合到master和develop分支，同时在master上打一个tag。
hotfix 分支工作流程分支命名规范
团队内部可以约定每个分支的命名样式，这里举个例子，大家可以参考：
feature分支：以feature_开头，如 feature_order
release分支：以release_开头，如 release_v1.0
hotfix分支：以hotfix_开头，如hotfix_20210117
tag标记：如果是release分支合并，则以release_开头，如果是hotfix分支合并，则以hotfix_开头。
Forking 工作流Forking 工作流是以 Github 为代表的一种代码协作方式，开发者通过克隆（fork）源仓库进行编写代码，一旦完成会发起 pull request，源仓库作者可以选择是否接受该 PR。
下面通过 Github 详细讲解 Forking 工作流模式。
随便找一个Github 开源项目，
https://github.com/smileArchitect/JavaMap
右上角有三个按钮：Watch，Star，Fork
Watch 是关注的意思，一旦你点击了之后该项目有任何改动都会第一时间通知到你；
Star 类似于点赞的意思，多给开源项目点个赞，鼓励一下作者；
Fork 本意是分叉，实际上是克隆的意思，点了之后会将该项目拷贝一份到自己的 github 远程仓库中。
fork 示例在本地执行 git clone 命令将代码克隆到本地，一顿修改操作后提交代码并 push到个人远程仓库中，然后在界面上发起 pull request，项目的原作者会看到你提交的 PR，根据提交的质量作者可以选择接受或拒绝。
Github 工作流程Forking 工作流非常适合于类似 Github 这种开源项目，任何一个开发者都可以通过fork + pull request 向项目中贡献代码。
总结文章介绍了四种工作流，分别是集中式工作流，功能分支工作流，Gitflow 工作流，Forking 工作流。
集中式工作流在 SVN 时代比较常见，切到 Git 后不建议再使用这种方式了。
功能分支工作流通常是一个主干 master 分支 + 多个 feature 分支，一般适用于小团队开发。
Gitflow 工作流是在功能分支工作流的基础上进一步演进而来，采用 master + develop 双主分支再加上多个临时功能分支，这是一个非常成熟的代码协作管理的方式，推荐大家使用。
Forking 工作流主要采取 fork + pull request 的模式进行协作，主要用于开源项目。
最后：这四种工作流方式各有特色，开发团队可根据自身的特点去选择，不必严格拘泥于某一种方式，适合自己的才是最优的。大家学会了吗？
年底了胖哥除了你们颗粒无收
2021-01-23
在使用Git时你应该这样提交代码
2021-01-21
21日同群友在B站技术交流实况录像
2021-01-22