Git ワークフロー: 公開/共有ブランチのリベース 質問する

私たちの職場のチームはリベース ワークフローを熱心に採用しましたが、少しやりすぎてしまったかもしれません。それがこの質問のポイントです。判断はあなたにお任せします。

pull --rebase を使うのは、今では私にとっては簡単なことです。しかし、複数の人が作業する大きな機能ブランチもあります。定期的に、マスターで起こっている変更を取り入れたいと考えています。共有ブランチなので、常識的にはマージするでしょう。しかし、リベースにこだわる私たちは、これらのブランチをリベースすることにしました。もちろん、全員の協力が必要です。ワークフローは次のようになります。

1) リベース担当者は全員と調整して、全員がチェックインされ、機能ブランチにプッシュされていることを確認し、問題がないと確認されるまでそのブランチでこれ以上作業を行わないように依頼します。

2) リベース機能は、機能ブランチをマスターにリベースし、リモート機能ブランチを削除し (git push origin :feature)、新しいリベースされた機能ブランチをプッシュします (git push origin feature)

3) リベース機能は全員にフェッチをさせ、各自の機能ブランチを更新し、ローカルの機能ブランチを削除し (git branch -D feature)、リモートの機能ブランチを追跡する新しいローカルの機能ブランチを作成します。これで全員の作業完了です。

このワークフローは、私たちのグループが小規模で、作業の中断が少ないこともあり、うまく機能しています。ただし、私たちが Git の悪い習慣 (共有ブランチのリベース) を身につけてしまったり、ワークフローがうまく拡張できないのではないかと心配しています。

良い点は、リポジトリの履歴が素晴らしいことです。

Git の達人の方々、どう思われますか? 私たちは火遊びをしているのでしょうか、それとも合理的なワークフローを実践しているのでしょうか?

アップデート:

私が最初にこの質問をしてから 2 年が経ちましたが、それ以来、私たちのワークフローは変わりましたか。私たちは今でも定期的に を行っているgit pull --rebaseため、それは変わっていません。これは常識であり、見苦しく混乱を招くミニマージをすべて防ぎます。(私たちはほぼ同期を保っているため、 にかかるコストはほとんどありませんgit pull --rebase)。

しかし、それ以外、そして間違いを訂正するための時折の英雄的な行動を除けば、私たちはリベースの狂気から抜け出しました。マージはほとんどの場合に意味があります。しかし、無謀なマージは問題があり、2年前に私が懸念していた混乱した混沌とした歴史の一因となっています。

当社のソリューションにはいくつかのコンポーネントがあります。

• マスターブランチは「原始的」です。トピックブランチはマージされ、そうなるとトピックブランチは廃止される言い換えると、トピック ブランチを にマージするということは、その作業が本番環境の準備ができており、マスター ブランチの一部になっていることを意味します。バージョン履歴を見ると、何が起こっているかが非常に明確です。トピック ブランチがマスターにマージされ、それで終わりです。

• 必要に応じて、使い捨ての統合ブランチを使用します。たとえば、トピック ブランチ A、B、C があり、いずれもマスターに統合する準備ができていないが、一緒にテストする必要がある場合、QA ブランチ (通常はマスターから) を作成し、A、B、C をマージします。ある時点で、QA ブランチは削除されるか、再利用されます。重要なのは、QA ブランチが永続的になることを意図しておらず、マスター ブランチと同じ制限がないことです (トピック ブランチを何度でもマージできます)。履歴が複雑になりすぎた場合は、QA ブランチを削除して最初からやり直すことができます (これは非常に自然なアプローチであることがわかりました)。

• 合流する際、いつも使用git merge --no-ff。これは2年前の「線形コミット履歴」への執着からの大きな逆転であり、コメントする価値があります。線形コミット履歴について緩和し、マージが優れていて有用であることがわかったので、私たちは頼るトピックブランチについて実際の支店最終的にマスターと 1 つになる一連のコミットではなく、マスターから外れます。git merge --no-ff必要がない場合でも、常にマージ コミットがあることを保証します。

• コミットメッセージとブランチについてはよく理解された慣例があり、さらに重要なのは、問題追跡システムと相互参照します. 当社の問題追跡システムでは数値の問題番号を使用しており、あらゆる機能 (または欠陥) に対して問題番号 (たとえば 1234) が割り当てられています。その問題に取り組んでいる場合は、ブランチを作成し_1234、すべてのコミット メッセージを で開始します"_1234: doing blah blah"。少し強迫観念的に思えるかもしれませんが、これは当社にとっては非常にうまく機能し、混乱を大幅に軽減/排除しました。

• ワークフローの定着を促進するためにgit wrapperを使用します。これは現在取り組んでいることですが、間違ったものから分岐するなどの単純で理解しやすい間違いを防ぐために絶対に必要だと認識しています（開発者が使い捨てのQAブランチからトピックブランチを作成したときに、私たちは最近完全な災害を経験しました。そのトピックブランチはライブに承認され、マージされました...そして、なかった承認されたすべてのコミットが取り込まれました。git wrapper は、何か通常とは異なる操作 (master 以外のブランチの作成、_NNNN 以外の名前のブランチの作成、_NNNN で始まらないコミットの作成など) を行うたびに確認を求めます。場合によっては、これらの操作を行う必要があるため、wrapper は防ぐしかし、これによって、人々が誤ってすべきでないことをしてしまうのを防ぐことができます。