1

ソース管理として Mercurial/TortoiseHg を使用しています。

これまでのところ、私は単一のアプリを持っており、バージョン 1.0 を完成させようとしています。V 1.0 が公開されると、次のバージョンに向けてプログラムする準備が整った機能がすでに用意されています。

これは電話アプリであり、現在 V1.0 は無料ですが、V2.0 を有料にする可能性があり、後で無料バージョンにいくつかのマイナーなバグ/修正アップデートを行う可能性があります。

V2.0 が進行中の間、バグ修正がどのように機能するかはわかりません。

私の質問は:

V1.0 の時点からリポジトリをフォークまたはブランチする必要がありますか? それとも、単に現在のリポジトリに機能を追加し続けるだけですか? 何をする必要があるとしても、なぜそれをする必要があるのか​​知りたいです。

ありがとう。

4

4 に答える 4

2

一般的なワークフローは、 と の 2 つのブランチを持つことstableですdefault。新しいバージョンをリリースする準備ができたら、新しい機能を追加しdefaultてマージしstableます。ライブ バグはstableブランチで修正され、マージされて に戻されdefaultます。

このページはそれをとてもよく説明しています。

于 2012-06-12T07:25:14.013 に答える
1

私は 2.0 用のブランチを作成し、追加内容を追加し、それらが完了したら 1.0 にマージするか、1.0 のタグ付きバージョンを作成してアーカイブ用に保持します。

バグ修正が必要な場合や新しい展開が必要な場合に備えて、1.0 バージョンを回復できるようにするため、それらを別々に保持します。

于 2012-06-11T23:36:45.693 に答える
1

おめでとうございます。アプリが公開されたら、おそらくバグを修正し、いくつかのマイナー アップデートを行う必要がありますが、そのようなバグやマイナー アップデートを修正すると、2.0 での作業が妨げられる可能性があるため、単純に分岐して修正するのが賢明です。必要に応じてバグが発生し、2.0 に伝播します。

于 2012-06-11T23:37:52.513 に答える
1

私は次のことをします:

リリースするリビジョンに v1.0 のタグを付ける

hg update -r <revision that's 1.0>
hg tag v1.0
hg ci -m 'Created V1.0 Tag'

その上にあるバグ修正用のブランチを作成します。これは、V1.0 をリリースしたときか、最初のバグ修正があったときです。

hg update v1.0 (or ideally the revision that added the V1.0 tag if it's immediately after V1.0)
hg branch release_v1
<Possibly do bug fix>
hg ci

デフォルト ブランチに戻り、v2 の開発を続けます。

hg update default
<carry on working>

v1 のバグ修正がある場合

hg update release_v1
<do bug fix>

次に、v1.x から v2.x に前方バグ修正をマージします

hg update default
hg merge release_v1
hg ci -m 'Merged V1 bug fixes into V2'

新しいリリースと同じように、新しいタグを作成します。ブランチはそのまま進み、バグ修正を蓄積し、必要に応じて (開発ブランチ) にrelease_v1マージされます。defaultマージ変更セットが持つブランチ名を決定するため、マージするときにデフォルトのブランチにいることを確認してください。


これは他の誰かが言及したstable/ワークフローのバリエーションであることを追加するために編集されましたが、バグ修正を受け入れる複数のメジャー リリースを持つことができるので、メジャー リリースごとにブランチを作成するのが好きです。default

于 2012-06-13T08:48:05.670 に答える