git branch最佳实践

一. 主分支

1. master分支
   生产环境下的正式版本
2. develop分支
   • nightly build 自动化任务的来源
   • 每当 develop 分支到达一个稳定的阶段，可以对外发布, 就将该分支合并到 master 分支, 并打上tag

二. 支持分支

(解决突发问题, 并行处理特性, 跟踪修复线上问题等, 最终都会被删除掉。)

1. feature分支

1. 特点:

   • 来自develop分支
   • 必须合并回develop分支
   • 仅存在于开发者的代码库中, 不存在于origin远程库中

2. 命名规则:
   除了master, develop, release-, or hotfix- 以外的任何名字都可以

3. 目的
   有时在开发过程中, 不确定某一特性是否将在下个版本出现, 所以单独拿出一个分支进行开发. 开发完毕后, 若想在下次发布中带上, 就合并回develop分支; 若不想再继续使用那个特性, 就彻底废除

4. 生命周期:

   1. 从 develop 创建feature分支

    $ git checkout -b myfeature develop
    Switched to a new branch "myfeature"
   

   2. 如果该特性确实想保留, 则开发完这个特性后, 需要把该feature分支合并回develop分支, 最终让下次release分支中包含本特性

   $ git checkout develop
   Switched to branch 'develop'
   $ git merge --no-ff myfeature
   Updating ea1b82a..05e9557
   (Summary of changes)
   $ git branch -d myfeature
   Deleted branch myfeature (was 05e9557).
   $ git push origin develop
   

   --no-ff 标记使得合并操作总是产生一次新的提交，哪怕合并操作可以快速完成。这个标记避免将 feature 分支和团队协作的所有提交的历史信息混在主分支的其它提交之后。

2. release分支

1. 特点:

   • 来自develop分支
   • 必须合并回：develop 和 master

2. 分支命名规范：
   release-*

3. 目的
   完成所有预期的开发任务时，就可以从 develop 分支创建出 release 分支. 新创建的realse分上可以进行bug fix, 但是禁止在release分支上进行重大特性的更新

4. release分支的生命周期

   • (1) 从develop分支创建release分支

   $ git checkout -b release-1.2 develop
       Switched to a new branch "release-1.2"
   $ ./bump-version.sh 1.2
       Files modified successfully, version bumped to 1.2.
   $ git commit -a -m "Bumped version 
       number to 1.2"
       [release-1.2 74d9424] Bumped version number to 1.2
       1 files changed, 1 insertions(+), 1 deletions(-)
   

   • (2) 完成release分支
     当release分支上的bug全部修复, 可以达到真正的发布状态时, 需要进行两步操作
     • (2.1) 将release分支合并回master分支, 并打上tag, 标明历史版本

     $ git checkout master
     Switched to branch 'master'
     $ git merge --no-ff release-1.2
      Merge made by recursive.
      (Summary of changes)
     $ git tag -a 1.2
     

     • (2.2) 将release分支合并回develop分支, 确保develop分支上包含了release上bug fix的代码

     $ git checkout develop
      Switched to branch 'develop'
     $ git merge --no-ff release-1.2
      Merge made by recursive.
      (Summary of changes)
     

   • (3) 在将release合并回master和develop分支后, 将release分支删除

   $ git branch -d release-1.2
   Deleted branch release-1.2 (was ff452fe).
   

3. hotfix分支

1. 特性:

   • 来自于master
   • 必须合并回master和develop

2. 命名规则为:
   hotfix-*

3. 目的
   hotfix分支用于生产环境中的代码发生严重bug, 需要立刻处理并打新包替换生产环境代码时. 因此, 他会从master分支对应的tag下创建出来 (master分支中的每个tag都标记了一次成功的版本发布). 同时, 在hotfix分支上修复bug并不影响develop分支上的开发人员

4. 生命周期

   • (1) 从master分支创建出hotfix分支, 注意hotfix分支中药标明版本号

   $ git checkout -b hotfix-1.2.1 master
   Switched to a new branch "hotfix-1.2.1"
   $ ./bump-version.sh 1.2.1
   Files modified successfully, version bumped to 1.2.1.
   $ git commit -a -m "Bumped version number to 1.2.1"
   [hotfix-1.2.1 41e61bb] Bumped version number to 1.2.1
   1 files changed, 1 insertions(+), 1 deletions(-)
   

   • (2) bug修复过后, 合并回master分支和develop分支, 其中master分支要打上tag
     • (2.1) 合并回master分支

     $ git checkout master
      Switched to branch 'master'
     $ git merge --no-ff hotfix-1.2.1
      Merge made by recursive.
      (Summary of changes)
     $ git tag -a 1.2.1
     

     • (2.2) 合并回develop分支

     $ git checkout develop
     Switched to branch 'develop'
     $ git merge --no-ff hotfix-1.2.1
      Merge made by recursive.
      (Summary of changes)
     

[Reference];
https://nvie.com/posts/a-successful-git-branching-model/