2016-04-06 2 views
2

最近svnからgitに移行しました。現在、リリースブランチとマスターブランチがあります。リリースの日にリリースをマージしてタグ付けします。パッチリリース後のマスターへのリリースの統合git

ここで、パッチリリースを行う予定だった場合。どのブランチを修正プログラムのブランチとして作成し、それをマスターにマージして、そこから新しいタグを作成してリリースします。次に、その修正プログラムをリリースにマージして、QAがテスト中にリリースですべての変更をプロダクションに反映させるようにします。

次に、リリースブランチをマージしてmasterに戻す必要があるときに問題が発生します。私たちは、マスターが

2を発散しているように早送り(これもコミットマージを追加します)私たちは、通常のマージを行う場合でも、それが安全になります)リリースを行うことはできません

1)は、そのコードは次のようになります私たちはマスターからリリースをリベースすることができますが、これは一般的な公開ブランチです(開発者のローカルブランチを台無しにするでしょうか?)、リベースリリースも危険ですか? 我々は理想的なリベースしていない場合、我々はあなたがリリースを行うにはどうすればよいのクリーンすべてのリリースでは、タグ・ポイントとマスターブランチの履歴のいずれか

を有し、通常この

+0

"リリース日にリリースをマスターにマージします。"あなたが 'git checkout master; git merge release'と呼ばれています。 – Schwern

+0

'release'を' master'にマージします。 'master 'は' diverged 'を持っていますが、' release'と同じコミットなので、矛盾はありません。あなたが説明するものは、[git flow](http://nvie.com/posts/a-successful-git-branching-model/)戦略とよく似ています。 gitフローを使うときは 'development'ブランチがあります(あなたの' release'ブランチに似ています)。 'master'から分岐したホットフィックスは' master'と 'development'の両方にマージされます。 '開発 'は後で再び'マスター'にマージされます(gitフローの場合は 'release'ブランチを介して)。 – Peter

答えて

1

Then we also merge that hotfix back into release

We can't do a fast forward release as the master has diverged

一つの方法を処理しません。そのワークフローを改善し、発散の状況はちょうどhotfixマージした後、もう一つのマージを追加することです避ける:

git checkout relase 
git merge -s ours master 

そのように、あなたはreleasemasterは「マージ」されていることを記録。

これにより、後で早送りマージをreleaseからmasterにすることができます。

+0

コメントを追加する前に、 "--ours"のビットを詳しく説明できますか?私もマージのためにgitドキュメントをチェックし、2つの "私たち"がリストされているようです。 – MilindaD

+0

@MilindaD oursは、宛先ブランチの* anything *を変更せずにマージを記録できるマージ戦略です。これにより、将来の早送りマージを可能にする共通の祖先を作成することができます。 – VonC

+0

私たちはmasterとreleaseの両方に修正プログラムをマージします。その後、 "ours"をマージしてマージします。正しい?また、私たちは修正版をリリースするようにマージしているので、後で "私たち"のマージを行うときに衝突があっても、早送りマージを行うことができます。正しい?また、あなたの職場(そして他の組織)で何をしているのかを明確にするだけですか? – MilindaD

関連する問題