「Git って何？」という疑問に対して、簡単で分かりやすい説明がネット上にどうしても見当たらなかったので、５分くらいで読める範囲で解説してみようと思い、まとめてみました。「そもそも Git を知らない人」「エンジニアじゃない人」などの入門者をメインの対象としますので、すごく端折って記載しています。
難しい話は置いておいて、ポイントだけさくっと知りたい方に向けているものとして、ご理解下さい。
Gitとは？
Git（ギット）とは、コンピュータ上のファイルなどに発生した変更を記録し、その記録履歴を管理するための「バージョン管理ツール」です。また、複数の作業者が同時に変更を行ったり、複数の履歴を共同で管理するための機能をあわせ持っています。
Git では、管理したいファイルが一つでなく、たくさんあったとしても（プログラムのソースコードなど）、まとめて一つの「管理対象」と見なします。具体的な運用では、ファイルシステム上の特待のフォルダーに関連するファイルをすべてまとめて、そのフォルダーをまるごと１つの「管理対象」とみなす事が多いです。
このような管理対象のひとまとまりを、Gitでは「レポジトリ」と呼びます。Git レポジトリには、管理対象に関するすべての変更履歴を記録でき、過去に保存した状態を指定すれば、その状態を閲覧したり、再現したりできるのです。具体的には、管理対象にしたフォルダー内で、ファイルが更新されたり、ファイルが増えてたり減ったりしても、すべて記録できる、というイメージですね。
「レポジトリ」は、あまり聞き慣れない言葉かもしれないのですが、 Git の説明をするときに重要な単語なので、あえて一番最初に説明しておきます。
Git を使ったチームでの共同作業
Git 自体はローカルで（＝手元のPC上で）動作するツールです。基本的には個人のPC上で完結するツールなのですが、チームでの同時作業を行いやすくするため、遠隔地にあるサーバー上の Gitレポジトリの存在を前提とする「リモートレポジトリ」という概念を取り入れています。
リモート（ remote）とは「遠隔地にある」という意味の英語です。自分のPC上でなく、別の場所にあるサーバーに保存されているレポジトリだよ、という意味ですね。
リモートレポジトリは、離れた場所にあって、複数の作業者が同時に閲覧したり、また記録をダウンロードしたり、アップロードしたりするために使います。「チームみんなが共同で利用するバックアップ」みたいなイメージが近そうです。
チームでプログラミングしてソフトウェアを開発をする時、多くの場合は、チームで共有するリモートレポジトリを１つ用意して、メンバーがファイルの変更内容をそこにアップロードし合う事で、共有された１つの変更履歴を一緒に作りあげるように作業します。
こうして、複数の人でも、足並みを揃えてスムーズに開発を進めることができるのです。
外部の Git レポジトリのホスティングサービス
実際にこのようなリモートレポジトリを用意するためには、例えば、共有のネットワーク内に、別の共有サーバーを用意して、そこに Git のリモートレポジトリを設定して設置・・・、などと作業する事になるのですが、正直かなりめんどくさいです・・・。
でも、世の中は便利になりました。今や（結構、昔からですが・・）、上記のようなめんどうな事を避けて楽をするため、別の人が、提供する「リモートレポジトリのホスティングサービス」を誰もが簡単に利用することが一般的となっています。
いうなれば、「うちのサーバー、Git のレポジトリ設置に使いやすくしておいたから、誰でも使っていいよ〜。」という人がでてきた、イメージです。
代表的なレポジトリホスティングサービスには、「GitHub（ギットハブ）」や、「BitBucket（ビットバケット）」「GitLab（ギットラブ）」などがあります。聞いたこと、ありますよね？そのようなホスティングサービスを利用することで、誰もが共有のサーバー環境を立ち上げる手間を省いて、すぐに共同開発を始める事ができるのです。
これらのサービスはすべて無料で利用を開始できますし、また、月額でいくらかお金を払うと、より多くの機能を利用することができます。Git が広く普及したので、このようなビジネスが成り立つのですね。
GitHub の機能
上記のようなリモートレポジトリのホスティングサービスでは、通常、レポジトリのホスティングだけでなく、共同開発をもっと便利にする、付加的な機能を多く揃えています。使いやすいサービスのほうが、利用者が増えて、ビジネスがうまくいきますからね。
最もシェアと支持を集めているのが GitHub 社が提供するサービス「GitHub」です。GitHub では下記のような Web ページが用意されており、Wiki、チャット、タスク管理など、チームでのコミュニケーションを円滑にするのを助けるような機能が満載です。
リモートレポジトリとの通信機能
共同開発に少し話を戻します。
Git で例えば、自分の手元の Git レポジトリに記録した変更履歴を、リモートレポジトリに送信して反映することを「push（プッシュ）する」、また、その逆の操作を「pull（プル）する」と言います。これらの単語は、Gitを使ったことがなくても、どこかで耳にした事があるかもしれませんね。
Git はオープンソース
また、Git 自体のはいわゆるオープンソースで、無料で利用できるソフトウェアライセンスが適用されていますので、誰でもすぐに利用することができます。ただし「ライセンス」と呼ばれる規約を守ることが条件です。Git が採用しているライセンスは、GPU (GNU General Public License)と呼ばれるものです。
すこし話題がそれますが、「GPU」は、言うなればこのような約束です。
「GPUの下に配布されたソフトウェアは、その利用方法に対して制約を課してはならない。その代わりに、再配布する場合、そのソフトウェアは必ずGPUの下に配布しなければならない」
この規約により、Git ソースコードの改変や、利用することの自由が永遠に守られます。その結果として、Git を使った新しいツール（GitHubは最たる例です）やプロジェクトが生まれ続け、発展が続いてい行きます。このように、利用自体は無償でも、利用者が増えたり、付随するビジネスや活発になったりする事で、そのシステムが改善・開発される事が多くの新しい利益を生み出すことになり、望んで開発に参加する人々（コミュニティ）が生まれていきます。これがオープンソースプロジェクトの仕組みです。
多くの他のオープンソースのプロジェクトと同様に、Git は今も多くの「メンテナー」と呼ばれる有志によって、改善と開発が続けられているのです。下記のリンクから、GitHub 上の Git の最新のソースコードにアクセスできます。今や、通算で１０００人を超えるメンテナーが開発に参加しています。望めば誰でも（あなたも・・）開発に参加することができます。
バージョン管理ツール「Git」
さて、ここからは、Git が何をしてくれるのか？実際どのように動作するのか？について、掘り下げていきます。
「バージョン管理」とは何か
Git を知るためには、先に「バージョン管理」について、すこし知っておく必要があります。
簡単な例をあげてみます。例えば、あなたの会社のチームで夏にキャンプに行くことにしたとしましょう。いいだしっぺの企画係Aさんが、チームの共有フォルダに、以下のような資料をアップしました。みんなで一緒にプランを立てたいとの事です。
夏のキャンプ情報フォルダ ├キャンプ参加者リスト.xls └キャンプ場の候補.docs
さて、チームメンバーに、計画する作業を分担したので、みんなが共有フォルダにアクセスして、それぞれのファイル更新を行っていきます。
その１週間後、気づけば共有フォルダはこんな状態になっていました。
└夏のキャンプ情報フォルダ ├キャンプ参加者リスト_20170301.xls ├キャンプ参加者リスト_20170301_backup.xls ├キャンプ参加者リスト_20170304.xls ├キャンプ参加者リスト_20170304_2.xls ├キャンプ場の候補_20170303.docs ├キャンプ場の候補_20170303_1.docs ├キャンプ場の候補_20170309_1(1).docs └キャンプ場の候補_20170310_藤原追記.docs
だれが更新したのかわからないままどんどんファイルが変更・追加されたり、ファイルの種類が増えたり、誤って上書きされたり、最新がわからなくなったり・・・。こんな共有フォルダの混沌は、多くの人が経験しているのではないでしょうか。
さて、上記のような問題を解決するため、言い出しっぺのAさんが、すこし工夫してファイルの更新の管理を行うことにしました。規則正しくフォルダを名前づけるように「ルール」をみんなに強制したのです。
考え方としては、ファイル群をフォルダーにまとめて、そのフォルダに一律な番号をつけて、変更があるたびに保存します。
├夏のキャンプ情報フォルダ(1) ├夏のキャンプ情報フォルダ(2) ├夏のキャンプ情報フォルダ(3) ├・・・ └夏のキャンプ情報フォルダ(23)
随分見やすくなりました。
この方法がベストだったかどうかは別にして、このような「更新履歴の管理」こそ、いわゆる「バージョン管理」です。更新を整理して記録していくことで、混沌を防ごうという試みです。
上記の例では、１回，２回，３回、・・、誰かが更新するたびに、その都度、その状態のバックアップを残していきます。これらのフォルダの一つ一つは「バージョン（version）」と呼ぶ事ができます。
バージョンをうまいこと管理する
さて、上記の方法でスッキリ感は出たものの、１０回、２０回と更新があるたびに、どんどんフォルダが増えて、だんだんごちゃごちゃしてきました。本来必要なのはほとんどの場合「最新のフォルダ」だけなので、そのフォルダだけ見える場所に残して、残りを別の場所に隠してしまいましょう。
「昔のデータ」というフォルダを新しく作り、一つ階層を下げて配置してみます。
├夏のキャンプ情報フォルダ └昔のデータ ├夏のキャンプ情報フォルダ(1) ├夏のキャンプ情報フォルダ(2) ├夏のキャンプ情報フォルダ(3) ├ ・・・ └夏のキャンプ情報フォルダ(23)
だいぶ良くなりました。
もっときれいにするために、開かれることが少ない「昔のデータ」を完全に別の場所に移して、見えにくくします。
└夏のキャンプ情報フォルダ
// どこか別の場所・・・
└昔のデータ
いやー、すごくスッキリしました。
これで、最新を知るためにはどのファイルを見ればいいか、間違えようがないですよね。
もし、どうしても昔のデータが見たくなった時、あれ？昔のデータはどこ？となりますが、別の場所に保存してあるだけで、確実に「残っている」のです（近くに見えないだけ）。もし見たくなったときだけ、そこに行って、探して取ってくればよいのです。
バージョン管理ツールの登場
上記のバージョン管理により、だいぶ混沌は回避できました。
一方で、上記のようなフォルダー操作を手作業で毎回行うのは、そもそも面倒ですし、チームでルールを知らない誰かが、勝手にいろいろ変更してしまって「あれ、あのファイル、どこに置いたの？？」「フォルダ構成、勝手に変更したの誰？！」とか、ルールを徹底できるのかどうかも不安があります。
みんなでできるだけシンプルに、そして同じルールで管理方法を統一するための「仕組み」が必要です。
そんなときこそ「バージョン管理ツール」が役に立つときです。みんなで、同じツールを使えば、自動的に同じルールになって、混乱は防げるはずです。
Git = 今一番いけているバージョン管理ツール
さて、いよいよ Gitの登場です。Gitはバージョン管理ツールとして本当にイケていて、いまや大人気です。プログラミングのためにたくさんファイルを更新しなければいけない、いまどきのソフトウェアエンジニアには、Gitはもはや必要不可欠なツールとなっています。
Git を使うと、上記での説明してきたような「バージョンの管理」作業が、すごくシンプルな操作で可能になります。
上記の「キャンプ」の事例はあくまで例ですので、、実際のキャンプの計画で Git を使ってバージョン管理をする事はないと思いますが・・、もっとたくさんのファイルを扱う時、特に複数の人間が一緒にプログラムを開発する「ソフトウェア開発」などには、必要不可欠なツールになっています。
Gitについて、本当に本当に詳しく知りたい人は、あとで、Pro git: gitの内側を読んで見てください。GITを使った事がない人だと、少し（かなり？）難しいかもしれませんが、本当に詳しく、正確な説明があります。
Git はどうやって使うの？
ここからは、実際にGit を使う時はどのような操作を行うのかを、少しだけかいつまんで紹介します。
Git でバージョンの保存
Git で行う操作の８０％以上は「ファイルを更新したら、バージョンを保存する」という操作だと思います。そんなとき、Gitがそれをどうやって行うか？という点に関して解説します。でも、実際は概ね上記で書いたような動作を自動的にGitがやってくれる、という事だけなのですが、もう少しだけ細かく見ていきましょう。
変更の保存「コミット」
さて、Git では、現在のファイルの状態を、あとで探したり見直したりできるように、コメント（メモ）をつけて記録する事になっています。
上記のキャンプフォルダを Git で管理し始めると、こんなふうに、Git が「.git」という隠しフォルダを追加します。
夏のキャンプ情報フォルダ ├キャンプ参加者リスト.xls ├キャンプ場の候補.docs └.git
この.git フォルダ内には、古いバージョンの情報など、過去の記録に関する情報がすべて保存されています。これは、ちょうど上述のキャンプの例で言えば、過去の記録をまとめて突っ込むフォルダという役割に似ていますね。
MacOSでは「.（ドット）」をフォルダ名の最初につけると、finder上は「隠しフォルダ」として扱われて、見えなくなりますね。（Windowsの場合はこうではないかもしれませんが、Winの事はよく知らないです・・）
さて、例えばあなたが何かファイルを更新したとして、バージョンを保存するとします。その時は、こんな操作を行います―ソフトウェア開発者の人の多くはターミナル（黒い文字だけの、怖がられることの多い画面・・）で下記のようなコマンドを打つ事が多いです。
// gitで、変更を記録するコマンド git commit index.html
これだけです。（実際は、「git add 」などのコマンドも利用しますが、今回は触れません）ターミナルでの Git 操作は本当に一瞬です。
上記を見て分かるように、Git上で「バージョンを記録する」操作を、Git用語で「コミット（commit）する」と言います。どこかで聞いたことあるのではないでしょうか？（ラ◯ザップの話じゃないです、念のため）
MacOSの標準ターミナル。Git の操作に利用できる。
え？ターミナルの利用は、必須なの？
ソフトウェア開発者じゃない人は、ターミナル（文字だけの黒い画面）なんていっさい使わない人も多いと思います。
そういった方にも、使いやすいGitツール（アプリ）があります。例えば「SouceTree」というイケているGitアプリです。結構いけてますので、アプリ上でポチポチやれば、ほとんどのGit操作が可能です。
でも、アプリもいいのですが、ターミナルのコマンド操作に慣れると、アプリでぽちぽちやるより、Git操作は３〜５倍くらい速い（当社比）と思います。
Gitを使って、昔のバージョンと比較して差分を調べる
ついでに、「あれ、このファイル誰が更新したんだろう・・、なんか違うけど、どこが変わったんだろう？」なんてときがよくありますが、Gitでは、簡単に昔のバージョンを見たり、比較したりすることができます。
例えば、以下のコマンドで、すぐに差分を見ることができます。いちいち別の差分比較ツールを開く必要はないです。
git diff <比較元のバージョン名> <比較先のバージョン名>
このコマンド一撃で、簡単に変更内容を調べられます。
「え、さっきどこを変更したの？」なんて会話とはもうさよならです。もちろん、コマンドじゃない方々は、もちろん上記のSourceTreeを使って全て同じ事ができます。
Gitを使って、昔のバージョンに戻す
昔のバージョンを取り戻します。Git でバージョンを保存していくと、このように履歴がたまっていきます。履歴を表示するコマンドは、
// Git で変更履歴のメモを見るコマンド git log
* a86a1ad 千葉県のキャンプ場を追加。 * ea8c91a キャンプ場候補をたくさん追加。 * a2b0a16 メンバーを追加。 * 2aee3d9 最初のコミット。
先頭のアルファベット記号の羅列が、各バージョンをあらわすIDになっているのですね。ちなみにこのIDは「SHA-1（シャーワン）」と呼ばれる暗号化をつかっていて、自動で生成されれます（くわしくはWikiどうぞ）その後に続く１文はメモのようなもので、Gitではコミットを作るたびにメモを付け加える事になっています。
例えば、最初のコミットの状態を再現したい時は、
git checkout 2aee3d9
と、操作すれば、すぐにその時の記録を Git が一瞬で再現してくれます。Git を使い慣れていない人は、一瞬すぎて何が起きたのか分からないレベルです。コマンド一撃で履歴をさかのぼれるのは、本当に簡単で便利です。
と・・・、ここまで３分くらいでしょうか。以下は、もう話が細かくなってきますので、急いでおられる方は、お仕事に戻っていただいて大丈夫そうです。読んで頂いてありがとうございました。お時間のあるかたは、もうすこし続きます。
Gitについての豆知識
Gitのこれまで
Gitは、2005年末にバージョン管理ツールとしてはじめてリリースされてから、その利便性から順調に広まりを見せます。だいたい2010年前後には、Google社を始め、多くの開発者や、会社に支持されて利用されるようになっていました。ちなみに筆者がGitにはじめて触れたのもこの頃です。
2017年の今日となっては、ソフトウェア開発者が利用するバージョン管理ツールにおいて、Gitのシェアはダントツとなりました。 要は「イケていて、本当にみんな使っているツール」になっているということです。ツールを使う事に抵抗を感じている人も、もはや「長いものには巻かれておくべき」というレベルです。
ちなみに、ひと昔前は「subversion」という別のバージョン管理ツールが最も一般的でしたが、Gitの台頭により、そのシェアはかなり廃れたようです。
参考までに、Google Trendでの検索数の相対的な推移のチャートを貼り付けます。Gitとsubversionとを比較します。どのくらい人気かというと、このくらいうなぎのぼりです、ということです。
参考です：
また、Gitは、リーナス・トーバルズという有名な人が作ったバージョン管理ツールという背景もあります。リーナスさんは、Linux（リナックス）という有名なオープンソースのOSを最初に作りはじめた人で、エンジニア業界ではかなり有名なすごい人です（詳しくはwikiで）
Gitの英語の発音
冒頭で説明の通りGitは「ギット」です。すこし読みにくいですが、間違わないようにしましょう。
ちなみに、レポジトリは、英語、特にアメリカ英語では、「ぽ」にアクセントがあります。地域によりますが「りぱぁじとぉり」のように聞こえると思います。ケンブリッジ辞書から、発音を掲載しておきます。
ケンブリッジ英語辞書：
他にも、多くのGit用語は、そのコマンド名から、開発者の間の会話では一般的に使われています。一般的なコマンドは、Add, Commit, Diff, Pull, Pull, Fetch, Merge, Branch, など、様々です。
「プルリク（Pull Request）」って何？！
プルリクは「プルリクエスト」の略です。そして、「Pull」自体は、冒頭でも触れた git pullコマンドの事です。これは、リモートにあるレポジトリから、新しい変更履歴をダウンロードして、手元の環境を最新に更新するためのコマンドです。
「Pull Request」はGit の元々の操作ではなく、はじめは GitHub が実装した、チーム内での、コードのレビューリクエストのことでした。ソースコードの管理者（多くの場合、チーム内の一番プログラミングができる人）に対して「ちょっと変更してみたよ〜、レビューして下さい！」というのを、メールでも、チャットでもなく、GitHub 上で、リクエストする機能です。
リクエストには、必ず「変更内容」が添付されています。ですので、レビューする管理者は、変更を見て、「お、いい感じじゃん？OK！」となれば、その変更をみんなが共有している更新履歴に取り込みます（これを、マージと言います）。
管理者は最終的に、そのリクエストの変更内容を「Pull」して、メインの履歴にマージします。これが「プルリクエスト」の名前の由来です。
実際は、マージはリモートレポジトリ上で（GitHub上で）完了することも多いです。GitHubがそのような機能を実装してくれたため、マージが簡単に済むのであれば、いちいち手元に落とす必要はないですからね。要は、GitHub上で行う、「変更作って、共有レポジトリに、アップしたよ〜。レビューしてOKそうであれば、マージして、お願い！」リクエスト、という意味です。
なお、bitBucket、gitLab にも同様の機能が実装されています。チームでの共同開発にはとても便利な機能です。
書き方は、Git？git？
また、書き方は、Gitでもgit でも構いませんが、通常英語では、固有名詞は大文字で始めます。ですので、「Git」と綴るのが一般的でしょう。
ただ、gitのウェブサイトで、ロゴ画像は「git」と書かれています。おそらく、これはターミナルで打ち込むコマンドで、gitコマンドを実行する時、小文字で「git」と打ち込みます。これを意識したものだと思われます。
また、プラグラミングで変数名は一般的に小文字で始めるケースが多いです。ですので、固有名詞を小文字のみで綴るのは「ソフトウェア開発に背景がある名称」という可能性が感じられますね。
参考情報
とにかく困ったら、原典（公式の仕様書や、マニュアル）を参考にするのはやはり間違いないです。情報探すの大変だけど・・。
こちらです：
- git公式ウェブサイト
- Pro Git 日本語 (git公式のgit教科書です。日本語もあります。CCライセンス)
