Git 分支策略

他们必须等到 release 分支派发出去之后再做合并。在一个 release 分支的开始，我们就赋予其一个明确的版本号。直到该分支创建之前，develop 分支上的描述都是“下一次”release 的改动，但这个“下一次”release 其实也没说清楚是 0.3 release 还是 1.0 release。而在一个 release 分支的开始时这一点就会确定。这将成为有关项目版本号晋升的一个守则。创建一个 release 分支Release 分支派发自 develop 分支。比如，我们当前的生产环境发布的版本是 1.1.5，马上有一个 release 要发布了。develop 分支已经为“下一次”release 做好了准备，并且我们已经决定把新的版本号定为 1.2 (而不是 1.1.6 或 2.0)。所以我们派发一个 release 分支并以新的版本号为其命名：$ git checkout -b release-1.2 developSwitched to a new branch "release-1.2"$ ./bump-version.sh 1.2Files 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.21 files changed, 1 insertions(+), 1 deletions(-)创建好并切换到新的分支之后，我们完成对版本号的晋升。这里的 bump-version.sh是一个虚构的用来改变代码库中某些文件以反映新版本的 shell 脚本。(当然你也可以手动完成这些改变——重点是有些文件发生了改变)然后，晋升了的版本号会被提交。这个新的分支会存在一段时间，直到它确实发布出去了为止。期间可能会有 bug 修复(这比在 develop 做更合理)。但我们严格禁止在此开发庞大的新特性，它们应该合并到 develop 分支，并放入下次发布。完成一个 release 分支当 release 分支真正发布成功之后，还有些事情需要收尾。首先，release 分支会被合并到 master (别忘了，master 上的每一次提交都代表一个真正的新的发布)；然后，为master 上的这次提交打一个 tag，以便作为版本历史的重要参考；最后，还要把 release 分支产生的改动合并回 develop，以便后续的发布同样包含对这些 bug 的修复。前两部在 git 下是这样操作的：$ git checkout masterSwitched to branch 'master'$ git merge --no-ff release-1.2Merge made by recursive(Summary of changes)$ git tag -a 1.2现在发布工作已经完成了，同时 tag 也打好了，用在未来做参考。补充：你也可以通过 -s 或 -u <key> 标记打 tag。为了保留 release 分支里的改动记录，我们需要把这些改动合并回 develop。git 操作如下：$ git checkout developSwitched to branch 'develop'$ git merge --no-ff release-1.2Merge made by recursive.(Summary of changes)这一步有可能导致冲突的发生(只是有理论上的可能性，因为我们已经改变了版本号)，一旦发现，解决冲突然后提交就好了。现在我们真正完成了一个 release 分支，该把它删掉了，因为它的使命已经完成了：$ git branch -d release-1.2Deleted branch release-1.2 (was ff452fe).hotfix 分支可能派发自：master必须合并回：develop 和 master分支命名规范：hotfix-*Hotfix 分支和 release 分支非常类似，因为他们都意味着会产生一个新的生产环境的发布，尽管 hotfix 分支不是先前就计划好的。他们在实时的生产环境版本出现意外需要快速响应时，从 master 分支相应的 tag 被派发。我们这样做的根本原因，是为了让团队其中一个人来快速修复生产环境的问题，其他成员可以按工作计划继续工作下去而不受太大影响。创建一个 hotfix 分支Hotfix 分支创建自 master 分支。例如，假设 1.2 版本是目前的生产环境且出现了一个严重的 bug，但是目前的 develop 并不足够稳定。那么我们可以派发出一个 hotfix 分支来开始我们的修复工作：$ git checkout -b hotfix-1.2.1 masterSwitched to a new branch "hotfix-1.2.1"$ ./bump-version.sh 1.2.1Files 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.11 files changed, 1 insertions(+), 1 deletions(-)别忘了在派发出分支之后晋升版本号！然后，修复 bug，提交改动。通过一个或多个提交都可以。$ git commit -m "Fixed severe production problem"[hotfix-1.2.1 abbe5d6] Fixed severe production problem5 files changed, 32 insertions(+), 17 deletions(-)完成一个 hotfix 分支当我们完成之后，对 bug 的修复需要合并回 master，同时也需要合并回 develop，以保证接下来的发布也都已经解决了这个 bug。这和 release 分支的完成方式是完全一样的。首先，更新 master 并为本次发布打一个 tag：$ git checkout masterSwitched to branch 'master'$ git merge --no-ff hotfix-1.2.1Merge made by recursive(Summary of changes)$ git tag -a 1.2.1补充：你也可以通过 -s 或 -u <key> 标记打 tag。然后，把已修复的 bug 合并到 develop：$ git checkout developSwitched to branch 'develop'$ git merge --no-ff hotfix-1.2.1Merge made by recursive(Summary of changes)这个规矩的一个额外之处是：如果此时已经存在了一个 release 分支，那么 hotfix 的改变需要合并到这个 release 分支，而不是 develop 分支。因为把对 bug 的修复合并回 release 分支之后，release 分支最终还是会合并回 develop 分支的。(如果在 develop 分支中立刻需要对这个 bug 的修复，且等不及 release 分支合并回来，则你还是可以直接合并回 develop 分支的，这是绝对没问题的)最后，删掉这个临时的分支：$ git branch -d hotfix-1.2.1Deleted branch hotfix-1.2.1 (was abbe5d6).摘要其实这个分支模型里没有什么新奇的东西。文章开头的那张大图对我们的项目来说非常有用。它非常易于团队成员理解这个优雅有效的模型，并在团队内部达成共识。这里还有一份那张大图的 高清PDF版本，你可以把它当做手册放在手边快速浏览。补充：还有，如果你们需要的话，这里还有一份 Keynote 版本本文译自：A successful Git branching model ? nvie.com