Git分支管理总结篇

目录

前言

1 master - 主干分支

2 develop branches - 主分支

2.1 创建主分支 

 2.2 合并主分支

3 feature branches - 新功能分支

3.1 创建新功能分支

3.2 合并新功能分支

4 release branches - 新版本分支

 4.1 创建新版本分支

4.2 合并新版本分支

5 hotfix branches - 热修补分支

 5.1 创建热修补分支

5.2 合并热修补分支

---

前言

        在使用 Git 进行版本控制时，随着迭代版本的推进，会出现多版本并行的情况，版本管理是件很头痛的事情。
        那么Git是如何做到的呢？答案是【分支管理】。
        Git也是为此而生的，即分散又集中。
        本文将结合相关资料进行整理加以说明。

• master 主要分支 - 主线分支，HEAD 指向的代码与稳定的生产环境代码同步
• develop 主要分支 - 开发线分支，HEAD 指向的代码是最新的开发进度，代表了面向下一版本 release 的最新代码更改，当开发线的代码到达稳定状态并可以发布 release 时，develop 线的代码将被合并到 master 中，并以一个新的 release 版本号 tag
• feature 辅助分支 - 新功能开发分支 伴随一个新功能开发而存在（多版本并行在于此）
• release 辅助分支 - 版本发布分支 在版本准备发布和发布成功之间存在的临时分支，代表了即将发布的代码状态。
• hotfix 辅助分支 - 热修补分支 生产环境出现 bug 需要紧急修复时候创建的

分支名称	分支类型	从何处检出	合并到何处
master	主要	-	-
develop	主要	-	-
feature	辅助支撑	develop	develop
release	辅助支撑	develop	develop & master
hotfix	辅助支撑	master	develop & master

 

1 master - 主干分支

 中心代码库永远维持着两个主要的分支：master、develop。

每次版本合并都要添加tag。

2 develop branches - 主分支

中心代码库永远维持着两个主要的分支：master、develop。

在 origin 上的 master 分支和每个 git 用户的保持一致。而和 master 分支并行的另一个分支叫做 develop。我们认为 origin/develop 是其 HEAD 源代码总是代表了最后一次交付的可以赶上下一次发布的状态的主分支。每当 develop 分支到达一个稳定的阶段，可以对外发布时，所有的改变都会被合并到 master 分支，并打一个发布版本的 tag。

2.1 创建主分支 

git checkout -b develop master
Switched to a new branch "develop"

 2.2 合并主分支

git checkout master
git merge --no-ff develop
git push orign master

3 feature branches - 新功能分支

新功能分支是 branch off from develop，它的生命周期伴随着开发某一特定新功能，新功能开发完成后，将 feature 分支 merge 到 develop 中，删除feature 分支。

3.1 创建新功能分支

git checkout -b newfeature develop
Switched to a new branch "newfeature"

3.2 合并新功能分支

git checkout develop
git merge --no-ff newfeature
git push orign develop
git branch -d newfeature

4 release branches - 新版本分支

新版本分支创建于生产环境最新 release 发布前夕，从 develop 分支中 checkout 出来，此时允许在 release 分支上进行小规模的 bugfix 并准备版本号等信息。而此时 develop 分支可以继续工作，接收下一个版本的代码改动。

 4.1 创建新版本分支

git checkout -b release-1.2.0 develop
./some-shell-to-change-file-version-number.sh
git commit -a -m "Bumped version number to 1.2.0"

4.2 合并新版本分支

当新版本在进行细微调整后成为真正的新版本时，将会通过以下三步完成一个新版本

1. 将新版本分支合并到 master 分支中，并对 master 分支打上 tag 方便引用（master 分支原则上只接受新版本的 merge）

git checkout master
git merge —no-ff release-1.2.0
git tag -a 1.2.0

1. 将新版本分支合并到 develop 分支中，将新版本发布期的更改添加到 develop 代码中

git checkout develop
git merge —no-ff release-1.2.0

1. 删除release分支

git branch -d release-1.2.0

5 hotfix branches - 热修补分支

当生产环境出现重大问题时，从master上直接checkout，此时可以对master的版本增加一个小版本号用以修复这个bug。此时其他开发人员可以继续在develop分支上工作而不必受到影响。问题修改完成后，将会首先合并热修补分支到master分支中修复生产环境问题，进而合并到develop分支中（**如果存在release分支，应先合并到release中，再由release合并到develop中，但如果develop分支等不及这个bug的修复，可以同时合并到develop分支中**）

 5.1 创建热修补分支

# 由master派发hotfix
git checkout -b hotfix-1.2.1 master
./change-file-version-number.sh
git commit -a -m "Bumped version number to 1.2.1"
# 修复完成后
git commit -m "Fixed severe production problem"

5.2 合并热修补分支

# 首先将hotfix合并到master中，解决问题
git checkout master
git merge --no-ff hotfix-1.2.1
git tag -a 1.2.1

# 再将hotfix合并到develop中
# 如果存在release分支，应先合并到release中，再由release合并到develop中，
# 但如果develop分支等不及这个bug的修复，可以同时合并到develop分支中
git checkout develop
git merge --no-ff hotfix-1.2.1

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