Git分岐モデル：いくつかの質問

Question

ブランチモデルは、生産コードを表すmasterブランチと、将来のリリースを表すrelease-x.xブランチがあるところでほぼ整っています。

しかし、我々は効果的に解決する方法がわからないいくつかのシナリオがあります：

ライブバグフィックスが新しいfeatureがrelease-2.0で分岐している現在のリリース

1. のためには関係ありませんモジュールAの完全な書き換えを行います。

2. release-2.0で新しいfeatureが完成し、マージされます。

3. 現在のライブモジュールAのバグが見つかりました。masterに修正されました。我々は（今は無関係であるバグ修正コードを破棄）競合をバグ修正を持参し、修正するためにmasterにrelease-2.0をリベース

   1. ：我々は考え出しこの時点で

   は、2つの可能なシナリオがあります。最終的には、リリースが準備完了したらrelease-2.0をmasterにマージします。

4. リリースに関連するバグフィックスのみをrelease-2.0に選択し、リリース準備が完了したら、release-2.0の履歴ですべてのmasterの履歴を上書きします。

ソリューション＃1軍たちは、私たちが必要とされていない知っているが、溶液＃2は、全体master枝を拭くと、すべてのリリースでrelease-2.0ブランチの歴史でそれを置き換えるために私たちを強制的にコミットとの競合をマージ解決します。これにより、チェリーピックを忘れてしまったバグ修正が失われる可能性があります（release-2.0）。また、リリース前にmasterに分岐していた進行中のバグ修正を破る可能性があります。

機能は、我々は新しいfeatureを作成やっぱ

1. リリースにそれをしない、release-2.0にリベースと--no-ffでrelease-2.0にそれをマージします。
2. いくつかのバグが見つかりましたので、featureに修正し、上記のマージプロセスをやり直してください。
3. クライアントは機能をもう一度見直して、多くのことを変更したいと決めます。機能には価値がありませんが、release-2.0の変更はできず、release-3.0まで待たなければなりません。

このシナリオを処理する適切な方法は何ですか？ release-2.0で行われた機能に関連するすべてのコミットを、「機能Xを元に戻して3.0に戻す」というメッセージを戻し、その後featureをrelease-3.0にマージする必要がありますか？

Answer 1

あなたは両方release-2.0とmasterブランチに、モジュールAを変更し、あなたのrelease-2.0支店にmasterに、モジュールAの変更を適用したい場合は、まず。

上記の解決策1と解決策2を除いて、モジュールAの変更をmasterからrelease-2.0にのみ適用できる別の方法があります。それはです。関連ファイルをmasterからrelease-2.0に直接チェックアウトし、変更をにコミットします。以下のように詳細手順：

git checkout release-2.0 
git checkout master /path/to/moduleA 
# Such as git checkout master moduleA/* 
# Now module A is what you changed in master 
git commit 

あなたはx.yとして（メジャー。マイナー）を、バージョンの形式を使用する場合には、第2は、ほとんどの場合のために、（主要な）xは、クライアントが必要と大幅に/主な変更を意味し、 y（マイナー）はバグを修正することを意味します。あるいは、お客様が行った作業をレビューする際に少し変更する必要はありません。

クライアントが2.0のバージョンを確認したときに大きな変更を要求した場合、そのプロジェクトをバージョン3.0として開発することができます。作業が終了したら、クライアントは3.0のバージョンを確認します。 3.0のバージョンでバグや小さな変更が報告された場合は、バージョンを3.1（変更した後にrelease-3.0ブランチの名前をrelease-3.1に変更するか、タグ3.1を追加する）に変更できます。ほかに

は、あなたが参照できるanother different branching moduleがあります： - >作業を終了するとき - >developreleaseにブランチをマージ - release分岐が承認された後> /レビュー - >masterブランチにreleaseをマージdevelopブランチ上で動作します - >リリースバージョンをタグに記録します。

Answer 2

ブランチの代わりにタグを使用して、プロダクションの内容を表すことをお勧めします。こうすることで、新しい修正プログラムのブランチをチェックアウトしてバグを修正し、このコミットを直接展開して現行の実動コードとしてタグ付けすることができます。次のリリースがすべて変更されることがわかっている場合は、

* 54c82e0 - (HEAD -> master) Commit6 
* bb6db8e - Commit5 
* 5156c9f - Commit4 
| * 630a150 - (tag: v1.1) Hotfix commit 
|/ 
* db5c984 - (tag: v1.0) Commit3 
* 00c6c5c - Commit2 
* 715412a - Commit1 

はあなたが計画されている分岐モデルを使用することになりますが、マスターではなく、すべての作業がにマージされて、あなたの「トランク」、となり、現在の生産コードは常にタグを持つことになりますが、あなたのことあなたは修正プログラムが必要かどうかチェックアウトすることができます。

GitFlowのような "実績のある"分岐モデルを盲目的に選ぶことには注意が必要です。あなたのニーズに合ったものを見つけるために、あなたは正しい道筋にいると思います。より多くの読み取りを参照してください：複数の質問がここにありますように

• Git Cooperation - From fancy to Functioning
• GitFlow considered harmful
• trunkbaseddevelopment.com