新人エンジニアはまずGitの考え方を理解しよう
――新人エンジニアが覚えなければいけないことの一つにGitが挙げられるかと思います。しかしGitをまったく知らないと、戸惑うことも多いはずです。開発経験もなく、Gitも利用したことがない人が初めてGitを使う際、押さえておきたい点は何でしょうか？
河村：例えば、チームに入っていきなり「Gitを使ってください」と指示を受けたとしても、最初はその意味が分からないでしょう。しかし、その指示が意味することは状況によってさまざまです。
まず、Gitをはじめとするバージョン管理システムでは、ソースコードなどでの変更差分をコミットと呼ばれる単位にして、リポジトリという場所に格納しています。つまりコミットという手続きを行なうことで、その時点での変更が記録され、保存されていくのです。そのため、いつ、何を行なったのか作業の履歴を確認することもできますし、過去のある時点にデータを戻すことも可能です。さらにチーム開発ではGitを使ってコミットを共有することで、コミット履歴から自分以外のメンバーが何をしているのかを把握することもできます。
太田：もちろん、メンバーに対して自分の作業を知らせることもできます。
河村：同じく、自分自身の作業だとしてもいずれは必ず忘れてしまうので、その記録を残しておくためのバックアップでもあります。履歴を振り返ったとき、個々の作業単位で情報が得られるほうが、いつ、どのような作業をしたのかがずっと分かりやすくなります。そのため、コミットはできるだけ細かい単位で、例えば「Aという機能に対する○○という変更」と「Bという機能に対する××という変更」と分けて記録することで、Aという機能に問題が起こった際も、どのコミットでの変更によって引き起こされたものなのか切り分けが容易になるのです。そのため、新人エンジニアはまず「コミットはできる限り細かく分ける」ということを意識してみてください。
ほかにもGitを使う際に忘れてはいけない、大切な機能の一つにブランチがあります。ブランチを切る、つまり変更履歴を分岐させることで、分岐させた先の変更は別の履歴を辿っていくことになります。ブランチを切って自分の作業を行なうことで、ほかのメンバーに与える影響を最小限にすることができるのです。
また、分岐させたブランチは決して分岐させたままにするのではなく、どこかのタイミングで分岐元など変更を反映させたい場所に戻す必要があります。ブランチを結合する作業をマージと呼ぶのですが、履歴が細かく整理されており、どのブランチにマージして戻すべきかの見通しがしっかりしていれば、チームとして最後に作り上げる1本のメインツリーが実にきれいに仕上がります。履歴がそのようにきれいだと、例えばあとになって10個前の履歴としてコミットされたある部分だけを直したいと指示が来たとしても、作業の際とても役立つことになります。そのため、仕組みを理解してコミット履歴をいかにきれいに保つことができるかが非常に重要です。
これをバージョン管理といいますが、その目的を理解するためにも、新人エンジニアにはGitというツールの使い方だけではなく、ブランチの管理やコミットの履歴の管理といった仕組み・考え方をぜひ学んでほしいと考えています。
次に新人エンジニアがつまずきがちなポイントとして挙げられるのは、目の前に複数のブランチがあって、自分のコミットをどのブランチに対して行なうべきなのか分からないということでしょう。チームの開発フローに応じてどのブランチにどういった内容をコミットすべきかは、Gitでは重要なポイントです。一例として、自分がどういった作業を行なっているかを確認してもらうという観点のWork In Progressという考え方があります。特定のブランチに開発途中のコードのコミットを積み重ねていき、先輩や上司にレビューをもらうという方法です。新米エンジニアはGitの使い方だけでなく、ぜひそのような開発フローも学んでほしいと思います。
なお、これは新人に限った話だけではないのですが、会議という形で実際集まってレビューせずとも、GitHubやGitLabなどのツールを使うことによりオンラインでコードレビューができるということは、開発者として知っておいていいことです。Web上で差分を見ることができ、掲示板のような形式で差分に対してコメントをやりとりしたり、ソースコード上の位置をURLで直接指定してコメントを入れたりできる機能があるのです。Gitだけでなく、GitをラップしたWebツールと組み合わせることで、コードレビューも全部オンライン上で、しかも記録が残る形で済ませられます。時間もぐっと短縮し、レビューのための会議を開く必要もなくなるというメリットもあります。
Subversionとの最大の違いを感じたのはローカルコミット
――新人エンジニアは、Gitの仕組みを通じてバージョン管理という概念を理解すべきということですね。では、Gitのほかにも有名なバージョン管理システムにはSubversionがあると思いますが、これまでSubversionを利用していたけれどGitは使うのは初めて、という人がGitを使う際に押さえておきたいポイントはありますか？
河村：Subversionは集中型と呼ばれるシステムなので、単一のサーバでバージョン管理がなされています。そのためサーバに対してコミットできる環境でないと、バージョン管理ができません。オフラインの状態など、コミットできない状況には往々にして直面するもので、そのときに細かい単位でコミットができずに、履歴が見づらいものになってしまうという問題があります。
それに対してGitは分散型と呼ばれるシステムであり、コミットはローカルに対して行ないます。そのためオフラインでも手元にあるリポジトリにコミットできるのです。そして、ローカルにコミットした変更差分の履歴をまとめてサーバにプッシュ（送信）して同期することで、ほかのメンバーと共有できます。自分の変更差分をどのような状況でも、たとえオフラインであっても管理できるということはGitの大きな利点で、私もローカルコミットを初めて体験したときは感動しました。
太田：常に細かいコミットを行なえる利点を持つGitは、一つの案件を一人で作るのではなく、複数人で同時に開発する並行開発と呼ばれる開発フローにとても有効です。いまでは当たり前のフローとなった並行開発を円滑に行なうためにも、SubversionユーザーはまずGitのコミットとプッシュという考え方や仕組みを理解する必要があると思います。
河村：ほかにもステージングという概念もSubversionユーザーが理解すべきことでしょう。あるディレクトリ内のソースコードを編集したときでも、その内容はいくつかの項目に分けられます。例えば同じディレクトリの中に、A、Bという別々の機能についてのコードがあるとして、それぞれに対して同時に変更作業を行なったとします。コミット履歴上で「Aの○○に対する変更」「Bの××に対する変更」と分けて管理することが大切なのは先ほど述べたとおりですが、SubversionではそのディレクトリをコミットしようとするとAもBも含んだ一つのコミットとして扱われてしまいます。Gitではコミットをする前に、コミット対象を指定するステージングと呼ばれる作業を行なう必要があります。コミットの前に一度ステージングを挟むことで、どの変更を一まとまりでコミットするかを普段から考えられるようになるのです。ステージングを行なうためにGitではaddというコマンドを用います。
太田：Subversionではaddとは単にリポジトリへのファイルの追加という意味であり、ファイルを追加した際に一度だけ用いるものでした。対してGitではaddというコマンドが、ステージングを行なう、という意味になっています。コミットの前に一度addを挟むのはなぜか、その意義や管理の仕組みをきちんと理解することは、SubversionユーザーにとってGitを使いこなすために大切になってきます。
開発を統べる存在、Gitを学ぶための本
――『エンジニアのためのGitの教科書』はそれらGitの使い方や仕組みを学ぶことのできる本なのですね。お二人が執筆に際して意識されたことをお聞かせください。
河村：本書は全体を通して、概念を理解できればGitを使いこなせる、というテーマで一貫しています。例えば、ブランチをマージしてメインツリーに戻すとき、どうしたら履歴がきれいになるか悩んでいるとします。その際にもGitの考え方の一つであるオブジェクト（コミット）の親子関係や、ブランチとはコミットを指している矢印にすぎない、という概念を理解していると、矢印を移動させるだけでマージができ、なぜマージコミットが必要なのかが理解できます。一例ですが、本書はそのような実践の場で役立つ本を目指しています。
また、個々のコマンドについての解説も、その構造やなぜこういった考え方になっているのか、それらのポイントに力を入れて書いています。
太田：コマンドなどはWebで検索すれば情報がいくらでも出てくるため、コマンド自体よりも動作の仕組みやその理由などの概念的な部分を重点的に伝えようと考えました。Gitの仕組みを学ぶための本として、本書を長く使ってもらえれば幸いです。中身が濃く、長く使える本になったと思います。
河村：私も同感です。本当にさまざまなポイントについて話し合いました。具体的には、個々のメンバーが知っておかなければならないことだけでなく、チームとして開発フローの次の段階に進むときはここで引っかかるはずだ、開発フローの設計の次はここで引っかかるはずだ、と順番に辿っているため、長く使える本に仕上がったのだと思います。初級編であってもチームリーダーになるぐらいまでは間違いなく使うことのできる本です。
新人が同期に差をつけるための本
河村：しかしまず、本書はまさに「これから学ぶ人」にこそ、本当に読んでほしいと考えています。
太田：例えば、4月にエンジニアとして入社した人が、本書でGitを1年間くらいかけてきちんと学んでもらえれば、1年後には同期ととても大きな差がつくはずです。なので、途中でめげそうになったとしても、友達や先輩に聞いてモチベーションを保ち、最後までこの本を読みきって習得してほしい、という思いがあります。
河村：Gitに触れたばかりの頃は、Gitがいくら便利だと言われても、何が便利なのか分からないままコミットとプッシュを繰り返す、ということがよくあります。
太田：コミットとプッシュしか利用したことがないような人にも、この本を読んでもらえるといいですね。僕も最初は、コミットとプッシュしかしていませんでした。その理由はきっと、チーム開発をしたことがないからだったと思います。チーム開発をしたことのない人は、同僚に擬似チーム開発をしてもらって勉強するのもいいと思います。
河村：そしてぜひ、次のステップとして本書の上級編へと進んでもらいたいと考えています。例えばチームリーダーになると、ブランチどうしの関係が分からずマージできなくなったメンバーに泣きつかれることがあるかもしれません。しかし、上級編を読んでGitの仕組みをきちんと理解していれば、ネットワーク図を見るだけで、それぞれのブランチについて、マージをした際の共通の親となるコミットはどれかが分かり、でき上がるネットワーク図のイメージも頭の中で組み上げられるようになります。
私が勤務しているリクルートテクノロジーズでも、Gitを仕組みから理解して使いこなせるかどうかが重要です。弊社ではさまざまなチーム開発フローを実践していますので、フロントエンドの開発やインフラのコード化などに興味がある方がいれば、ぜひ一緒に働いてみたいですね。
――最後に、本書を読んでGitを学んでみようと思った人に、メッセージをいただけますか？
河村：個人的に、Gitとはただのコマンドではなく「開発を統べるもの」だと思っています。この本でそんなGitを学んで、ぜひ同期に差をつけてください。
