长话短说，仓库内部采用 Git flow 模式，仓库之间采用 GitHub flow模式。
开始之前需要先了解下什么是Git flow什么又是GitHub flow。
这两个不是谁替代谁的关系，而是他们适用的场景不一样，Git flow专注的是软件发布模型，作为一个商业软件，只有一个master分支是远远不够的，因为你的用户不太可能都采用同样的版本，并且在有新版本后统一更新，即使是互联网只有服务器端的项目也会面临组织内部不同服务之间的版本依赖问题。因此，遵循Git flow的建议，辅以Git flow extensions在仓库内部维护完整的分支和Tag，如同它文档标题一样，这样的分支模型会让你达到成功的彼岸。
而GitHub flow模型关注的则是协作，抛开个人solo的项目，每个项目都会面临协作的问题。此时，一个直观的想法是给其他人开放Developer权限，这里告诉你千万不要这样干，尤其是在这个人没有经过专业训练的前提下。正确的姿势应该是，Fork -> Pull Request -> Merge。 Git是一个分布式的仓库，应该按照分布式的思维方式来工作，合作应该是仓库和仓库之间的事情。这种分布式的思维应该运用在每个Git仓库中，GitHub上的仓库和你本地的仓库，即使都是你的，并且都是你一个人在维护，那么也需要把它理解为这是两个仓库，在维护过程中你要扮演两个角色，一个是Developer，将代码clone到本地之后，采用Git flow的模式进行工作。然后再扮演另一个Master的角色，来维护Github那个。
So, 在真实的工作中我们应该将这两者结合起来。
网友评论