Git工作流

Git是非常灵活的,在一个团队中要用好Git就要求所有人遵守一定的规范,这个规范的核心是大家采用怎样的一个流程来开展工作。这就是Git工作流。

并没有一个“正确”的Git工作流,团队的习惯不同、项目的规模不同,都有可能采用不同的Git工作流。Git工作流不是越复杂越好,也不是越简单越好,而是越适合越好。

一、中心工作流(Centralized Workflow)

一个中心,各人本地有一个克隆。

各人在本地克隆上修改,修改后的提交也是提交到本地克隆里。

最后要把本地提交的修改推送到中心仓库里。

这时,有可能别人已经对中心仓库进行了修改。那么就需要把别人的修改拉下来,基于别人修改后的内容把自己的修改叠加上去,这个是由git自动做的,除非这个过程出现了冲突,那就需要人工解决冲突了。

二、特性分支工作流(Feature branching, 在Github中又称为Github flow)

一个系统在进行升级时,会有多个新特性同时开发。如果新特性在开发过程中提交到中心仓库,那么中心仓库的代码就会处于不稳定状态。为了解决这个问题,产生了特性分支工作流。

对于要开发的每一个新特性,创建一个分支,相应地,原先的主干称为master。

此后的操作基于新建的这个分支,这部分与中心工作流相同。

当这个分支开发好了,就要合并进主分支,这时要发起一个pull request,意思就是,兄弟们呀,拉我一把,把我拉进主干吧。这时是同行评审的好时机。

评审并修改后,正式合并。这时又会有rebase和conflict,与中心工作流相同。

三、Gitflow工作流(Gitflow Workflow)

我们经常会看到某个软件有正式版、测试版等等。Gitflow工作流就是创建多个分支,在master上分出develop分支,用于开发,新特性的开发在develop上分出feature分支。在develop上分出release分支,用于发布版本,在master上分出hotfix用于打补丁。各条分支上的操作与Feature branching相同。

四、分叉工作流(Forking Workflow)

以上各种工作流都是一个中心仓库,Forking Workflow是每个开发人员有一个中心仓库和一个本地仓库。开源软件的开发往往是采取这种模式。贡献者没有权限写入软件的“官方”仓库,只能提交pull request,由软件的维护者拉进去。

『参考资料』

Comparing Workflows (https://www.atlassian.com/git/tutorials/comparing-workflows

Understanding the GitHub flow (https://guides.github.com/introduction/flow/

Leave a Reply

Your email address will not be published. Required fields are marked *