kledgeb Ubuntuの使い方や日本語化、アプリの使い方を紹介しています。 Ubuntuの最新情報も紹介しています。

リベース利用時の注意事項

  「リベース」には、様々な注意点があります。

  他のユーザーとリポジトリーを共有している場合、十分な注意を払ったうえで「リベース」を実行する必要があります。

  さもないと他のユーザーは現在行っている作業を一旦中断・破棄し、作業のやり直しを強いられるでしょう。

  ポイント

    一言で言うなら、「すでに公開・共有されているブランチやコミットオブジェクトを、リポジトリーの管理者や他のユーザーの同意なく勝手にリベースするのは避けましょう」です。


    自分の「ローカルリポジトリー」にしか存在しない「ブランチ」や「コミットオブジェクト」をリベースする分には問題ありません。

変更履歴の変遷

  「リベース」は、ブランチの連結と統合なので、変更履歴が変わります。
  この点が「マージ」 と大きく異なる点の1つです。

  例えば、以下のようなリポジトリーがあるとします。


  ユーザーは、「fix」ブランチで行った修正を「master」ブランチに取り込みたいと考えています。
  この時、ユーザーは以下の方法を思いつくでしょう。

  1. 「fix」ブランチを「master」ブランチにマージする
  2. 「fix」ブランチを「master」ブランチにリベースする

  1.マージした場合

    「fix」ブランチを「master」ブランチに「マージ」 した場合、リポジトリーは以下のようになります。


    見ての通り、「fix」ブランチの「コミットオブジェクト」がそのまま残ります。
    マージ前のリポジトリーの「コミットオブジェクト」の履歴に、変更はありません。

    「Commit8」は、「Commit5」と「Commit7」をマージして生成された、という履歴が新たに追加されるだけです。

  2.リベースした場合

    「fix」ブランチを「master」ブランチに「リベース」した場合、リポジトリーは以下のようになります。


  「Commit8」は「Commit6」の変更内容を含んでいます。
  「Commit9」は「Commit7」の変更内容を含んでいます。

    見ての通り、「fix」ブランチに存在していた「コミットオブジェクト」が削除され、新たにリベースされた「コミットオブジェクト」が追加されています。

    リベース前のリポジトリーと比較してみると、存在していた「コミットオブジェクト」が削除されており、「コミットオブジェクト」の構成が変更されています。
     
    これは、リベース前に存在していた履歴が改変されたことを意味します。
    この履歴が改変されたという点に留意が必要です。

変更履歴管理と変更履歴の意味

  VCSを利用する理由の一つに、変更履歴管理があります。

  変更履歴の価値

    変更履歴は、プロジェクトで何が起きたのかを記録します。
    変更履歴は、プロジェクトの過去を紐解くドキュメントであり、変更履歴自身に価値があります。

    後からプロジェクトに参加する人たちにとっても、変更履歴は有用なドキュメントです。

  むやみに既存の変更履歴を変更しない

    むやみに既存の変更履歴を変更するのは望ましくありません。
    プロジェクトによっては、既存の変更履歴の改変は「改ざん」と捉えるプロジェクトもあるでしょう。

    変更履歴が変わってしまうということは、過去に行っていた実作業の記録を変えてしまうということになります。
    過去にどのように作業していたのか、把握しにくくなります。

    一方マージでは、大量の「マージコミット」 で履歴が乱雑に見えることもあります。
    あたかもLinuxディストリビューションの歴史を見ているかのように、乱雑に見えることもあるでしょう。

    しかしそれは、プロジェクトで起きた歴史であり、後続の人たちのために残しておく、という考え方もあります。

  ブランチの意味

    ブランチは、不具合対応や新機能の追加など、ある一連の作業の集まりを意味します。
    例えば以下の「fix」ブランチは、ある特定の不具合対応のために用意したブランチです。


    もし「fix」ブランチで行った作業が別の不具合を引き起こす修正だった場合、「fix」ブランチで行った作業内容を、確認のために抽出したくなるでしょう。

    しかしブランチが統合されてしまうと、「fix」ブランチで行った作業内容を抽出するのが面倒になります。

    このように、変更履歴から特定の作業を抽出して過去の状況を確認する際、手間がかかるようになります。

  複雑な変更履歴をまとめる

    後で変更履歴の情報が不必要なブランチであれば、上記は問題にならないでしょう。

    ブランチしたとしても、いつかはメインのブランチに変更内容を結合します。
    直線的にプロジェクトの変更内容を知りたい時は、変更履歴がまとまっていた方が把握しやすいでしょう。

    リベースの利点の1つは、複雑にブランチしすぎて管理上煩雑になった変更履歴を、1直線にきれいにまとめられる、という点です。   
    変更履歴の煩雑さを解消できます。

    自分の「ローカルリポジトリー」で作業を行っているなら、リベースを行い自分の変更内容と「リモートリポジトリー」側で行われた変更内容をきれいにまとめて、変更内容を整理することは有用です。

    ただし、すでに「リモートリポジトリー」に反映した変更内容を勝手にリベースするのは避けましょう。


関連コンテンツ
同一カテゴリーの記事
コメント
オプション