管理Mercurial中的发行分支 [英] Managing release branches in Mercurial
问题描述
最近，我从SVN切换到了Mercurial.现在，我想知道如何根据良好实践在Mercurial中实现预期的分支工作流程，希望其他开发人员了解存储库中发生的情况.
Recently I switched from SVN to Mercurial. Now I wonder how to realize my intended branching work flow in Mercurial according to good practice, hoping other developers understand what happens in the repository.
这是工作流程:
- 通常，我有一个主干/默认分支，在该分支上进行当前发行版的工作.假设是1.x.同时，我使用分支2.x来处理下一个主要版本.该分支中的更改可能是巨大的，因此与trunk/default/1.x分支合并在这里毫无意义.
- 过一会儿，在2.x上的工作可能会完成，并且会发布2.0版.现在，我希望2.x分支成为新的default/trunk分支，而当前的默认/trunk成为1.x分支.
- 重复此过程，可能会出现一个新的3.x分支.与以前一样，如果发布3.0，则3.x应该成为新的默认分支，而当前的默认应该再次成为2.x分支.
- Usually I have a trunk/default branch where work on the current release series happens. Let's say that is 1.x. At the same time I use a branch 2.x to work on the next major release. Changes in this branch may be radical, so merging with the trunk/default/1.x branch makes no sense here.
- After a while work on 2.x may be finished and version 2.0 gets released. Now I want the 2.x branch to be the new default/trunk branch and the current default/trunk to be the 1.x branch.
- Repeating this process, there may come a new 3.x branch. As before, if 3.0 gets released, 3.x should become the new default branch while the then current default should become the 2.x branch (again).
我的问题不是不是，这个工作流程是否很好(我想这根本不是错误的).我的问题是，在Mercurial中实现这一目标的方式是否可以看作是一种好的做法，还是有更好的机会.
My question is not whether this work flow is a good one (I guess it's not fundamentally wrong). My questions is whether the way I realize this in Mercurial can be seen as good practice or if there are better opportunities.
这就是我计划在Mercurial中管理分支机构的方式...
So here is how I plan to manage branches in Mercurial ...
从具有单个分支的存储库开始，该分支包含当前发行版本1.x的代码:
Starting from a repository with a single branch which holds the code of the current release series 1.x:
$ hg init
$ echo "hello world" > file1.txt
$ hg ci -A -m "Initial commit of 1.x code"
开始处理版本2.x:
$ hg branch 2.x
$ hg ci -m "Create new branch for 2.x development"
$ echo "Big new feature for 2.x" > file2.txt
$ hg ci -A -m "Add big new feature"
同时，在当前版本的系列(1.x)中做一些工作:
Meanwhile, do some work in current release series (1.x):
$ hg up default
$ echo "Minor adjustments specific for 1.x" > file3.txt
$ hg ci -A -m "Minor adjustments"
一段时间后，2.0版就准备好了，yippee！将 default 分支到 1.x ，将 2.x 分支到 default :
After some time release 2.0 is ready, yippee! Make default branch to 1.x and 2.x to default:
$ hg up default
$ hg branch 1.x
$ hg ci -m "Make default branch to 1.x branch"
$ hg up 2.x
$ hg ci --close-branch -m "Close branch 2.x"
$ hg branch --force default
$ hg ci -m "Make former 2.x branch to new default"
现在创建一个新分支 3.x 并在其中工作，也可以在 default 上工作.同样，在3.0就绪之后，该再次管理分支名称了:
Now create a new branch 3.x and work in it, also work on default. Again, after some time 3.0 is ready and it's time again to manage branch names:
$ hg up default
$ hg branch --force 2.x # (reuse previously closed 2.x branch name)
$ hg ci -m "Make default branch to 2.x branch"
$ hg up 3.x
$ hg ci --close-branch -m "Close branch 3.x"
$ hg branch --force default
$ hg ci -m "Make former 3.x branch to new default"
现在回购可能看起来像这样('o'是头):
The repo now may look like this ('o' are the heads):
o Branch default (3.x)
|
| o Branch 2.x
\|
| o Branch 1.x
\|
|
.
我不确定主要要点是重用分支名称并使用分支名称 default 玩弄是一种好习惯.
The main point I'm not sure about is if reusing branch names and juggling with the branch name default is good practice.
关于该问题的很多文字-抱歉-但我想清楚自己在做什么.
A lot of text for that question - sorry - but I wanted to be clear about what I'm doing.
推荐答案
这就是我要做的:
将default设置为您的主线"分支.该分支的技巧是代码的当前发布给公众"版本.关键的错误修正可以直接提交到此分支，然后合并到开发分支中.
Make default your "mainline" branch. The tip of this branch is the "currently released to the public" version of your code. Critical bugfixes can be committed directly to this branch and merged into development branches.
要开始使用2.0版，请创建一个2.0-dev分支.将对2.0的更改提交到该分支，然后将来自主线(default)的重要错误修正合并到该分支中.完成2.0后，将2.0-dev合并到default并将结果标记为2.0.
To start working on version 2.0, make a 2.0-dev branch. Commit changes for 2.0 to that branch, and merge critical bugfixes from the mainline (default) into it. Once you're done with 2.0, merge 2.0-dev into default and tag the result as 2.0.
以这种方式做事意味着您不必担心弄乱分支名称，并且可以很容易地将关键错误修正到主线合并到开发分支中.
Doing things this way means you don't have to worry about juggling branch names, and you can merge critical bugfixes to the mainline into development branches quite easily.
当您同时处理多个将来的版本(例如2.1和3.0)时，它也可以很好地扩展.您可以定期将2.1的更改合并到3.0，以保持3.0的最新状态.
It also scales well when you're working on multiple future versions at once (say 2.1 and 3.0). You can periodically merge the 2.1 changes into 3.0 to keep 3.0 current.
您最终将得到一个这样的图形:
You'll end up with a graph like this:
$ hg glog -l 1000
@ changeset: 25:efc0096f47c0 tip
| summary: Added tag 3.0 for changeset d1a7fc3d7d77
|
o changeset: 24:d1a7fc3d7d77 3.0
|\ summary: Merge in the redesign changes.
| |
| o changeset: 23:b5b69d24c8f7 3.0-dev
| | summary: Finish 3.0 redesign.
| |
| o changeset: 22:4c2f98fac54b 3.0-dev
|/| summary: Merge in the latest changes to 2.1/mainline.
| |
o | changeset: 21:37df04521032
| | summary: Added tag 2.1 for changeset 39ecc520fc0a
| |
o | changeset: 20:39ecc520fc0a 2.1
|\ \ summary: 2.1 development is done.
| | |
| o | changeset: 19:208f3f9236af 2.1-dev
| | | summary: Finish the 2.1 work.
| | |
| | o changeset: 18:4a024009a9d6 3.0-dev
| | | summary: More redesign work.
| | |
| | o changeset: 17:00c416888c25 3.0-dev
| |/| summary: Merge in changes from the 2.1 branch to keep the redesign current.
| | |
| o | changeset: 16:a57e781a0db1 2.1-dev
| | | summary: More 2.1 work.
| | |
| | o changeset: 15:ddeb65402a61 3.0-dev
| | | summary: More redesign work.
| | |
+---o changeset: 14:90f5d7a8af9a 3.0-dev
| | | summary: Merge in the fire fixes.
| | |
| o | changeset: 13:78a949b67bb9 2.1-dev
|/| | summary: Merge in the fire fixes.
| | |
o | | changeset: 12:6dfe9d856202
| | | summary: Oh no everything is on fire, fix it in the mainline.
| | |
| o | changeset: 11:86767671dcdb 2.1-dev
| | | summary: Smaller changes for 2.1.
| | |
| | o changeset: 10:25dec81d2546 3.0-dev
| | | summary: Work more on the redesign.
| | |
+---o changeset: 9:42c7d689fb24 3.0-dev
| | summary: Start working on a complete redesign.
| |
| o changeset: 8:3da99186ca7d 2.1-dev
|/ summary: Start working on 2.1.
|
o changeset: 7:9ba79361827d
| summary: Added tag 2.0 for changeset 755ed5c5e291
|
o changeset: 6:755ed5c5e291 2.0
|\ summary: Merge in the dev branch for 2.0.
| |
| o changeset: 5:44a833fcc838 2.0-dev
| | summary: Finish work on 2.0.
| |
| o changeset: 4:d7ba6aae1651 2.0-dev
|/| summary: Merge in the critical fix.
| |
o | changeset: 3:968049f1b33a
| | summary: Fix a critical bug on the main branch.
| |
| o changeset: 2:917869609b25 2.0-dev
| | summary: More work on the new version.
| |
| o changeset: 1:f95798b9cb2e 2.0-dev
|/ summary: Start working on version 2.0.
|
o changeset: 0:8a3fb044d3f4
summary: Initial commit.
这篇关于管理Mercurial中的发行分支的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
