本当の初心者向け!Git入門のための概念から基本用語まで

本当の初心者向け!Git入門のための概念から基本用語まで

ほりでー

ほりでー

こんにちは。ほりでーです。
フロントエンドチームから、チーム開発には欠かせない「Git(ギット)」を基本から学ぶための連載がスタートします! ということで、今回はその第一回目。

具体的な使い方の説明に入る前に、そもそもGitとは何か、なぜGitを学ぶ必要があるのか、という概論から入っていきたいと思います。前半ではスキルとしてなぜGitが重要視されているのか、後半ではGitに登場する基本的な概念について、初心者にもわかりやすく説明していきます!

1. Gitが使えないと困る理由

Gitは、HTML・CSS・JavaScriptなどの
コードを管理するためのツールで、世界的に定評があります。極端な話、Gitを使えるようになったからと言って、デザインが上手くなったり、すごいJavaScriptが書けたりするわけではありません。デザインやプログラミングのテクニックとは、あまり関係がないスキルなんです。

ただし、もしあなたが何かコードを書く仕事に携わるのであれば、どんなデザインやプログラミングのスキルよりも先に、Gitを使えないと仕事に参加できない可能性があります。そればかりか、Gitを使いこなすことで
本業のコーディング効率を大幅にアップさせることができるんです!

Gitはバージョン管理システムの一種

どうしてGitが使えないと仕事に参加できない可能性があるのでしょうか?

実は、Gitは「バージョン管理システム(Version Controll System/以下VCS)」と呼ばれる種類のアプリケーションの1つで、
企業やグループでコードの管理をする際に、とても重要な役割を担っているんです。

バージョン管理システムとは?

いきなり難しそうな言葉がでてきてしまいましたが、安心してください! まずは、このVCSの役割について丁寧に説明していきます。

VCSの役割1:細かく記録を残していつでも元に戻せる

デザイナーやプログラマーにとって、自分達が書いたコードは大切な資産です。しかし、必ずどこかで間違いが起こってしまうもの。みなさんも、パソコンの中で作った書類を間違えて消去してしまったり、意図しない内容で上書き保存してしまったりと苦い経験があると思います。このようなミスに備えるためには、日頃からバックアップを取ることが大事です。

 
どれが最新? ウィンドウの中にたくさんのファイルがあるが、どれが最新なのかわからない状態

ファイルのコピーを作り、名前に日時を付けてバックアップを取るなどの方法は簡単ですが、名前を付け間違えたり、「最新の最新」「最新(本当の最新)」など意味不明な名前をつけてしまったりと、結局ファイルの管理が煩雑になってしまいます。人によって命名ルールも違うし、手作業なので名前と実際の内容が一致している保証もありません。

しかし、VCSは記録をとても細かい単位で管理してくれるデータベースとしての機能を持っています。

バージョンコントロールシステム(VCS)を使うと、データベースにわかりやすくファイルの変更を記録できます

ユーザーが「今の状態を記録してほしい!」と命令すれば、細かいことを考えずに自動的に今の状態を裏側で保存してくれる上に、
いつでも過去の記録を引っ張り出してくることもできるようになります。

VCSの役割2:ミスの特定を簡単にする

どんな敏腕技術者でも、ミスのないコードを書くのは不可能です。ミスが不可避なのであれば、できるだけ速やかにミスを修正できることが求められます。

例えば、あるサイトの中に、昔は崩れていなかった箇所でデザイン崩れを発見したとしましょう。そのミスの原因はコードのどこかにあることは確かなのですが、それが一体、いつ、どこに書いたコードなのかを見つけることは、コードの量が増えてくると簡単ではありません。プロジェクト全体で数千から数万行のコードがあることも普通なので、コードを上から順番にチェックするのはとても非効率的です。

 
VCSがあれば、どこがどう変更されたのかを正確に追跡できます。左に過去のコード、右に現在のコードがあり、その差分がハイライト表示されている。

VCSには、こんなときのために「コードを過去に記録したときの状態へ一次的に戻したり」、「コードの状態を過去と現在で比較したり、ある過去とそれよりももっと古い過去を比較する」機能が付いています。これなら、いつの段階に書いたコードがバグを生んだのか、検証しやすくなります。記録を順番に取り出し、どの記録からデザイン崩れが起きたのかを検証すれば良いのです。

VCSの役割3:誰がどんな理由で書いたコードなのかがわかる

例え一人でコードを書いていたとしても、何週間・何ヶ月と時間が経てば、昔書いたコードがどういう意図で書かれていたのかを正確に思い出すのは困難です。それどころか、企業やオープンソースコミュニティで大規模な製品を作ることになれば、コードを書く人は数十人から数百人におよぶこともあります。

 
VCSがあれば、誰がどういった理由で変更を行ったのかを追跡できます。
[fix]
refs #262 update css rules · hokkey/whitegry_plus@22e42bf – GitHub

VCSは、「役割1」でも説明したように細かい記録を残す際に、その記録の作成者が誰で、どんな作業をしていたかを強制的に残す仕組みを持っています。

この記録のおかげで、メンバー同士がVCSの記録を通じ、これまでのコードの変更意図を理解しやすくなります。過去の自分や前任の担当者が、どういう意図をもってコードを書いてきたのか、いくらでも検索できるんです。

なぜVCSを使えないと困るのか

このように、VCSを使うと僅かな手間で圧倒的に効率的なコードの管理・保守をすることができます。
こんなに便利なものを使わない手はありません! 実際に多くのIT企業やオープンソースプロジェクトでは、何かしらのVCSを使ってWebサイトやアプリケーションの開発をおこなっています。したがって、あなたが企業やオープンソースプロジェクトに仲間入りしてソースコードを書くためには、他のスキルよりも先にVCSのことを理解しなければならないのです。

とりあえず下記のことができれば、VCSで管理されたプロジェクトに参加することができます。

  • 既存のプロジェクトに自分のコードを追記し、他のメンバーと共有できる
  • 過去の記録を閲覧し、これまでの記録を辿ることができる
  • 記録を間違えて破壊したり、他の人の作業を邪魔するような操作をしない

VCSのスキルは、開発者がプロジェクトに参加するための最初の一歩と言えるでしょう。

Gitを選ぶ理由

Gitは、VCSの中でも特に人気のあるアプリケーションですが、その理由は3つ考えられます。

まず、これまでのVCSと比べて機能が優れていて使いやすいこと。次に、Gitの生みの親がLinuxの創始者で伝説的な技術者である、リーナス・トーバルズさんであることも要因の1つだと考えられます。
参考:Linuxの生みの親、リーナス・トーバルズってどんな人? |
IT系のインターンシップならエンジニアインターン

最後に、非常に優れたツールであるにも関わらず、フリーのライセンスで、誰もが無料で使い続けることができる点です。

以上のことから、Gitの最初のリリースから10年以上が経ったいまでも多くの企業が導入しています。ちなみに、LIGでも全面的にGitを使った開発をしています。

2. Gitの用語を比喩でやさしく解説

Gitを使う上で必ず出てくる用語や概念ではカタカナ言葉が多いので、まずは順番にわかりやすく説明していきます。また、複雑な関係をやさしく解説するために「写真・カメラ・被写体・撮影者・アルバム」の関係を例に出していきます。

リポジトリ

Gitを含むVCSは、基本的な機能として時系列でファイルの記録を整理でき、この記録を管理するデータベースを「リポジトリ」と呼びます。データを一元的に保管する貯蔵庫のようなものですね。

 
比喩:写真アルバム/実際の意味:記録のアーカイブ/Gitでの呼び名:リポジトリ

その都度のソースコードを「写真」に置き換えると、リポジトリは「家族写真のアルバム」のようなものです。思い出の写真が時系列順で入っているのを想像してみてください。昔を思い出したくなったら、ページをめくって過去の写真と今の写真を見比べることで、子供の成長を実感できますよね。

Gitの場合、プロジェクト単位でリポジトリを作成することが多いです。例えば、LIGブログのリポジトリであれば、そこにLIGブログと関係のあるコードだけを記録するようにします。
イメージとしては記録の詰まったフォルダでも間違ってはないのですが、リポジトリの実体は不可視フォルダとして隠されていて、Gitを通じないと中を調べたり変更を加えたりすることができない仕組みになっています。

また、既に誰かが作ったものをコピーしてくることを「リポジトリのクローン」と呼び、自分で空っぽのものを作成することを「リポジトリのイニット」と呼びます。

コミットとコミットメッセージ

Gitでは、リポジトリに現状のファイルの内容を記録することや、その結果作られた記録のことを「コミット」と呼びます。

 
比喩:インスタントカメラでシャッターを押す/実際の意味:記録を作成する/Gitでの呼び名:コミット(する)、比喩:インスタント写真/実際の意味:記録/Gitでの呼び名:コミット、比喩:インスタント写真に添えられた走り書き/実際の意味:記録の注釈/Gitでの呼び名:コミットメッセージ

写真やアルバムで例えると、コミットとはインスタントカメラのシャッターボタンを押すことや、出来上がったインスタント写真を指します。そして、コミットメッセージとはその写真に走り書きされたカメラマンの注釈と言っても良いでしょう。

Gitでは、ファイルに変更が発生するたびにコミットできます。もちろん、まとめて複数のファイルをコミットすることも、細かく1ファイルづつコミットすることも可能です。逆に、コミットしない限り、ファイルの変更はリポジトリに記録されません。

コミットする際には、自動的にコミットしたユーザの名前が記録され、コミットメッセージを残すことが強制されます。コミットメッセージには、そのコミットでおこなった変更をなるべく具体的に記述しておくと、後々記録を見直したときに便利です。
チーム開発では、良いコミットメッセージを残すことも重要なスキルとなります。

ポイントとしては、1日の作業で数回以上コミットすることです。なぜなら、Gitが記録している情報の単位は、コミットの頻度と同じだからです。もし1週間仕事をしたのに1回しかコミットをしなければ、リポジトリには大雑把な記録しか残らず、Gitを使うメリットが低下してしまいます。

ワークツリー

「ワークツリー」とは、普通のフォルダのようなものです。普通のフォルダと異なるのは、ワークツリーにあるファイルの変更がGitによって監視されているという点のみ。

 
比喩:被写体・モチーフ/実際の意味:記録の対象となるコードやファイル/Gitでの呼び名:ワークツリー

コミットがカメラのシャッターを押して写真を撮ることであれば、ワークツリーはそのカメラの被写体と例えることができます。

Gitは、現在のコミットとワークツリーの内容を比較し、そこに差分があったときに、ファイルごとに行単位で変更箇所を教えてくれます。ファイルを追加したり削除した場合も、差分として扱われます。ワークツリー内での変更は、あなたがコミットをするまでは仮の状態に過ぎないので、必ずいつかはコミットをして、リポジトリに記録するようにしましょう。

ちなみに、ワークツリーのことを「ワーキングディレクトリ」や「ワーキングコピー」や「作業コピー」と呼ぶこともありますが、意味は同じです。

ステージング

比喩:写真の構図を決める/実際の意味:作成する記録の対象を選択する/Gitでの呼び名:ステージング

ワークツリーがカメラの被写体で、コミットがシャッターを押すことであれば、次に撮る写真にどのモチーフを入れるか、構図を決める作業が「ステージング」です。

先程説明したとおり、コミットとコミットメッセージは常に1セット。1つのコミットに複数の異なる作業をまとめると、コミットメッセージにはさまざまなコメントが必要となり、煩雑なものになってしまいます。写真で例えると、いろいろなものを混ぜて撮るよりも、主役を絞って撮影した方が、カメラマンの意図がわかりやすくなるのと同じかもしれません。

始めのうちはステージングにこだわらなくてもコミットはできるので、問題なく作業はすすめられます。しかし、段々Gitに慣れて良いコミットメッセージを書こうとすると、ステージングの粒度にも関心が生まれてくると思います。写真が上手くなってくると、構図にもこだわりが出てくることと似ているかもしれませんね。

ブランチとマージ

「ブランチ」とは、複数の機能を同時に開発するときに使われる、コミットの系譜の枝分かれのことを指した概念です。

比喩:カメラマン/実際の意味:開発者/Gitでの呼び名:ユーザー、比喩:複数の写真アルバム/実際の意味:複数の開発者による並行開発/Gitでの呼び名:ブランチ、比喩:2冊の写真アルバムを1冊にまとめる/実際の意味:並行開発の終了/Gitでの呼び名:マージ

最初は1冊しかなかったアルバムの撮影に、途中から別のカメラマンが参加したとします。2人は別々の場所で異なる写真を撮るために、それぞれ別のアルバムを携えて出かけることにしました。ただし、2つのアルバムには、1冊しかなかった頃の写真が全部入っているようにしました。つまり、2人のアルバムは同じ過去をベースに、それぞれ新しい写真を追加していくことになります。この
2つのアルバムを、それぞれブランチと呼びます。

そして、二人は数日後に再開して、お互いが撮った写真を1つのアルバムにまとめ直す作業をします。この、
別々のアルバムにばらけた写真を1つのアルバムにもう一度まとめることを「マージ」と言います。例が長くなりましたが、これがブランチとマージの説明です。ブランチを使うと、同じ過去の記録を元に、混じり合うことのない新しい記録を積み上げていくことができるんです。

このような機能があると、デザイナーとエンジニアがフォームバリデーションの実装を平行しておこなっていて、2人とも共通のHTMLファイルを編集しなければいけなくなったときに役立ちます。と言うのも、一旦お互いの作業する環境を完全にわけてしまい、2人とも作業が完了してから帳尻を合わせるが可能になるからです。このわかれた環境がブランチで、帳尻合わせがマージです。

1人で開発しているときには、あまりブランチを意識することはないかもしれません。しかし、多くのチームで開発することになれば、それぞれ別々の機能を開発することも増えてきます。ファイルの変更が衝突する機会を減らすらためには、ブランチを使わなければなりません。

コンフリクト

なお、ブランチはファイルの衝突を先伸ばしにすることはできますが、完全に衝突を阻止することはできません。同じファイルが2つのブランチでそれぞれ変更され、どうしてもGitでは中身を合体できない!という状況になると「コンフリクト」が発生します。

コンフリクトが起きると、ブランチのマージは一旦保留になり、ユーザが手動でコンフリクトを解消しなければなりません。

まとめ

長くなりましたが、なぜGitが開発スキルとして重要なのか、そしてGitを取り巻く多くのカタカナ用語について、なんとなくわかっていただけたのではないでしょうか。

今回の記事をまとめると、下記のとおりです。

  • ソフトウェアの開発において、バージョン管理システム(VCS)は重要な役割を持っている
  • 開発に参加するには、VCSを使えることが必須
  • Gitはその中で特に人気の高いアプリケーションで、多くの企業やグループが導入している

Gitでの概念を写真の例に置き換えた表
itの主要な概念について記述された表です。
 
次回は1週間後、Gitの基本的な操作についてご紹介します!

LIGはWebサイト制作を支援しています。ご興味のある方は事業ぺージをぜひご覧ください。

Webサイト制作の実績・料金を見る

この記事のシェア数

ほりでー
ほりでー フロントエンドエンジニア / 堀 祐磨

デザイナーから転職してきました。毎日がホリデーです。

このメンバーの記事をもっと読む
Git編:一歩踏み出すフロントエンド入門 | 6 articles
デザイン力×グローバルな開発体制でDXをトータル支援
お問い合わせ 会社概要DL