Git 分支管理策略汇总 _生活百科

原文链接： Git 分支管理策略
最近，团队新入职了一些小伙伴，在开发过程中，他们问我 Git 分支是如何管理的，以及应该怎么提交代码？
我大概说了一些规则，但仔细想来，好像也并没有形成一个清晰规范的流程。所以查了一些资料，总结出下面这篇文章，一共包含四种常见的分支管理策略，分享给大家。
Git flow

文章插图
在这种模式下，主要维护了两类分支：

主要分支 (The main branch)

master
develop

辅助分支 (Supporting branch)

feature branch (功能分支)
release branch (预发布分支)
hotfix branch (热修复分支)

master首先，代码库应该有一个、且仅有一个主分支。master 分支的代码永远是稳定的，可以随时发布到生产环境。
developdevelop 分支用于日常开发，保存了开发过程中最新的代码。
当 develop 分支上的代码达到稳定，并且具备发版状态时，需要将 develop 的代码合并到 master，并且打一个带有发布版本号的 tag 。
创建 develop 分支：
git checkout -b develop master将 develop 合并到 master：
# 切换到 master 分支git checkout master# 对 develop 分支进行合并git merge --no-ff develop--no-ff 参数的作用是使当前的合并操作总是创建一个新的 commit 对象，即使该合并被执行为快进式（fast-forward）合并。
这样可以避免丢失掉该功能分支的历史信息，并且将针对该功能的所有提交都集中到一起。这样解释也并不是很易懂，通过下图来对比一下就比较明显了：
feature

分支来源：develop
合并到分支：develop
分支命名约定：feature-*

功能分支，在开发某一个新功能时，从 develop 分支分出来，开发完之后，再合并回 develop 分支。
功能分支通常只存在于开发者的本地仓库中，并不包含在远程库中。
创建一个功能分支：
git checkout -b feature-x develop开发完成后，将功能分支合并到 develop 分支：
git checkout developgit merge --no-ff feature-x删除 feature 分支：
git branch -d feature-xrelease

分支来源：develop
合并到分支：develop，master
分支命名约定：release-*

预发布分支，它是指发布正式版本之前，我们可能需要有一个预发布的版本测试，并且可以在上面做一些较小 bug 的修复。
预发布分支是从 develop 分支上分出来的，预发布结束以后，必须合并进 develop 和 master 分支。
创建一个预发布分支：
git checkout -b release-1.2 develop确认没有问题后，合并到 master 分支：
git checkout mastergit merge --no-ff release-1.2# 对合并生成的新节点，做一个标签git tag -a 1.2再合并到 develop 分支：
git checkout developgit merge --no-ff release-1.2最后，删除预发布分支：
git branch -d release-1.2hotfix

分支来源：master
合并到分支：develop，master
分支命名约定：hotfix-*

最后一种是修复 bug 分支。软件正式发布以后，难免会出现 bug 。这时就需要创建一个分支，进行 bug 修复。
修复 bug 分支是从 master 分支上分出来的。修复结束以后，再合并进 master 和 develop 分支。
创建一个修复 bug 分支：
git checkout -b hotfix-0.1 master修复结束后，合并到 master 分支：
git checkout mastergit merge --no-ff hotfix-0.1git tag -a 0.1.1再合并到 develop 分支：
git checkout developgit merge --no-ff hotfix-0.1最后，删除修复 bug 分支：
git branch -d hotfix-0.1小结优点：