Rebase vs. Merge：Gitの変更の統合-CSSチュートリアル-php.cn

Rebase vs. Merge：Gitの変更の統合

Mar 18, 2025 pm 12:09 PM

Rebase vs. Merge：Gitの変更の統合

この記事では、「Advanced Git」シリーズを継続しています。 Twitterでフォローするか、今後の記事の最新情報についてはニュースレターを購読してください！

開発者にとって効果的なGit分岐が重要です。私の以前の記事では、分岐戦略、GITの分岐モデル、分岐型、および一般的なワークフローの詳細について説明しました。コアの利点：分離ワークスペース（分岐）はバージョン制御を大幅に改善します。

この記事では、ブランチの統合に焦点を当てています。コードをメイン開発ラインに効率的に統合します。 2つの重要な方法を調べます：マージとリベッシング。

git mergeとgit rebase両方が同じ問題を解決します。あるブランチから別のブランチへの変更を統合します。ただし、それらのアプローチは大きく異なります。最初にマージを調べてみましょう。

git mergeコマンドはブランチを統合します。新しいコミットでbranch-B想像してください。 branch-Aに合流する：

 <code>$ git checkout branch-A $ git merge branch-B</code>

これにより、 branch-Aに新しいマージコミットが作成され、両方のブランチ履歴が接続されます。 GITは3つの重要なコミットを識別します。

Gitはこれらのコミットを組み合わせて統合を達成します。単純化されたシナリオ（ branch-Aに分岐以来コミットしていない場合）は、「高速」マージになります。これは、 branch-Bのコミットメントを直接効率的に追加します。

ただし、ほとんどの実際のシナリオでは、両方のブランチが独立して進化しています。 GITは、開発者が作成したコミットとは異なり、変更を組み合わせるためにマージのコミットを作成します。この自動マージを理解するには、完全な分岐履歴を分析する必要があります。

開発者が作成したコミットは、関連する変更と有益なメッセージが含まれており、慎重に構成されています。逆に、コミットは自動的に枝を接続しますが、必ずしも意味的に一貫した一連の変更を表すわけではありません。

Rebasingは、マージに代わるものを提供します。それは本質的に「より良い」ものではなく、まさに異なっています。合併だけでGitを正常に管理できます。ただし、Rebasingを理解することは貴重なオプションを提供します。

リベッシングは、自動マージコミットを回避し、線形プロジェクトの履歴を作成し、ブランチの発散トレースを排除します。

branch-Bをbranch-Aにリベースしましょう：

 <code>$ git checkout branch-A $ git rebase branch-B</code>

プロセスには3つのステップが含まれます。

一時的にコミットの削除：共通の祖先が一時的に保管された後、 branch-Aでコミット。
branch-Bのコミット： branch-Bのコミットを適用して、両方のブランチを一時的に整列させます。
branch-Aのコミットの再退任：一時的に保存されたbranch-A Commitsは、 branch-Bのコミットの上に再適用され、線形履歴が生まれます。