一、分支管理模型选型

Branching Model在业界有多种规范，如：Gitflow、AoneFlow、OneFlow等，Branching Model的复杂程度取决于实际开发团队和代码规模，自动化程度等因素，实际使用时需要结合当前具体情况精简。但随着情况变化，当前的Model可能会不适用，需要定期Review并优化模型选型。

二、Branching Model的选型依据参考

1. 是否一个Repository同时有多人在分别开发不同feature，或者做bugfix，且需要同时deploy到不同环境。eg. dev, pre, production, grayscale etc.
   • 解决方案：每个环境需要一个对应的branch或tag
2. 是否需要同时维护多个长期版本
   • 解决方案：需要多个base branch
3. 是否需要一个branch来记录latest stable version，这个version和production environment上deploy的内容完全一致
   • 解决方案：需要一个mark branch
4. 是否需要在发布新版本到生产环境前冻结代码进行控制
   • 解决方案：需要对应一个branch，此branch开发无权限merge，代码被merge到此branch之后开始做集成测试
5. 是否有CI/CD自动化工具
   • 解决方案：CI/CD自动化工具可以简化开发对git的操作

三、小型团队选型结论

1. 存在多个开发在一个Repository上开发不同feature然后合并到一起测试和同时deploy到production environment的场景
2. 不需要维护多个长期版本
3. 不需要一个单端的branch来记录production environment上deploy的内容
4. 不必要deploy前冻结代码
5. 无CI/CD自动化工具

结论：

用到的branch（尽量少）：

• develop branch
• release branch
• feature branch

四、branching model & workflow

• 使用long live的develop branch来记录最新的代码
• 使用short live的release branch来记录next version的代码，并且使用release branch部署test和production environment
• 使用Tag来记录latest的production environment内容
• 在最新的Tag上创建short live的bugfix branch用来修production environment的bug

具体的workflow如下：

4.1 working on a feature branch

1. Fetch develop branch so as to make it up to date

$ git fetch develop

2. Start a new feature branch

$ git checkout -b feature/${customized_feature_name} origin/develop

3. Implement feature and commit several times

$ git commit -a --amend

4. Merge with latest develop branch

$ git fetch develop
$ git rebase origin/develop

5. Self-testing
6. Push your branch. Make sure you have only one commit for your feature before push

$ git log
$ git rebase -i hash
$ git push origin feature/${customized_feature_name}

7. Open your browser and visit the "pull request url" printed on your console, then finish committing a PR on your browser with detailed test cases in your comment.

4.2 working on a release branch

You need a release branch when you decide to deploy a new release to production environment.

1. Fetch develop branch so as to make it up to date

$ git fetch develop

2. Start a release branch

$ git log origin/develop
$ git checkout -b release/x.y.z hash

3. Deploy to test environment based on release/x.y.z branch
4. Test thoroughly & Bug fixing(There should be only one commit for all bugs)
5. Deploy to production environment based on release/x.y.z branch's latest commit & Test
6. Squash commits & Tag the commit

$ git rebase -i hash
$ git tag x.y.z

7. Merge to develop branch and push

$ git checkout develop
$ git pull origin develop
$ git merge release/x.y.z
$ git push --tags origin develop
$ git branch -d release/x.y.z

4.3 working on a hotfix branch

1. Start a bugfix branch

$ git checkout -b hotfix/x.y.1 x.y.0

1. Code and fix bugs
2. Finish a bugfix branch

$ git checkout develop
$ git pull origin develop
$ git merge hotfix/x.y.1
$ git push --tags origin develop
$ git branch -d hotfix/x.y.1

rebase -i用法参考

Rewriting History Chapter from Pro Git SCM book