Gitflow

git-flow源于2010年一篇A successful Git branching model的文章，在这10年间被很多团队采用并成为了一个事实上的“标准做法”。

主分支

在这种模型下，git仓库中有两个分支是一直存在的：

• origin/master(或者main)：这个分支上的最新代码永远是production-ready的
• origin/develop：这个分支上的代码永远是下一个发布的最新的交付代码。也可以称为“集成分支”，用于进行每日构建（nightly builds）

当develop分支上的代码达到了上线的标准之后，这些改动就会merge回master分支，并打上release版本号的标签。合并代码到master也就意味着新的产品发布，可以使用web hook来自动进行发布过程：每当master分支有commit的时候自动进行编译、发布等操作发布到生产环境。

辅助分支

除了主分支外，在开发的过程中还有一些辅助分支用来完成开发、发布以及线上问题修复等。这些分支都是临时性的，最终会被从git中移除。

feature分支

feature分支用来开发在未来发布的新功能，但具体在哪个版本进行发布可能还是未知的，它：

• 从develop分支拉取创建
• 开发完成后合并回develop分支（意味着下一次发布会包含这个新功能）
• 或者被丢弃掉（例如发现这个功能影响用户体验）

git checkout -b myfeature develop

git checkout develop
git merge --no-ff myfeature
git branch -d myfeature
git push origin develop

release分支

release分支用来进行发布的准备工作，其：

• 从develop分支拉取创建
• 完成后必须合并回develop、master分支
• 命名惯例是release-*

releas分支可以在生产发布之前做最后的一些操作，例如：

• 一些小的bug修复
• 更新发布产品的元数据，如版本号等

这样，当release分支创建完成之后，develop分支可以继续下一个发布的开发工作。拉取release分支的时机为，develop分支几乎达到了可以发布的状态，至少所有这次发布的feature需要首先合并完成到develop分支中。如果还有其他的不希望在这次上线发布的feature，必须要等到release分支拉完之后才能合并到develop上。

git checkout -b release-1.2 develop

# 在release分支更新版本号
./bump-version.sh 1.2
git commit -a -m "Bumped version number to 1.2"

# merge回master并打tag
git checkout master
git merge --no-ff release-1.2
git tag -a 1.2

# merge回develop
git checkout develop
git merge --no-ff release-1.2

# 删除分支
git branch -d release-1.2

hotfix分支

hotfix分支用于紧急修复当前线上的版本的问题，其：

• 从master分支拉取创建
• 完成后合并会develop和master。有特殊情况就是，如果当前有release分支（意味着这个releas还没有上线，上线之后应该删除release分支），那么应该合并到release分支而不是直接到develop分支
• 命名惯例为hotfix-*

git checkout -b hotfix-1.2.1 master

# 检出hotfix分支之后，首先更新版本号
./bump-version.sh 1.2.1
git commit -a -m "Bumped version number to 1.2.1"

# ...
# 修复问题之后，提交
git commit -m "Fixed severe production problem"
# merge到master以便上线到生产
git checkout master
git merge --no-ff hotfix-1.2.1

# 打这次上线的tag
git tag -a 1.2.1

# merge回develop
git checkout develop
git merge --no-ff hotfix-1.2.1

# 删除hotfix分支
git branch -d hotfix-1.2.1