1

セットアップ

ライブ環境には master ブランチを使用します。つまり、マスター上にあるものはすべて、ライブ環境にデプロイするのに適しています。

同様に、ステージング環境が実行されるステージング ブランチを使用します。

すべての変更は、トピック ブランチで開発されます。これらは QA のためにステージングにマージされ、展開のためにクリアされると、トピック ブランチはマスターにマージされて破棄されます。

マスター ブランチとトピック ブランチは Github に存在し、ステージングは​​ローカルに存在し、ステージング環境を構築するためのリポジトリにのみ存在します。

問題

トピック ブランチが立ち上がることがあります。それらはステージングにマージされましたが、何らかの理由 (顧客側での時間の制約、外部の依存関係など) により、ライブへの移行が許可されていません。通常、これは問題ではなく、しばらくの間ステージングのままになります。

しかし、現在、おそらく数か月間ライブにならないブランチがいくつかあり、新しいトピックブランチがステージングに到着すると、マージの競合が発生し始めています。

だから私がやりたいのは、スレートをきれいにすることです.基本的に、ステージングブランチをマスターの最新のコミットに戻し、近い将来に完了する可能性のあるすべてのトピックブランチを再適用します. その後、元に戻したステージング ブランチを、リポジトリで余分なクリーンアップを行うことなく、ステージング環境がデプロイに使用するリモート リポジトリにプッシュできるようにしたいと考えています。

どうすればいいですか？どうもありがとうございました。

4

1 に答える 1

2

手順に関するアドバイスを求めているのか、これを行うための git コマンドを求めているのかわかりません。私があなたを正しければ、これは役立つかもしれません：

ステージング ブランチをマスターの最新のコミットに戻します

$ git checkout staging
$ git reset --hard master

近い将来に完了する可能性のあるすべてのトピック ブランチを再適用する

$ git checkout topic1
$ git rebase -i staging
$ git checkout topic2
$ git rebase -i staging
...

注: リベースは「過去を変える」ため、よく議論される問題です。すべての開発者を同期させ (つまり、彼らのコミットが事後的に排除しようとしているものを参照していないことを確認してください)、リポジトリをバックアップすることをお勧めします。

rebase -i は対話モードを開始します。その後、トピック 1 の変更をステージング ヘッドに適用することができます。こことここに良いドキュメントがあります。

于 2013-11-12T10:43:13.580 に答える