GitHubなどのホスティングサービスでは、実際に変更をマージする前に変更をレビュー、必要に応じてコメントを入れるという「プルリクエスト」機能が提供されているものも少ない。とはいえ、プルリクエストにおいて、個人的に極力やめてほしいことがある。それが、rebaseとamendである。なぜこれらはすべきではないのかについて、以下に説明してみたい。
まず、Gitでは、多くの場合、複数人がそれぞれ開発を行うというスタイルが中心になっている。多くの場合、それぞれ機能の追加や不具合の修正を目的とした「トピックブランチ」を作成し、それが一通り形になったらmasterブランチなどの「基幹ブランチ」に統合すると言った方式が主流となる。
このブランチを扱う上で、Gitではmergeやrebaseと言ったコマンドがあるが、mergeは指定したブランチの変更を合流するという意味の一方、rebaseは指定したブランチに付け替えて、現在のブランチでの変更を反映させるというものになっている。したがって、基本的にmergeではその前のコミットまでは破壊的な変更は加えられていないが、rebaseでは破壊的な変更が加えられる。
また、amendは、直前のコミットを上書きするものであり、これもコミット履歴を破壊する。
個人的にはプルリクエストを作成・レビュー中はmergeは問題ないが、rebaseとamendはすべきではないと考えている。というのは、以下の通りである。
まず、amendとrebaseは過去のコミットを破壊するという点で、プルリクエストの際のログと不整合が発生してしまうこと、どこを修正すべきで、それが反映されているのかどうかの確認が困難になってしまうこと、などが挙げられる。これらはローカルのみで行なっている、あるいはプルリクエストが作成されていない段階では実害は限定的だが、プルリクエストが作成された後だと管理上かなり不便を強いられることになる。
とはいえ、masterブランチなどの基幹ブランチが更新されるなどして変更が著しい時は、その変更をマージした際にログに残っちゃうので、あまりにも乖離が出てしまっている場合は、やむを得ないところではあるが・・・。
とはいえ、通常はプルリクエストを作った後は、管理上リベースやアメンドは極力すべきではない。多くの場合、それをやってしまうとあまり望ましくない状態になってしまうからである。
ウェブマスター。本ブログでITを中心にいろいろな情報や意見などを提供しています。主にスマートフォン向けアプリやウェブアプリの開発を携わっています。ご用の方はコメントかコンタクトフォームにて。
