プログラミングの世界では必ず使用されているとも言えるシステムの一つにGitがあります。
GitHubはプログラマーであれば、一度は聞いたことのあるサービスですよね。
Gitはチームで開発する際には特に利用されることが多く、さらにチーム開発の利便性を向上させてくれるサービスになります。
この記事ではまず、Gitに対する知識をつけることで、Gitがどのようなものなのか、ということを理解しておきましょう。
Gitとは何か？
Gitは、コンピューターで書かれたプログラムや文書の変更履歴を管理するためのツールです。
厳密に言えば、プログラムやコードのバージョン管理を効率的に行うための分散型バージョン管理システムというのが一番正しいかもしれませんが、よくわかりませんよね。
例えば、書きかけの小説やレポートを何度も書き直す際に、それぞれのバージョンを保存しておいて、後から見返したり、前のバージョンに戻したりすることができます。
いわゆる「ゲームにおけるセーブポイント」を作成できるのがGitの強みと言えるでしょう。
このツールを使うことで、グループで作業する際にも、誰がどの部分を変更したのかがわかります。
誰でも自由に開発ができるオープンソースで開発され、主にソフトウェア開発に利用されます。
バージョン管理システムとは？
バージョン管理システム（VCS）は、ファイルの変更履歴を記録し、管理するためのツールです。
VCSを使うことで、過去のバージョンに戻すことができ、どの変更が誰によって行われたのかを追跡できます。
これにより、チーム開発においても効率的かつ安全にコードの管理が行えます。
例えばエッセイや小説を書いているときに、過去のバージョンを保存しておいて、いつでも元に戻すことができます。
家族や友達と一緒に同じ文書を編集するときも、誰がどの部分を変更したのかが一目でわかります。
Gitとその他のバージョン管理システムの違い
Gitは分散型であることが大きな特徴で、従来のVCSであるSubversion（SVN）やMercurialは集中型で、中央のリポジトリを基に動作します。
分散型のGitは、各開発者がローカルリポジトリを持ち、インターネットに接続せずとも完全な履歴を管理できます。
例えば、ある人が小説の第1章を書いている間に別の人が第2章を書くことができ、それぞれの作業が終わったら、最終的にまとめることができます。
Gitはインターネットに接続せずに自分のパソコン内で全ての変更履歴を管理することができるので、とても効率的です。
これにより、高い柔軟性と効率性が実現されています。
Gitの歴史
Gitはフィンランド出身の著名なソフトウェアエンジニアであるリーナス・トーバルズによって2005年に誕生しました。
開発された理由としては、
- それまで使用していた商用のバージョン管理システムであるBitKeeperが無償提供を終了することになり、新たなツールが急務となったこと。
- 既存のツールに対する不満から、自身のニーズを満たすために独自のバージョン管理システムの開発が必要だったこと
以上2点からGitのシステムが開発されました。
リポジトリとクローン
Gitでは、バージョン管理を行う場所のことを「リポジトリ」と呼びます。
「リポジトリ」は、プロジェクトの変更履歴を保存するための場所です。
新しい「リポジトリ」を作成すると、ファイルの変更や追加が追跡されるようになり、プロジェクトの進行状況を管理しやすくなります。
つまり、「リポジトリ」とは大切な書類やプロジェクトを保管しておくための「箱」のようなもので、この箱に入れた書類は、いつでも取り出して見直したり、元の状態に戻したりできます。
「リポジトリ」には「ローカルリポジトリ」と「リモートリポジトリ」の2つがあり、ローカルリポジトリは「ローカル」という名前の通り「自分のPC」や「自分のワークスペース」にあるので「自分だけのリポジトリ」です。
一方で、リモートリポジトリは自分のPCなどではなく、サーバー上に置かれた「リポジトリ」になります。
サーバー上に「リポジトリ」がおかれているので、自分だけでなくほかの人でもアクセスすることができるのです。
そのため、チーム開発においてはこの一つのリモートリポジトリをチームで共有しつつ、ローカルリポジトリで作業をしながらリモートリポジトリにアップロードしてチーム開発を行う、という手法が一般的となっています。
そして、誰かがすでに作ったリポジトリを自分のパソコンにコピーすることを「クローン」といいます。
クローンすることで、他の人が作った書類を自分のパソコンでも見ることができ、さらに自分の修正も加えることができます。
リモート上にある既存のリポジトリをクローンして自分のパソコン環境に「ローカルリポジトリ」として取り込むことで、他の開発者が行った変更を自分の環境で確認したり、自分が加えた変更を他の人と共有したりすることが容易になります。
コミット
Gitではリポジトリに対して記録する作業のことを「コミット(commit)」と呼びます。
コミットは時系列のつながりを持ち、作業の流れが時系列順に記録されるとともに、過去に戻ることも容易です。
そのため、 コミットすることで特定の変更点を確定し、その内容を他の人と共有できるようになります。
また、コミットする際には必ずコミットメッセージと呼ばれるコメントをつける必要があります。
誰でもわかりやすいコメントをつけることは、どんな作業をしたのかを一目瞭然で伝えられるため、非常に重要です。
リモートリポジトリに共有された際にも、修正内容を簡潔に伝える役割を持ちます。
コミットにはプログラムのコードの修正はもちろん、ファイルを追加した場合や削除した場合も含まれます。
これにより、どの時点でどのような変更が行われたのかを後からでも 追跡することができます。
プッシュとプル
リモートリポジトリについては先ほど解説しましたが、リモートリポジトリはインターネット上で共有されているリポジトリです。
これを追加することで、リモートリポジトリとローカルリポジトリを連携させ、変更内容を相互に同期させることができます。
そして同期させる時に使用するコマンドがプッシュとプルになります。
プッシュは、ローカルリポジトリの変更内容をリモートリポジトリに反映させる行為です。
これにより、自分の作業内容を他の開発者と共有し、共同作業を効率的に進めることができます。
プルは、リモートリポジトリの最新の変更内容をローカルリポジトリに取り込む行為です。
他の開発者が行った変更を自分の環境に反映させることで、常に最新の状態を保つことができます。
フェッチ
プルに似たようなものにフェッチがあります。
プルはリモートリポジトリから最新の変更内容を ローカルリポジトリに取り込む行為、と解説しましたが、取り込むのではなく最新の情報だけを確認したい場合はどうしたらいいのでしょうか。
その時に使用するのがfetch です。
fetch は、リモートリポジトリから最新の情報を取得するGitコマンドで、簡単に言うと「リモートリポジトリで他の人がどんな変更をしたかを確認するためのコマンド」です。
このコマンドを使うことで、リモートリポジトリで行われた変更をローカルリポジトリに取り込みます。
ただし、fetch は単に情報を取得するだけで、ローカルリポジトリの作業ディレクトリには影響を与えません。
例えば、友達が書き直した部分を確認したいとき、fetch で最新情報を取得して、実際に自分の作業に取り込むかどうかを決められます。
このようにfetch コマンドを使うことは、リモートリポジトリの最新情報を手に入れつつ、自分の作業には直接影響を与えないというメリットがあります。
ブランチ
ブランチとは、プロジェクトの変更履歴を独立して管理するための仕組みです。
これを使うことで、ある時点から分岐して作業を進めたり、実験的な変更を加えたりできます。
例えば、小説を書いているとしましょう。
メインの物語を「メインブランチ」として、登場人物の視点を変えたシナリオを試したい場合、そのための「ブランチ」を作成します。
このブランチで新しいシナリオを書き、気に入ったらメインブランチに戻すことができます。
こうすることで、元の物語に影響を与えずに新しいアイデアを試すことができます。
ブランチのメリット
- 非常に軽量
ブランチは非常に軽量であり、作成や削除、切り替えが容易に行えます。 - どんな作業でも可能
ブランチを作成することで、小さな修正から大規模な機能追加まで様々な作業を行えます。 - 安全な実験
ブランチを使うことで、メインのプロジェクトに影響を与えることなく新しい機能を試すことができます。 - 並行作業
複数のブランチを作成することで、チームメンバーがそれぞれ異なる作業を同時に進めることができ、開発を効率的に行えます。 - 履歴管理
どのブランチでどのような変更が行われたのかを明確に管理できます。
実際の使い方
ブランチを利用することで、同じリポジトリ内で複数の異なる開発作業を同時に進行させることができます。
例えば、新しい機能の開発を行う場合、まず新しいブランチを作成するので、各開発者は自身の作業ブランチを作成して作業を行います。
このブランチ上で作業を行うことで、メインのブランチ（通常はmasterまたはmainと呼ばれます）に影響を与えることなく開発を進めることができます。
実際の作業ではローカルリポジトリで作業する場合でも、必ずブランチを作成してほかのブランチに影響を受けないように作業する必要があります。
開発が完了したら、そのブランチをメインのブランチにマージすることで、新しい機能を取り込むことができます。
マージ
マージとは、異なるブランチで行った変更を一つにまとめる作業のことです。
これは、例えば新しい機能を開発していたブランチの内容を、メインのプロジェクトに統合する際に使います。
マージの主な目的は、別々の作業ブランチで行われた変更を一つのブランチにまとめることです。
これにより、個々の作業を統合して一つの完成形に近づけます。
例えば、小説を書いているとします。
メインストーリー（メインブランチ）に新しいシーンを追加するために、別のブランチで作業をしていたとします。
この新しいシーンが完成したら、それをメインストーリーに統合する必要があります。この時に使うのがマージです。
- メインブランチ（メインストーリー）での作業
- 新しいブランチ（新しいシーンの作業）を作成
- 新しいブランチで作業を行い、新しいシーンを完成
- 完成した新しいシーンをメインブランチに統合（マージ）
マージのメリット
- 効率的な作業管理
複数の作業を同時に進めながら、最後に統合して一つの完成形にすることができます。 - チーム開発の支援
各メンバーが独立して作業を行い、それを最終的に一つにまとめることで、チーム全体の生産性を向上させます。
マージの方法
マージは一般的に以下の2つの方法で行われます。
自動マージは Gitが自動的に変更を統合します。
特に変更が競合しない場合、自動的にマージが成功します。
手動マージは 変更が競合する場合、人間が手動でどの変更を採用するかを決めます。
例えば、同じ行を異なる内容で変更した場合などです。
Gitの基本概念
Gitの基本概念を学ぶ上で外すことができないのが「ワーキングディレクトリ」と「ステージングエリア」です。
まずは以下の画像を見てイメージをつかんでください。
ステージングエリア
ステージングエリアとは、ファイルをコミットする前に一時的に保存しておく場所です。
Gitでは、変更を直接リポジトリにコミットするのではなく、まずステージングエリアに追加します。
このワンクッションを置くことにより、どの変更をコミットするかを選別することができます。
作業自体はワーキングディレクトリで行い、変更を行ったら一度ステージングエリアに「add」するのが基本です。
ステージングエリアを使うことで、意図しない変更をコミットするリスクを減らし、コミットを整理することができます。
初めのうちは面倒に感じるかもしれませんが、このステージングエリアを理解しておくことは非常に重要です。
まとめ
この記事では、Gitの基礎知識からGitの核となる概念までを解説しました。
Gitはソフトウェア開発において不可欠なツールです。
リポジトリの作成やクローン、コミット、ブランチの活用、そしてマージの操作を理解することで、プロジェクト管理がよりスムーズになります。
ただし、この記事ではあくまで基礎の部分のみを解説したもので、本格的なコマンドなどは別の記事にて紹介していきます。
これからの開発プロジェクトにおいて、Gitの基本をしっかり活用し、バージョン管理を効果的に行いましょう。
