用手画了11张图终于搞明白了Git工作流，我怀疑你用的是假 Git

号外号外！《死磕 Java 并发编程》系列连载中，大家可以关注一波：

「死磕 Java 并发编程05」阿里面试失败后，一气之下我图解了Java中18把锁

「死磕 Java 并发编程04」说说Java Atomic 原子类的实现原理

「死磕 Java 并发编程03」阿里二面，面试官：说说 Java CAS 原理？

「死磕 Java 并发编程02」面试官：说说什么是 Java 内存模型（JMM）？

「死磕 Java 并发编程01」10张图告诉你Java并发多线程那些破事

目录

集中式工作流

功能分支工作流

Gitflow 工作流

Forking 工作流

总结

作为一个开发人员每天必不可少要提交代码，但是你真的懂代码提交吗？这篇文章带领大家熟悉一下常用的代码提交方式，大家可以根据自己所在公司团队的开发模式对号入座。

代码提交方式可以用一个专业术语描述：代码工作流，在 SVN 时代大家会使用集中式工作流，所有人都往一个主库分支合入代码；随着技术的演进，以 Git 为代表的分布式代码管理工具横空出世，在 Git 的基础上又逐渐出现了多种代码管理工作流：功能分支工作流，Gitflow 工作流，Forking 工作流。搬好小板凳，下面一一位大家讲解。

集中式工作流

集中式工作流这种工作方式对于使用过SVN的同学想必会非常的熟悉，让我们思考下在 SVN下的协作体验，不同的开发同学需要依次将本地的修改提交到服务器，如果有冲突就先解决本地的冲突再提交，这个过程中远端的服务器就像是一个集中管理者，管理着所有人的代码提交，所以 SVN的开发协作流程就是典型的集中式工作流。

如果切换到 Git 来维护代码仓，但是开发人员又对 Git 的分支模式不熟悉，能不能用 Git 实现类似的集中式工作流呢？答案是当然可以。

每个开发人员将远程仓库的代码 clone 下来变成了属于自己的本地仓库，提交代码时先提交至本地仓库，然后再推送到远程仓库。

这种模式相比 SVN 只是多了一个本地仓库而已，有了 SVN 的经验开发人员也很快能熟悉这种模式，在前些年有很多公司都是将 Git 作为 SVN 来用的。

从提交记录来看，集中式工作流通常是一条直线往前走，如下图：