最近、一緒に仕事をするメンバーの流動性が高くなってきた印象があります。様々な開発を経験してきた人とかかわることが出来るので非常に刺激的なのですが、なかにはgitにあまり触れてこなかった人もいるので、gitを使う際に最初に知っておいた方が良いことをまとめてみました。（ここではイメージを持つことを優先するので、正確性に欠ける説明をする場合がありますがご了承下さい。）
前提
gitのイメージを持ちやすくするために、以下の前提で説明させていただきます。
- 一つのプログラムを複数人で分担しながら開発する
- gitで管理する対象は、
共同開発中のプログラム - 自分のコード実装は
個人用PCで行う - リモートリポジトリ（ここでは「バックアップ場所」程度の認識で良いです）は
個人用PCとは別のあらかじめ決められたサーバーマシン上に存在する
gitとは
gitとは分散型バージョン管理システムと言われることが多いです。ただこの単語だとわかりずらいので、単語を分解して説明します。
バージョン管理：
バージョン管理機能として主に以下を実施します。
- 更新履歴が残る
- 古いバージョンに簡単に戻せる（新しいバージョンにも簡単に戻せる）
- 複数人が個々に実施した変更を一つに統合できる
分散型：
サーバー上で最新バージョンを含むすべてのバージョンと更新履歴が管理されるだけでなく、個人が操作するPC上にも様々なバージョンのバックアップが作成されます。これにより、サーバー上のデータが破損したとしても、個々の環境上のデータを持ち寄ることで、履歴等も含めてある程度の復元が可能になります。
「3つのソースコード置き場」を区別する
gitのファイル置き場には「リモートリポジトリ」「ローカルリポジトリ」「作業ディレクトリ」があります。
名称 特徴 リモート
リポジトリ開発者のPCとは別のサーバー上に存在するフォルダのコト
更新履歴等も保存されている
他者と共有されているローカル
リポジトリ開発者のPC上にあるがgitコマンドを通してしかさわることが出来ないフォルダのコト
更新履歴等も保存されている
他者と共有されていない作業ディレクトリ 開発者のPC上で実際に開発者が変更するフォルダのコト
他者と共有されていない各ソースコード置き場の関係のイメージ図
ブランチによるコードの目的別管理
開発中のプログラムを管理するには、更新（バージョン）の管理が必要になります。更新の管理と言っても、「レビューが終わっているバージョン」「結合テストが終わっているバージョン」「まだコーディング途中でデバッグが出来ていないバージョン」等様々なバージョンが存在します。これらのバージョンをチームの共通認識のもと管理する際に使用するのがブランチです。
例えばdevelopブランチには「実装（デバッグ含む）＋コードレビュー」が終わった状態のコードが入っているものとします。個人作業を行うときはdevelopブランチを元にfeature/****ブランチと言うブランチを作成し、feature/****ブランチ上で作業を行います（feature/の後に変更内容の名称を付けて開発用のブランチ名とするのが一般的です）。コードに変更を加える前はdevelopブランチとfeature/****ブランチは一致していますが、変更を加えた後はfeature/****ブランチのみが更新されます。そしてfeature/****ブランチで「実装（デバッグ含む）＋コードレビュー」が終わるとfeature/****ブランチの更新内容を、developブランチに取り込みます。この一連の流れで開発する場合、個々のブランチには以下のルールが存在します。
| 名称 | 特徴 |
|---|---|
| developブランチ | 機能実装が完了したコードを管理する 結合部分の開発に利用可能 レビュー済みのコードなので複数人の確認がされていることを保証する 万が一想定外の動作をする場合はバグなので修正が必要 |
| featureブランチ | 機能実装中のコード 動作保証はない 実装者が実装完了した後にレビューも実施される レビュアーの指摘を受けて追加変更が発生する可能性がある |
ブランチの作成に制限はありませんが、「ブランチの使い方に関するルール」には一般的なものがいくつかあります。（ブランチ戦略と呼んだりします。余裕がある場合は目を通してみてください。）
gitの操作
クローン
リモートリポジトリを用いて自分の開発環境にローカルリポジトリと作業ディレクトリを作成すること。（操作③＆操作④（初回））- クローンにより作業ディレクトリにmainブランチの最新状態が作られる。
フェッチ
リモートリポジトリの最新状態をローカルリポジトリに反映すること（操作③）- 作業ディレクトリは変わらない。
- 他者が
リモートリポジトリにプッシュをすると、リモートリポジトリと自分のローカルリポジトリにズレが生じます。このずれを解消するのがフェッチです。
プル
リモートリポジトリの最新状態をローカルリポジトリと作業ディレクトリに取り込むこと。（操作③＆操作④）
コミット
作業ディレクトリで行った機能追加などの変更をローカルリポジトリに反映すること。（操作①）
プッシュ
ローカルリポジトリの内容をリモートリポジトリに反映すること。（操作②）
チェックアウト
- ブランチを切り替えること。
マージ
- ブランチ間に差分がある時に、一方のブランチに加えられた更新をもう一方のブランチに取り込むこと。
- 例：
feature/****ブランチで開発した内容をdevelopブランチに取り込むことを、「feature/****ブランチをdevelopブランチにマージする」という。
- 例：
その他のgitに関するキーワード
プルリクエスト（プルリク）
gitを用いた開発を実施する中で、他者にコードレビューを依頼する手法の一つにプルリクエスト（プルリク）があります。プルリクは「プルをリクエストする」ことなのですが、背景には「私の開発中のブランチを（ローカル環境に）プルしたうえで、レビューして下さい。」という意味があります。そして開発チームごとのルールに依存しますが、「レビューの結果問題なけれ、developブランチへのマージとリモートリポジトリへのプッシュをしてください。」という依頼が含まれることが多いようです。
最後に
最初にgitに持った印象は「コマンドで操作しなければいけない」「操作が複雑」などの理由で「とっつきにくい」といった感じの人も多いのではないでしょうか？しかし現在はSourceTreeなどのgitクライアントツールも普及し、最初に感じたハードルはかなり低くなっっていると感じます。今回は最初の一歩を踏み出す際に知っておくべき内容として、入門的な内容を記載しましたが、gitの機能のほんの一部でしかありません。まだまだ覚えるべき機能はありますが、今回記載した内容を知っているだけでも大きな恩恵を受けることができるはずです。少しづつ知っている機能・使える機能を増やしていけばよいので、まずはココから始めてみてください。（ちなみに私は「gitのすべての機能を使いこなしている人はいない」と思っています。）
