3

git では、デプロイ ブランチの履歴を保持したい場合、ブランチに master から厳選されたコミットが既に含まれている場合、デプロイ ブランチを master で最新の状態にするための最良/最も簡単な方法は何ですか?

シナリオ:

  1. 過去のある時点で master から作成された展開ブランチ。
  2. 追加のコミットは、マスターからデプロイまでチェリーピックされ、他のいくつかのコミットは除外されます。
  3. デプロイ時のコードは本番環境にデプロイされます。
  4. ここで、次のデプロイのためにデプロイをマスターと完全に同期させる必要があります。

問題は、デプロイの履歴を変更せずにステップ 4 を簡単に実行する方法です (マージの競合を回避します。デプロイするためにコミットされたものは何もなく、厳選された変更のみです)。展開の履歴を削除したり、展開された正確なコードを元に戻したりするのをより困難にしますが、私はこれで間違っている可能性が非常に高いです)。

実行git merge masterすると多くの競合が発生しますが、これは避けた方がよいでしょう。なぜなら、必要なのは単に deploy の head が master の head に直接似ているためです (deploy には固有の変更は含まれていません)。

4

3 に答える 3

4

これまでにこれを行うために見つけた最良の方法で自分の質問に答えます。以下のコマンドは、マスターを優先してすべての競合を解決しながら、マスターをブランチにマージします (ブランチのチェックアウトから実行します)。

git merge -s recursive -X theirs origin/master
于 2013-03-12T20:11:03.840 に答える
2

私の経験では、マージするだけでうまくいくはずです。Gitは、チェリーピックされたコミットがすでに適用されていることを検出し、マージ中にそれらを「無視」します。マージしようとしましたか？失敗した場合でも、gitを使用して簡単に元に戻して、別の方法を試すことができます（別のマージ戦略かもしれませんが、まだ経験がありません）。

リベースしてもデプロイされたコードを残したい場合は、保持したいコードにタグを追加するだけです。リベースはコミットの履歴を書き換えますが、タグはリベース前のコード（コミット）を指します。

于 2013-02-14T18:34:17.313 に答える
1

これはあなたが期待している答えではないと思いますが、分岐戦略を少し洗練して、トピック分岐をより細かくする必要がある可能性があります。そうすれば、マスターからチェリーピッキングする代わりに、トピックブランチをマージできます。したがって、マスター ブランチはすべてのトピック ブランチをマージし、開発ブランチはいくつかのトピック ブランチをマージします。その後、最終的に master on development をマージして deploy ブランチを最新の状態にします。これは、競合を回避できるという保証ではありませんが、よりクリーンであり、標準的なケースでは、解決する競合が少なくなります。

チェリーピックすると、git は、チェリーピックされたコミットとチェリーピックされた元のコミットが同一であることを認識する能力を失います。ここから対立が生まれます。

于 2013-02-14T19:26:28.350 に答える