Git 分支策略和工作流程

Git 工作流中常见的三种分支策略：GitFlow、GitHubFlow 以及 GitLabFlow。

Git Flow

就像代码需要代码规范一样，代码管理同样需要一个清晰的流程和规范

Vincent Driessen 同学为了解决这个问题提出了 A Successful Git Branching Model

Git Flow 常用分支

• Production 分支

也就是我们经常使用的Master分支，这个分支最近发布到生产环境的代码，最近发布的Release， 这个分支只能从其他分支合并，不能在这个分支直接修改

• Develop 分支

这个分支是我们是我们的主开发分支，包含所有要发布到下一个Release的代码，这个主要合并与其他分支，比如Feature分支

• Feature 分支

这个分支主要是用来开发一个新的功能，一旦开发完成，我们合并回Develop分支进入下一个Release

• Release 分支

当你需要一个发布一个新Release的时候，我们基于Develop分支创建一个Release分支，完成Release后，我们合并到Master和Develop分支

• Hotfix 分支

当我们在Production发现新的Bug时候，我们需要创建一个Hotfix, 完成Hotfix后，我们合并回Master和Develop分支，所以Hotfix的改动会进入下一个Release

Master和Developer需要我们长期维护，也是我们开发的主干线。其余分支都是临时分支。

Git Flow 如何工作

初始分支

所有在Master分支上的Commit应该Tag

Feature 分支

分支名 feature/*

Feature分支做完后，必须合并回Develop分支, 合并完分支后一般会删点这个Feature分支，但是我们也可以保留

Release分支

分支名 release/*

Release分支基于Develop分支创建，打完Release分之后，我们可以在这个Release分支上测试，修改Bug等。同时，其它开发人员可以基于开发新的Feature (记住：一旦打了Release分支之后不要从Develop分支上合并新的改动到Release分支)

发布Release分支时，合并Release到Master和Develop， 同时在Master分支上打个Tag记住Release版本号，然后可以删除Release分支了。

维护分支 Hotfix

分支名 hotfix/*

hotfix分支基于Master分支创建，开发完后需要合并回Master和Develop分支，同时在Master上打一个tag

Git-flow AVH

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

brew install git-flow-avh
# init
git flow init
# feature
git flow feature help
# 新建功能开发分支
git flow feature start <feature_name>
# 提交分支远程协同开发
git flow feature publish <feature_name>
# 提交所有修改后
git flow feature finish <feature_name>
# release
git flow release start v1.0.0
git flow release finish v1.0.0
# hotfix
git flow hotfix start v1.0.0-patch
git flow hotfix finish v1.0.0-patch

GUI 工具 SourceTree

https://www.sourcetreeapp.com/

GitLab FLow

• https://about.gitlab.com/topics/version-control/what-is-gitlab-flow/
• https://about.gitlab.com/topics/version-control/what-are-gitlab-flow-best-practices/

GitLab flow 中的环境分支

拥有一个可以自动更新到master分支的环境可能是个好主意。只是，在这种情况下，这个环境的名称可能与分支的名称不同。假设你有一个预发布环境（staging environment），一个预生产环境（pre-production environment），以及一个生产环境（production environment）。在这种情况下，将master分支部署到预发布环境。要部署到预生产环境，请创建一个从master分支到预生产分支的合并请求（merge request）。通过将预生产分支合并到生产分支来实现上线。这种工作流（在其中提交只流向下游）可以确保所有东西在所有环境中都得到了测试。如果你需要cherry-pick（挑选）一个带有热修复的提交，通常是在功能分支上开发，然后用合并请求将其合并到master。在这种情况下，先不要删除功能分支。如果master通过了自动测试，你再把这个功能分支合并到其他分支。如果这因为需要更多人工测试而无法做到，你可以把来自功能分支的合并请求发送给下游分支。

GitLab flow 中的发布分支

只有当你需要向外界发布软件时，你才需要使用发布分支。在这种情况下，每个分支都包含一个次要版本（minor version），如2-3-stable或2-4-stable。以master为起点创建稳定分支，并尽可能晚地创建。通过这样做，你可以最大限度地减少不得不将错误修复应用到多个分支上的耗时。在公布一个发布分支后，只向该分支添加严重错误修复。如果可能的话，先把这些错误修复合并到master，然后再把它们cherry-pick到发布分支。如果一开始就合并到发布分支，你可能会忘记把它们cherry-pick到master上，然后你就会在随后的发布中遇到同样的错误。先合并到master分支，然后再cherry-pick到发布分支叫做 “上游优先 “政策，Google 和 Red Hat 也是这样实践的。每当你在发布分支中加入一个错误修复，就通过设置一个新的标签来增大补丁版本（patch version）（以符合语义化版本）。有些项目也有一个稳定分支，它指向与最新发布的分支相同的提交。在这种流程下通常都不会有一个生产分支（或Git flow的master分支）。