Gitのマージとリベースの概要:それらとは何か、およびそれらの使用方法

開発者として、私たちの多くはマージとリベースのどちらかを選択する必要があります。私たちがインターネットから得たすべての参照で、誰もが「リベースを使用しないでください、それは深刻な問題を引き起こす可能性がある」と信じています。ここでは、マージとリベースとは何か、それらを使用する必要がある(および使用しない)理由、およびその方法について説明します。

GitMergeとGitRebaseは同じ目的を果たします。これらは、複数のブランチからの変更を1つに統合するように設計されています。最終的な目標は同じですが、これら2つの方法は異なる方法でそれを達成します。より優れたソフトウェア開発者になるにつれて、違いを知ることが役立ちます。

この質問はGitコミュニティを分割しました。常にリベースする必要があると考える人もいれば、常にマージする必要があると考える人もいます。それぞれの側には、いくつかの説得力のある利点があります。

Gitマージ

マージは、バージョン管理システムを使用する開発者にとって一般的な方法です。テスト、バグ修正、またはその他の理由でブランチが作成されたかどうかに関係なく、コミットの変更は別の場所にコミットされます。具体的には、マージはソースブランチのコンテンツを取得し、それらをターゲットブランチと統合します。このプロセスでは、ターゲットブランチのみが変更されます。ソースブランチの履歴は同じままです。

長所

  • シンプルでおなじみ
  • 完全な履歴と時系列を保持します
  • ブランチのコンテキストを維持します

短所

  • コミット履歴は、多くのマージコミットによって汚染される可能性があります
  • を使用したデバッグgit bisectは難しくなる可能性があります

どうやるか

checkoutandmergeコマンドを使用して、マスターブランチを機能ブランチにマージします。

$ git checkout feature $ git merge master (or) $ git merge master feature

これにより、両方のブランチの履歴を保持する新しい「マージコミット」が機能ブランチに作成されます。

Gitリベース

リベースは、あるブランチから別のブランチへの変更を統合するもう1つの方法です。Rebaseは、すべての変更を1つの「パッチ」に圧縮します。次に、パッチをターゲットブランチに統合します。

マージとは異なり、リベースは完了した作業をあるブランチから別のブランチに転送するため、履歴をフラットにします。その過程で、不要な履歴が削除されます。

リベースは、変更が階層の最上位から下に渡される方法であり、マージは、変更が上に戻る方法です。

長所

  • 潜在的に複雑な履歴を合理化します
  • 単一のコミットの操作は簡単です(たとえば、それらを元に戻す)
  • ビジーなブランチを持つビジーなリポジトリでのマージコミットの「ノイズ」を回避します
  • 中間コミットを単一のコミットにすることでクリーンアップします。これはDevOpsチームに役立ちます

短所

  • 機能を少数のコミットに押しつぶすと、コンテキストを隠すことができます
  • チームとして作業する場合、パブリックリポジトリのリベースは危険な場合があります
  • より多くの作業:リベースを使用して機能ブランチを常に更新し続ける
  • リモートブランチでリベースするには、強制的にプッシュする必要があります人々が直面する最大の問題は、強制的にプッシュするが、gitpushをデフォルトに設定していないことです。これにより、ローカルとリモートの両方で同じ名前のすべてのブランチが更新されます。これを処理するのは恐ろしいことです。
誤ってリベースし、意図せずに履歴を書き換えると、深刻な問題が発生する可能性があるため、何をしているのかを確認してください。

どうやるか

次のコマンドを使用して、機能ブランチをマスターブランチにリベースします。

$ git checkout feature $ git rebase master

これにより、機能ブランチ全体がマスターブランチの上に移動します。これは、元の(機能)ブランチのコミットごとに新しいコミットを作成してプロジェクト履歴を書き直すことで行われます。

インタラクティブリベース

これにより、コミットが新しいブランチに移動するときにコミットを変更できます。これは、ブランチのコミット履歴を完全に制御できるため、自動リベースよりも強力です。通常、これは、機能ブランチをマスターにマージする前に、乱雑な履歴をクリーンアップするために使用されます。

$ git checkout feature $ git rebase -i master

これにより、移動しようとしているすべてのコミットが一覧表示され、エディターが開きます。

pick 22d6d7c Commit message#1 pick 44e8a9b Commit message#2 pick 79f1d2h Commit message#3

これは、リベースが実行された後のブランチの外観を正確に定義します。エンティティを並べ替えることで、履歴を好きなように見せることができます。たとえば、次のようなコマンドを使用することができfixupsquasheditの代わりになど、pick

どちらを使用するか

それで、何が最善ですか?専門家は何をお勧めしますか?

チームはそれぞれ異なるため、一般化してどちらかを決定するのは困難です。しかし、どこかから始めなければなりません。

チームは、Gitリベースポリシーとマージポリシーを設定するときに、いくつかの質問を考慮する必要があります。結局のところ、一方のワークフロー戦略はもう一方よりも優れているわけではないからです。それはあなたのチームに依存します。

組織全体のリベースとGitの能力のレベルを検討してください。トレーサビリティとマージの履歴と比較して、リベースの単純さをどの程度評価するかを決定します。

最後に、マージとリベースに関する決定は、明確な分岐戦略のコンテキストで検討する必要があります(分岐戦略の詳細についてはこの記事参照してください)。成功するブランチ戦略は、チームの編成を中心に設計されています。

何をお勧めしますか?

チームが成長するにつれて、常にマージポリシーを使用して開発の変更を管理または追跡することが困難になります。クリーンで理解しやすいコミット履歴を得るには、Rebaseを使用するのが合理的で効果的です。

次の状況とガイドラインを考慮することで、Rebaseを最大限に活用できます

  • ローカルで開発している:自分の作業を他の人と共有していない場合。この時点で、履歴を整理するために、マージよりもリベースを選択する必要があります。リポジトリの個人用フォークがあり、それが他の開発者と共有されていない場合は、ブランチにプッシュした後でも安全にリベースできます。
  • コードを確認する準備ができました:プルリクエストを作成しました。他の人はあなたの作品をレビューしていて、ローカルレビューのためにフォークにそれをフェッチしている可能性があります。この時点で、作業をリベースしないでください。'rework'コミットを作成し、機能ブランチを更新する必要があります。これは、プルリクエストのトレーサビリティに役立ち、偶発的な履歴の破損を防ぎます。
  • レビューが完了し、ターゲットブランチに統合する準備が整いました。おめでとう!機能ブランチを削除しようとしています。この時点から他の開発者がこれらの変更をフェッチマージしないことを考えると、これはあなたの履歴をサニタイズするチャンスです。この時点で、履歴を書き換えて元のコミットを折りたたむことができ、それらの厄介な「prrework」および「merge」コミットを焦点を絞ったコミットの小さなセットにまとめることができます。これらのコミットの明示的なマージの作成はオプションですが、価値があります。機能がマスターに移行した時期を記録します。

結論

この説明がGitのマージGitのリベースに関する洞察を与えてくれることを願っています。マージ対リベース戦略は常に議論の余地があります。しかし、おそらくこの記事はあなたの疑問を払拭し、あなたのチームに役立つアプローチを採用するのに役立つでしょう。

GitのワークフローGitの概念について書くのを楽しみにしています。次に書きたいトピックについてコメントしてください。乾杯!

code = coffee + developer

ソフトウェア開発者のためのコーディングスクール