gitの「リベースのゴールデンルール」はそれほど重要ですか？

最近、GITの機能ブランチのリベース戦略に絶対に反対する人々と議論しました。ローカルのプライベートブランチにのみリベースを使用することは受け入れられているパターンのようですが、この「リベースのゴールデンルール」と呼ばれるように、同じ機能とブランチで作業する複数の人がいる場合はリベースを使用しないでください：//www.atlassian.com/git/tutorials/merging-vs-rebasing/conceptual-overview）

これにはコンセンサスがあることに驚いています。私は完全なリベース戦略で3年間働いたが、約20人の開発者が一緒に働いて、それがうまくいったことを推測した。

プロセスは基本的に次のとおりです。

• 機能ブランチを作成し、「myfeature」と呼び、origin / myfeatureにプッシュします。
• 他の人がそれをチェックアウトして作業するかもしれません
• マスターからリベースすることがあります： "myfeature"から、git rebase origin / master ; そして、はい、あなたはそれをプッシュする必要があります。
• 他の人がコミットをプッシュしたい場合はどうなりますか？彼らはそれをリベースするだけです：git rebase origin / myfeature。そのため、彼らは現在、早送りしており、無理なくプッシュすることができます。

尊重する唯一の原則は、機能ブランチが誰かによって所有されているということです。プッシュフォースできるのは所有者だけです。

だから、私は認める：プッシュ力があるとすぐに、エラーを起こすリスクがある。それは本当だ。しかし、エラーから回復する方法もたくさんあります。実際、3年間の開発では、強制的なミスはあまり見られませんでした。それが起こったとき、常に適切に回復する方法を見つけました。

それでは、なぜこの「リベースの黄金のルール」が広く受け入れられているのでしょうか？私がそれで逃した何か他のものがありますか？私はそれが最小限の組織を必要とすることを理解しています（すべての戦略は何らかの組織を必要とします）が、それは機能します。

強制プッシュの問題は、機能ブランチとマスターの問題ではなく、マスターを他の誰かのマスターにプッシュすることです-その同期は、先端にあるものを無視して、変更でマスターを上書きすることになります。

この危険を考慮すると、物事がめちゃくちゃにならず、修理を行うために絶対に使用する必要がある場合を除き、まったく使用しない理由があります。SCMシステムは、何かがひどく間違っていたためにこのように強制される必要はありません（そのような場合の最初のアプローチは、バックアップを復元し、操作を繰り返して履歴を保持することです）。

おそらくあなたはなぜリベースをしているのでしょうか？機能をマスターに戻す際の「クリーン」な歴史のために？もしそうなら、あなたは純粋にスタイル上の理由から分岐に関するすべての良い歴史を捨てています。IMHOの早送りマージもベストプラクティスではありません。すべての履歴を保持して、後でサニタイズされたバージョンではなく、実際に行ったことを確認できるようにする必要があります。

あなたがそれがほとんど化粧品であると言うので、リベースは必須ではありません。マージよりもずっと簡単な場合もあります。そのため、「実際の」値を持つことができますが、「時々」

リベースの不適切な使用はコストがかかる可能性があります。パニックを起こさずに復旧手順を調べるのに十分な知識があればデータを失うことはまずありませんが、「しばらくの間、誰も私が修正する必要はありません...」とは言えません。また、機能を追加したりバグをつぶしたりする（または家族と一緒に帰宅する）可能性があるときに、誰かが研究の復旧とテストに時間を費やすこともありません。

そのトレードオフで、「ごく少数の人々がリベースと強制プッシュを行う」という結果はそれほど驚くことではありません。

ワークフローによっては、リスクを軽減することができます。たとえば、「どのブランチを強制的に許可し、どのブランチを強制できないかを覚えている限り、ゼロに」します。実際には、リスクを正当化するのに十分安全かもしれませんが、人々はより大きな民間伝承に基づいて選択をすることがよくあります。繰り返しますが、実際には利益は非常に小さいので、リスクを実際にどれだけ小さくする必要がありますか？

別の音声を追加するには：

はい、説明どおりに作業すれば、使用rebaseおよび強制プッシュに問題はありません。重要な点は次のとおりです。チーム内で合意している。

rebase友人や友人に関する警告は、特別な合意がない場合のためのものです。通常、gitは、非早送りプッシュを許可しないなどして、自動的に保護します。rebase強制押しを使用すると、その安全性が上書きされます。何か他の場所があれば大丈夫です。

私のチームでは、履歴が乱雑になった場合に機能ブランチをリベースすることもあります。古いブランチを削除して新しい名前で新しいブランチを作成するか、単に非公式に調整します（私たちは小さなチームであり、他の誰もリポジトリで作業していないため可能です）。

gitプロジェクト自体も同様のことを行うことに注意してください。「pu」と呼ばれる定期的に再作成される統合ブランチがあります。このブランチは定期的に再作成され、新しい作業に基づいてはならないことが文書化されています。

だから、私は認める：プッシュ力があるとすぐに、エラーを起こすリスクがある。それは本当だ。しかし、エラーから回復する方法もたくさんあります。実際、3年間の開発では、強制的なミスはあまり見られませんでした。それが起こったとき、常に適切に回復する方法を見つけました。

Gitユーザーが共有される変更可能な履歴を回避する傾向があるのは、これらの問題を自動的に回避または修復できないためです。自分が何をしているかを知る必要があり、混乱した場合はすべてを手動で修正する必要があります。1人のユーザーに強制プッシュを許可することは直感的ではなく、Gitの分散設計に反しています。その人が休暇に入ったらどうなりますか？他の誰かが一時的にブランチを所有していますか？元の所有者が何をしていても、彼らが歩き回らないことをどのように知っていますか？そして、オープンソースの世界では、ブランチの所有者が公式に離れずにコミュニティから徐々に離れていくとどうなりますか？ブランチの所有権を他の誰かに渡すのを待つのに多くの時間を失う可能性があります。

しかし、本当の問題はこれです：混乱してすぐに気付かない場合、古いコミットは十分な時間が経過した後に最終的に消えます。その時点で、問題は回復不可能な場合があります（または、少なくとも、バックアップストーリーがどのように見えるかに応じて、回復が非常に困難になる可能性があります-Gitリポジトリの古いコピー、つまりクローンだけをバックアップしますか？）

これとMercurialのChangesetの進化作業（これは、まだ完成または安定していないことに注意してください）とは対照的です。チェンジセットがパブリックとしてマークされていなければ、誰でも好きな履歴に変更を加えることができます。これらの修正とリベースは、ブランチの所有者を必要とせず、完全に免責されてプッシュおよびプルできます。データは削除されません。ローカルリポジトリ全体は追加専用です。不要になった変更セットは廃止とマークされますが、無期限に保持されます。最後に、履歴を台無しにすると（これは日常のワークフローの通常の部分として扱われます）、自動的にクリーンアップする気の利いたコマンドがあります。 これは、共有履歴を変更する前に人々が期待するUXです。