2009-09-10 9 views
46

最近、私はSVNからMercurialに切り替えました。他の開発者がリポジトリで何が起こっているのかを理解するために、Mercurialで意図した分岐作業フローを実現する方法を知りました。Mercurialのリリースブランチの管理

これは、作業の流れです:

  1. 通常、私は現在のリリースシリーズの作業が発生したトランク/デフォルトの枝を持っています。それが1.xだとしましょう。同時に私は次のメジャーリリースに取り組むためにブランチ2.xを使用します。このブランチの変更は根本的なので、trunk/default/1.xブランチとのマージはここでは意味がありません。
    • しばらくして2.xでの作業が終了し、バージョン2.0がリリースされることがあります。今私は2.xブランチを新しいデフォルト/トランクブランチにし、現在のデフォルト/トランクを1.xブランチにします。
    • このプロセスを繰り返すと、新しい3.xブランチが作成されることがあります。以前のように、3.0がリリースされた場合、3.xは新しいデフォルトブランチになるはずですが、現在のデフォルトは2.xブランチ(再び)になります。

私の質問は、この作業の流れが良いもの(私はそれが根本的に間違っていないだと思う)であるかどうかないです。私の疑問は、Mercurialでこれを実現する方法が良い習慣と見なされるか、より良い機会があるかどうかということです。だからここ

は、私はMercurialの中に支店を管理する計画方法です...

現在のリリースシリーズ1.1のコードを保持している単一の分岐でリポジトリ最低料金:

$ 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.1)にいくつかの作業を行います。

$ hg up default 
$ echo "Minor adjustments specific for 1.x" > file3.txt 
$ hg ci -A -m "Minor adjustments" 

いくつかの時間リリース2.0の準備が整い、yippee!

$ 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のと仕事を作成1.12.xのにデフォルトからデフォルト分岐が作ります。ここでも、いくつかの時間3.0の後に準備ができて、それはブランチ名を管理するために再び時間です:

$ 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」のヘッドで)次のようになります。

o Branch default (3.x) 
| 
| o Branch 2.x 
\| 
    | o Branch 1.x 
    \| 
    | 
    . 

主なポイント私はブランチ名とジャグリングブランチ名デフォルトを再利用する場合は、が良い練習であるかどうかは分かりません。

その質問のテキストがたくさんあります - 申し訳ありませんが、私は自分のしていることを明確にしたいと思っていました。

+0

[Mercurial wiki](http://www.mercurial-scm.org/wiki/StandardBranching)はこのトピックについての良い紹介です。 – xyres

答えて

47

は、ここで私がしたいものです。

defaultあなたの「メインライン」ブランチを作成します。このブランチの先端は、現在公開されているコードのバージョンです。重大なバグ修正は、このブランチに直接コミットして開発ブランチにマージすることができます。

バージョン2.0の作業を開始するには、2.0-devブランチを作成します。 2.0の変更をそのブランチにコミットし、幹線(default)からの重要なバグ修正をそのブランチにマージします。 2.0で終わったら2.0-devdefaultにマージし、結果を2.0とタグ付けします。

このようにすると、分岐名のジャグリングを心配する必要がなくなり、重要なバグ修正をメインラインにマージして開発ブランチに簡単にマージすることができます。

これは、複数の将来のバージョン(たとえば2.1と3.0)で作業しているときにもうまくスケーリングされます。 2.1の変更を3.0にマージして3.0を最新の状態に保つことができます。

次のようなグラフになってしまいます:a successfull git branching model:私はあなたがこれを検討すべきだと思う

$ 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. 
+2

私はこのワークフローを推奨していると聞いたことがありますが、develブランチには意味を持たないメインラインにいくつかの変更があった場合、それがどの程度うまく適用されるかわかりませんでした。私はそれが最新のメインラインの変更をdevelブランチにどのようにマージするかということになると思います。メインラインから不要な変更をどうやって処理するのですか? 「メインセットからチェンジセット23と27をマージしますが、他のすべてのチェンジセットを無視します(またはマージ後に元に戻す)」などの表現が可能ですか? –

+4

23と27をマージして他のものを無視する場合は、Transplant拡張機能が必要です。http://mercurial.selenic.com/wiki/TransplantExtensionすべてをマージして23と27を元に戻したい場合は、通常とマージしてから'hg backout 23 --merge; hg backout 27 --merge'をdevブランチに置きます。 –

+2

私は 'backout'コマンドが自分の目的に最も適していると思います。私はそれをテストし、私がしたいことをします。バックアウトの変更が数回しかない場合は、うまく機能しているようです。さもなければ、不必要な変更がたくさんあると、履歴グラフが膨らみ、多くの手動作業が必要になります。しかし、これが当てはまらない限り、私はあなたの提案に完全に満足しています:)ありがとう! –

2

私はgitの大ファンではありませんが、このモデルは水銀のためにも非常に便利です。

関連する問題