Gitの概要
Git は、分散型のバージョン管理システムで、主に以下のようなことが実現できます。
- 変更履歴の確認（誰が、どこを、どう変更したか）
- 過去状態への復旧
- ブランチによる、複数作業の同時進行とその統合（＋衝突回避）
また、Gitの管理対象はプログラムコードに限定されません。
ファイル/フォルダの追加・削除・移動・名前変更といった構成の変化も追えるため、プログラムコードだけでなく、各種アセットやデータファイル類の管理も容易になります。
GitとGitHubとの違い
Gitについて調べると、GitHubについて目にすることも多いかと思います。
GitHubは簡単に言うと、Gitで作成した履歴情報をWebで管理・共有するWebサービスです。
ここで詳細な説明は省きますが、GitHubはGitで作成した履歴情報をWebで管理・共有するもののため、GitHubを使うときにも、前提としてGitの知識が必要になります。
hiramameざっくり言うと、個人環境＝Git で、チーム(複数人)環境＝Git + GitHub
といった形式です。
Gitの環境構築
Git・GitHubの環境構築方法については以下の記事でまとめています。よろしければご参照ください。
以降は、Gitを扱ううえで登場する各用語や基本操作について、関連コマンドとともにまとめていきます。
リポジトリ（Repository）
リポジトリとは、変更の履歴 (＝各時点での状態) を保存する場所のことです。
要は、Gitのセーブデータみたいなもので、置く場所によって以下の二種類があります。
- ローカルリポジトリ：自分のPC上にあるリポジトリ（作業用)
- リモートリポジトリ：GitHubなどのサーバ上にあるリポジトリ（共有・統合用）
リポジトリの新規作成：
リポジトリを新規作成する時はinitコマンドを使用します。Gitを始めるときに最初に実行するのがこのコマンドです。
git initクローン(Clone)：
クローンは、リモートリポジトリの内容をコピーし、ローカルリポジトリとして作成する操作です。
つまりは、リモートリポジトリをベースとした、新規ローカルリポジトリの作成コマンドです。
git clone <リポジトリ> <複製先ディレクトリ名>新しく共有プロジェクトに参加する人や、テンプレートプロジェクトを使って作業を開始する場合は、新規リポジトリを作成する代わりにここから開始します。
ワークツリー
Gitでは、履歴管理対象としている実際の作業フォルダをワークツリーと言います。
（なぜツリー（木）と表現されるかは、後述のブランチ（枝）がかかわってきます。）
インデックス/ステージング（Staging / Index）
インデックスとは、リポジトリとワークツリーの間にある、保存対象の選択スペースです。
=変更内容をコミット対象として一時的に登録する領域。
Gitは、保存操作(コミット)を実行する際、インデックスに登録された内容のみを記録します。
（逆にいうと、登録しなければコミットの対象から外すことができるということです）
つまりは、その回の保存(コミット)で記録する対象を選択する役割があり、ここを使って以下のような処理ができ、より見やすい履歴の作成を実現します。
- その回では確定したくない変更を含めない
- 複数発生した変更を分類・整理して別コミットとして保存する
コミット（Commit）
コミットは、ファイルの変更を履歴としてリポジトリに保存する操作です。
各時点での履歴情報はリビジョンとも言い、コミットによって記録・蓄積されていきます。
Gitは履歴管理のシステムなので、保存のタイミングで以下のようなことをやってくれます。
- 前回～今回 間の差分から、記録情報(リビジョン)を作成
- コミットメッセージ(変更の説明文)の入力を受け付ける
- 重複のない英数字の名前を付与し、保存
また、コミット時は「変更の意味」が大切で、「新機能の追加」と「バグ修正」など異なる意味は異なるコミットで処理しておくことで、履歴が見やすくなります。
→説明文にあたるコミットメッセージが「一文一義」になっているかが判断基準です
タグ
タグは、コミットに名前を付ける機能です。（タグ名を使用したチェックアウトやリセットの実行も可能）
タグには、名前のみを付ける軽量タグと、追加でコメントや署名を付けられる注釈付きタグの二種類があります。
mainのブランチでバージョン情報などを記載するときは注釈付きタグ、
ローカルの作業用につい買い捨てる場合などには軽量タグを使用します。
プッシュ(Push)
プッシュは、ローカルリポジトリでコミットした変更内容を、リモートリポジトリにアップロードする操作です。
ローカルで作業→リモートへアップロード（＋必要に応じて競合の解決）を行うことで、共有リポジトリで同期をとります
- 個人で作成したブランチでリモートの履歴が複雑にならないよう、プッシュしたブランチはfast-forwardマージされるようにしておく（競合発生時はプッシュ拒否。）
- ローカルで作成したブランチを共有したい場合は、明示的にプッシュを行う
- リモートで共有しているコミットは書き換えない。
（同期しているほかリポジトリの履歴が破損するため）
プル（Pull）
プルは、リモートリポジトリの更新内容を、ローカルリポジトリへダウンロードする操作です。
複数人で作業をしている場合に、ほかの人がリモートへプッシュした内容を自分のローカルにも反映させるときに使用します。
注意点として、ローカルリポジトリ側にも変更がある場合は、pullの実行時にリモート/ローカルを統合したマージコミットが作成されます。
→つまり、pullを行う前に競合の解決が必要になるケースも出てくるということです
フェッチ（fetch）
フェッチは、リモートリポジトリの最新履歴を、FETCH_HEADというブランチとして取り込む操作です。
pull による自動的なマージ実行をせずに、別ブランチの状態のまま、リモートの更新をローカルに取り込みたいときに使用します。
要はマージを行わないダウンロード操作で、実際にマージを行いたい段階では、pullを行うか、ローカルでFETCH_HEADをマージすればOKです。
（pull ＝ fetch + merge ということです）
ブランチ（Branch）
ブランチは、履歴を分岐して記録する仕組みです。
ブランチで影響範囲を制限することで、作業の同時進行や問題発生時の原因切り分けができます。
ブランチは大きくは以下２種類で管理します。
| ブランチ種別 | 概要 |
|---|---|
| 統合ブランチ | ・”安定版”管理を担当するブランチ ・常にビルド可能(安定状態)を保ち、更新を取りまとめる ・最初に作成される main (master) などがこれに相当 |
| トピックブランチ | ・実際に作業を行う際の履歴管理を担当するブランチ ・新規作業発生時に、統合ブランチから作成する ・名称は作業によって様々ですが、対応関係としては、 replica (slave) と総称 |
※master-slave → main-replica 差し替えの背景は以下の記事が参考になります:
チェックアウト
チェックアウトは、作業するブランチを切り替える操作です。
チェックアウトを行うことで、以下の処理が行われます。
- 当該ブランチの最終状態を自身のワークツリーへ反映
- 以降のコミットを当該ブランチを対象として適用
また、現在使用しているブランチの先頭(最終更新位置)をHEADと言います。
stash
stashは、ファイルの変更を一時的に記憶しておく仕組みです。
チェックアウトで別ブランチへの移動を行う際に、コミットを行わずに変更箇所を保持しておきたい場合に使用します。
※何らかの変更が未コミットの状態でほかブランチへ移動した場合、その変更はそのまま移動先ブランチ並行する形になります。（衝突がある場合はチェックアウト失敗）
ブランチの統合(marge/rebase)
ブランチを統合する際には、marge または rebase を使用します。
marge
複数の履歴を、合流させる形で統合を行います。
ブランチごとの履歴をそのまま残せるため、
主に トピックブランチ→統合ブランチ の統合に使用。
変更の状態によって、以下のように合流します。
- 統合ブランチにトピックより進んだ変更が無い：
派生したブランチがそのままmainが置き換わるような形で統合される。（fast-forward）
-> このケースでも、ブランチを残したい場合は、non fast-forwardマージオプションを指定することで、マージコミットを作成する形で統合が可能 - 統合ブランチにトピックよりも進んだ変更がある：
統合とトピック両方の変更を一つにまとめたマージコミットが作成され、統合ブランチの先頭となる。
rebase
統合する履歴を、ブランチ末尾に追加する形で統合を行います。
最終的に残る履歴が1本になるため、
主に 統合ブランチ→トピックブランチ の統合に使用。
ポイントとして、自身のトピックブランチよりも進んだ統合ブランチの変更がある場合は、一旦統合ブランチをトピックにrebaseで統合し、動作確認してから、トピックの変更を統合ブランチにmargeする対応をしておくと、より安定した統合が可能です。