私たちのチームは純粋にマージベースの git ワークフローを使用しており、すべてのチーム メンバーに、ある日の午後にすべての作業をサーバーにプッシュし、夜にサーバー リポジトリのリベースを行うように依頼する可能性について話し合っています。
私が自動的にやりたいことは、すべてのコミットが同じブランチのセットにのみあり、並列コミットの数が特定のしきい値を下回っている限り、シリーズをリベースしてマージコミットを削除したいということです（秒）。しかし、私は提案を受け入れていますか？
誰でもこれを行う方法を知っていますか?
私の意見では、「見栄えを良くする」ためだけに履歴を書き直したいという誘惑を避ける必要があります。本当に意味がありません。履歴は、それ自体、現実をより正確に表したものであり、gitのレポートツールはすべて、小さなマージがたくさんある場合でも役立つように設計されています。
多くのマージを表示することに興味がない場合は、多くのレポートタスクからそれらを抑制することができます。
git log --no-merges
あなたが提案していること（リベースの夜、おそらくすべての開発者がしなければならないことreset）は、仕事のために作品を作成しているように見えます。
これがどれほど簡単かはわかりません。を実行するrebase -iと、すべてのマージを無視しようとします。競合のないマージは成功しますが、競合があった場合は停止して待機します。
一方、として呼び出すとrebase -i -p、ユーザーが実際のマージを行ったときに必要なマージが保持されますが、それ以外の場合はポイントが完全に失われます。
おそらく、必要な場合にのみマージを保持する 2 つのコマンドのいくつかのシーケンスが、この場合の仕事を成し遂げる可能性があります。
しかし、歴史を現実に反映させることは、それを「きれいに見せる」ことよりもはるかに価値があるというチャールズに同意しなければなりません. 実際、一方のコミットは他方のコミットを知らずに行われました。ソース コードの場合、これにより、何か問題が発生した理由がわかります。
私たちのチームは、純粋にマージベースの git ワークフローを使用しています
--rebase常に(eg )でプルすることの何が問題になっていgit pull -rますか? フラットなトポロジが必要な場合、最も簡単な方法は、リベースできるときにマージしないことです。
また、「マージがクリーン」な場合にのみフラット化したいと言います。私はここで推測しているだけですが、デフォルトのコミットメッセージのメモ以外に、事実の後に git が競合を記録するとは思いません。