開発の現場では、すでにデファクトスタンダードとなっておりますので、開発中級者から上級者の方はこのブログ記事は物足りないかもしれません。
しかし、いま一度、Gitを含むバージョン管理が普及していなかった頃の開発現場を思い出してみてください。

その頃、私はWeb開発に携わっておりHTMLファイルなどを扱ってネットショップを制作していました。
メニューを増やすなどHTMLを変更しなければならないときは・・・

1. 該当のHTMLファイルを複製して、
2. その日の日付をつけたものへリネームしてバックアップファイルとし、
3. さらにどの部分を変更したのかファイルの中にコメントして
4. アップロードする予定のファイルやフォルダの一覧をつくり、チェックしながらリリース。

これを変更の度にくり返すとバックアップファイルもどんどん増えますし、ファイル中のコメントも増えてしまって冗長化したソースコードで読みにくくなっていましたよね。
また時間も手間もかかりますし、ストレージも逼迫します。何より安心して変更できないのです。

フォルダやファイルを整理整頓できるようになり、効率化でき、精神的にも穏やかに開発ができるようにしてくれたGitの技術、概念がとても素晴らしいと思いませんか。（先人の方々、本当にありがとう）
これまでGitとは縁遠かった職種の方々も、ぜひこの恩恵を受けていただきたいです。
そのため、初級の方も理解しやすい記事にしました。説明中で例えが技術的に不適切である場合があるかもしれませんがご容赦ください。

Gitの基本情報

概要

分散型バージョン管理システムのこと。読み方はギット。

• 公式サイト：https://git-scm.com/

基本機能

複数の環境あるいは単一の環境で、変化するファイルやフォルダのスナップショットを記録し、後で過去のバージョンを呼び出すことができます。

類似の技術

Subversion、CVS（コンカレント・バージョンズ・システム）などもありますが、今回は割愛します。

Gitを使うとどんな良いことがあるの？

Gitを使うとメリットが多々あります。
日々の業務で、下記のようなことはありませんか？

このようにGitを導入する前で起きがちであった問題を解決することができます。

Gitの主な用語・操作

Gitを理解する上でカギとなる、いくつかの主要な用語・操作があります。先ほどの「Gitのイメージ図①」を再度載せますので、参考にして大枠をつかみましょう。

リポジトリ（Repository）

リモートリポジトリとローカルリポジトリの2種類があります。どちらもファイルやフォルダを保存できるストレージ（倉庫）であり、変更履歴を登録できるデータベースサーバーです。

クローン（Clone）

イメージ図には載せていませんが、リモートリポジトリからローカルリポジトリへコピーを作成する操作です。ほとんどのユーザーがこの操作を最初に行うことでしょう。

コミット（Commit）

ローカルリポジトリで変更を行ったら、コミットを行います。イメージ図ではAさんもBさんも行っています。各々わざとらしくセリフを言っていますね。
ファイルを上書き保存すると、変更した箇所がdiff（読み方はディフで、意味は差分。）として確認できます。そのdiffを確認し意図したものであれば、まずステージと呼ばれる領域にアップして「これとこれが今回のコミット対象ファイルですよ」と明示した上でコミットを行います。この時点では、リモートリポジトリへの反映はされません。次のプッシュを行いましょう。

プッシュ（Push）

コミットを実行した後、AさんもBさんも行っています。プッシュを行うことで技術的にはブランチと呼ばれるものをリモートリポジトリへ送っています。結果それまでに行ったコミットがリモートリポジトリで表示されるようになります。

プル（Pull）

Bさんだけが行っているプルという操作もあります。これは自分以外の環境で変更されたときの為のものです。
イメージ図でのBさんのように、クローンをした後で他のだれか（Aさん）が変更を行うと、Bさんのローカルリポジトリは古くなってしまいます。Aさんが行った変更を取り込むことで、最新の状態を保つことができます。
とは言え、頻繁にプルしなければならないような状況ですと厄介なことも起きたり無駄な作業も発生しますので、同時作業ではなく作業する時期をずらすか、変更するファイルを完全に分けるなどの運用にするとよいでしょう。

大枠が掴めましたでしょうか。なんとなくで構いません。使えばすぐ慣れますし、次に示すイメージ図②でも詳細が見えてくるかと思います。また「ブランチ」という、新しい用語も出てきましたのでそちらも解説します。

このイメージ図は、Gitの変更履歴が枝分かれする様をグラフィカルに表したものです。丸い記号がたくさんありますね。この〇は、一番下のものがコミットで、その他はマージと呼ばれる操作によるものです。
そして左側が過去で、右側が現在です。未来はありません。そりゃそうですよね、変更した「履歴」をどんどん記録していくわけですから＾＾；

ツリー（Tree）

まさにこの枝分かれの様子をツリーと言います。作業ツリーやワークツリーとも呼ばれます。

ブランチ（Branch）

ツリーを構成する樹木の幹と枝そのものです。任意の名前をつけることができますが、このブランチ名によってツリーの見やすさが変わりますので、運用ルールを設けて全員で守るようにしましょう。
1番の親は、ここではmainブランチで樹木の幹となります。尚、mainでなく運用ルールとして他の使いやすい名前にすることも可能です。

2番目の親は、developブランチです。

3番目は、それぞれのfeatureブランチ（feature-1とfeature-2）です。

ツリーを見ると、mainブランチからdevelopブランチへと枝分かれし、developブランチからそれぞれのfeatureブランチへと枝分かれしています。親子関係を持たせるためにブランチを作成する際にその手順を踏んでいるのです。親子関係によってツリーがわかりやすくなり、運用時のミスも減るというメリットがあります。
実際の現場では、3番目のそれぞれのfeatureブランチにてファイル変更作業を行います。もちろん運用次第で、どのブランチで変更をしてもOKなのですが、mainやdevelopブランチで変更作業を行うと、Gitの恩恵を最大限享受することはできません。mainやdevelopブランチは取りまとめ役での運用が推奨されています。

また重要なポイントとして、イメージ図②の各featureブランチにある吹き出しに示しているように、そのブランチで変更作業をしてコミットすると当然コミットは時系列で増えていきます。そして最新のコミットにブランチの先頭があるということです（まるで枝が成長して伸びているようですね）。
これはGitを利用する上で重要です。ローカルリポジトリでのブランチが今どこにあるのか、リモートリポジトリでmainやdevelopブランチを進めていないか、進めていればプルすべきか／すべきでないか。ブランチを把握をすることが不可欠です。

マージ（Merge）

ツリーをさらによく見ると、子のブランチから親のブランチへ合流していることがわかりますね。樹木で見かけることはあまりありませんが、Gitではこのマージという操作を頻繁に行いますし、またとても役立ちます。
このマージを行うと、子ブランチで行われた変更を取り込むことができますので、従来のファイル管理、バージョン管理よりも格段に安全でスピーディーになりました。
ただしマージをしたからといって各fetureブランチが干渉されることはありません（干渉するように操作を指定しなければ）。feture-1ブランチからdevelopブランチへマージをしても、feture-1ブランチの先頭は動かないのです。マージの〇ではマージ先だけに変更があったので、マージ先のdevelopブランチの位置でだけ〇が表示され、developブランチだけ枝が伸びたのです。
尚、このマージという操作はmainやdevelopブランチという重要なブランチへ影響することがありますので、現在の主流はプルリクエストという機能が利用されています。

プルリクエスト

ファイルを変更したユーザー本人ではない他のユーザーにて問題ないかを確認していただき、OKが出ればマージができるという機能です。

開発現場ではコードレビューと呼ばれており、自分よりも上級スキルのユーザーから行っていただけると理想ですが、全員おなじくらいのスキルといった場合や上級スキルの方がおいそがしい場合は立候補制または交代制にしてもよいと思います。そこは運用しながらブラッシュアップしましょう。

またコードレビューで指摘をされたときは落ち込んでしまうものですが、よりよい品質にすること、未然にミスを防いでくれたという感謝を持って、また自分自身のスキルアップにも繋がりますので、勇気を出してプルリクエストを出してみましょう。

さて、説明が長くなってしまいました。

今回のブログの目的は、まだGitを導入されていない・導入したけど使いこなせていないといった初級者の方向けに執筆しましたので、説明を簡潔にするため、いくつかの機能を省略させていただいたり、実践については触れておりません。

機会がありましたら、省略させていただいた機能と実践をご紹介したいと思います。

少しでも、Gitへ興味を持っていただけたら幸いです。