2

gitlabを使用しています。マスターブランチは保護されており、プロジェクトの所有者のみがマスターへのマージリクエストをコミット/受け入れることができます。他の開発者は、コードをマスターにするためにマージリクエストを送信します。

マージリクエスト（機能ブランチからマスターへ）を送信するとき、開発者の1人がコードを確認します。提案/コメントがある場合、開発者はコードを更新し、マージ要求は新しいコミットも表示します。

次に、QAがブランチでテストを開始し、開発者が同じブランチのバグを修正します。すべてが完了し、準備が整うと、QAはマージリクエストにテスト済みであることを示すコメントを追加します。

コミットはたくさんありますが、機能は1つなので、管理しやすくするために、1つのコミットとしてプッシュするだけです。

ここがプロジェクトのオーナーと私が矛盾するところです。私はプロジェクトの所有者にそうするgit merge --squashように頼みますが、彼は最後のコミットにすべてを押しつぶして強制的にプッシュすることによって私のブランチをリベースするように私に頼みます。この後、枝は死んでしまうので、彼の主張は、問題を起こさないだろうということです。

それで、ここに従うための最良の方法はどれですか？

PS gitlabでスカッシュマージを実行するためのGUIオプションはありません。使用可能なオプションは、すべてのコミットをそのままマージすることだけです。

4

1 に答える 1

4

両方の操作の結果は非常に似ており、master 上でのコミットと、最終的に終了する機能ブランチです。

マージ --squash により、プロジェクト所有者は発生する可能性のある競合に対処する必要があります。この問題を回避するには、マージの直前に機能ブランチで origin/master をマージする必要があります。

その後、最終結果の唯一の違いは、機能ブランチが操作の後にポイントする場所です。

  1. : フィーチャー ブランチの後に、merge origin/master, merge --squash最終的に消滅する瀕死のブランチを指しますが、多少混乱するでしょう:既にマージされていますか?
  2. 機能ブランチの後、rebase, force push, merge --ff押しつぶされたコミットがポイントされます。

次のことを決定する必要があります。

  • 機能ブランチを強制的に「削除」し、機能ブランチの履歴を保持することを明示的に選択するプロセス (リベースの前に新しい参照を作成してプッシュすることにより、更新された名前: featureA_merged である可能性があります)
  • すべての機能ブランチを保持するプロセスですが、マージされたブランチを記憶/管理する必要があります。

IMHO rebase と force push は、結局のところ、よりクリーンなソリューションです。潜在的な競合に対処し、参照を瀕死のブランチから移動すると、将来トラブルや混乱を引き起こす可能性があります。今では間違っているように見えることをしても、強制的にプッシュします。

于 2012-10-17T21:37:48.877 に答える