git - Gitの分岐とマージのワークフローの問題。どうしますか？

Question

これが私たちの開発ワークフローです：

私の問題はステップ3と4にあります。クライアントはステージングサーバーにのみアクセスできるため、クライアントが変更を確認するには、トピックブランチを開発ブランチにマージしてステージングサーバーにプッシュする必要があります。 1つのブランチだけをマージするのではなく、平均して3〜4をマージします。

クライアントが変更を拒否し、さらに変更が必要な場合、開発者は同じトピックブランチの問題を修正し、私は開発に再び取り組む必要があります。

トピックブランチを複数回再マージして開発することにより、私は歴史の中でその問題を見失います。（時には競合も発生します）

これは「健全な」開発ワークフローですか？あなたの提案、改善は何ですか？

score 2 · Accepted Answer

クライアントが変更を拒否し、さらに変更が必要な場合、開発者は同じトピックブランチの問題を修正し、私は開発に再び取り組む必要があります。

開発ブランチで拒否された変更を（のように）元に戻しgit revert、開発者の修正を待ちます。
git revertを使用することで、履歴を変更するのではなく、新しいコミットのみを追加します（rebaseまたはgit reset）

そうすれば、（同じ機能の）次のコミットを開発ブランチで簡単に再度マージする必要があります。

score 1 · Accepted Answer

ステージングブランチを導入するだけです。これはダーティであり、誰もブランチすることはできません。

ステージングデプロイメントプロセスが履歴の書き換えを処理することを確認してください。ステージングサーバーが中央リポジトリからプルする場合は、プルをとに置き換えますfetch。reset --hard origin/branch
クライアントに変更を確認してもらいたい場合は、以前のプロセスを使用するだけです。プロセスをマージし、変更が必要な場合は再マージします。
たまにマージしdevelopて、すべての変更があることを確認します。現在レビューがない場合（=stagingはと同期している必要があります）、代わりdevelopにリセットstagingしてください（ ; ）developgit checkout staginggit reset --hard develop
git reset --hard HEAD~4ステージングはダーティであると想定されているため、変更によって何かが壊れた場合などに影響を与えることなく、数ステップ（）に戻るなど、いつでもクレイジーな書き換えを行うことができます。
クライアントが変更を承認した後でのみ、変更を開発にマージします。

このように、履歴をあまり気にせず（クライアントにコンテンツを表示する）、developブランチが非常にクリーンな履歴を取得するプロセスで、優れた履歴を生成することを心配する必要はありません。

マージの競合を複数回解決する必要があることを心配している場合は、gitのrerere機能をご覧ください

2 に答える 2