開発ブログ
Git、CSS、HTML、正規表現など、入門者がつまづきそうなポイントを中心に、役立ち情報発信します。。

Gitとは?入門向け基礎知識のまとめ

最終更新:2018-06-22 by Joe

「Git って何?」という疑問に対して、簡単で分かりやすい説明がネット上にどうしても見当たらなかったので、5分くらいで読める範囲で解説してみようと思い、まとめてみました。「そもそも Git を知らない人」「エンジニアじゃない人」などの入門者をメインの対象としますので、すごく端折って記載しています。

難しい話は置いておいて、ポイントだけさくっと知りたい方に向けているものとして、ご理解下さい。

Gitとは?

Git(ギット)とは、コンピュータ上のファイルなどに発生した変更を記録し、その変更履歴を管理するための「バージョン管理ツール」です。同時に、複数の作業者が同時に変更を行ったり、複数の履歴を共同で管理するための機能を併せ持っています。

Gitでは、関連するファイル群(プログラムのソースコードなど)をまとめて一つの管理対象と見なします。具体的な運用では、ファイルシステム上の特定のフォルダーに関連ファイルをまとめて、そのフォルダーをまるごと1つの管理対象とみなす事が多いです。

このような管理対象のひとまとまりを、Gitでは「レポジトリ」と呼びます。Gitレポジトリには、管理対象に関するすべての変更履歴を記録でき、過去に保存した状態を指定すれば、その状態を閲覧したり、再現したりできるのです。

Git による変更履歴の保存

Git を使ったチームでの共同作業

Git 自体はローカルで(=手元のPC上で)動作するツールです。

基本的には個人のPC上で完結するツールなのですが、チームでの同時作業を行いやすくするため、遠隔地にあるサーバー上の Gitレポジトリの存在を前提とする「リモートレポジトリ」という概念を取り入れています。

リモートレポジトリは、「チームみんなが共同で利用するバックアップ」みたいなイメージが近そうです。多くの場合は、チームで共有するリモートレポジトリを1つ用意して、メンバーがファイルの変更内容をそこにアップロードし合う事で、共有された1つの変更履歴を一緒に作りあげるように作業します。

Git を使った共同開発のイメージ

外部の Git レポジトリのホスティングサービス

実際にこのようなリモートレポジトリを用意するためには、共有のネットワーク内に、別の共有サーバーを用意して、そこにリモートレポジトリを設置して・・・、などと作業する事になるのですが、正直かなりめんどくさいです・・・。

でも、世の中は便利になりました。今や(結構、昔からですが・・)、上記のようなめんどうな事を避けて楽をするため、第三者が提供する「リモートレポジトリのホスティングサービス」を誰もが簡単に利用することが一般的となっています。

代表的なレポジトリのホスティングサービスには、「GitHub(ギットハブ)」や、「BitBucket(ビットバケット)」「GitLab(ギットラブ)」などがあります。聞いたこと、ありますよね?そのようなホスティングサービスを利用することで、誰もが共有のサーバー環境を立ち上げる手間を省いて、すぐに共同開発を始める事ができるのです。

これらのサービスはすべて無料で利用を開始できますし、また、月額でいくらかお金を払うと、より多くの機能を利用することができます。

Git レポジトリのホスティングサービス

GitHub の機能

リモートレポジトリのホスティングサービスでは、通常ホスティングだけでなく、共同開発を便利にする機能を多く揃えています。

最もシェアと指示を集めているのがGitHub社が提供するサービス「GitHub」です。GitHub では下記のようなWebページが用意されており、Wiki、チャット、タスク管理など、チームでのコミュニケーションを円滑にするのを助けるような機能が満載です。

GitHubはリモートレポジトリのホスティングサービス。
GitHub(ギットハブ)は、リモートレポジトリのホスティングだけでなく、Web上利用できる、資料(Wiki)や、課題リストの管理など、様々なコラボレーションのための機能を備えている。

リモートレポジトリとの通信機能

Git で例えば、自分の手元のGitレポジトリに記録した変更履歴を、リモートレポジトリに送信して反映することを「push(プッシュ)する」、また、その逆の操作を「pull(プル)する」と言います。これらの単語は、Gitを使ったことがなくても、どこかで耳にした事があるかもしれませんね。

Git のリモート通信機能 push と pull

Git はオープンソース

また、Git自体のはいわゆるオープンソースで、無料で利用できるソフトウェアライセンスが適用されていますので、誰でもすぐに利用することができます。ライセンスはGPU (GNU General Public License)と呼ばれるものです。

すこし話題がそれますが、、オープンソースライセンスとして一般的な「GPU」は、言うなればこのような約束です。

GPUの下に配布されたソフトウェアは、その利用方法に対して制約を課してはならない。その代わりに、再配布する場合、そのソフトウェアは必ずGPUの下に配布しなければならない

この規約により、Git ソースコードの改変や利用の自由が永遠に守られます。その結果として、Git を使った新しいツール(GitHubは最たる例です)やプロジェクトが生まれ続けます。このように、利用自体は無償でも、利用者が増えたり、付随するビジネスや活発になったりする事で、そのシステムが改善・開発される事が多くの利益を生み出すことになり、望んで開発に参加する人々(コミュニティ)が生まれていきます。これがオープンソースプロジェクトの仕組みです。

多くの他のオープンソースのプロジェクトと同様に、Git は今も多くの「メンテナー」と呼ばれる有志によって、改善と開発が続けられているのです。下記のリンクから、GitHub 上の Git の最新のソースコードにアクセスできます。今や、通算で1000人を超えるメンテナーが開発に参加しています。望めば誰でも(あなたも)開発に参加することができます。

バージョン管理ツール「Git」

さて、ここからは、Git が何をしてくれるのか?実際どのように動作するのか?について、掘り下げていきます。

「バージョン管理」とは何か

Git を知るためには、先に「バージョン管理」について、すこし知っておく必要があります。

簡単な例をあげてみます。例えば、あなたの会社のチームで夏にキャンプに行くことにしたとしましょう。いいだしっぺの企画係Aさんが、チームの共有フォルダに、以下のような資料をアップしました。みんなで一緒にプランを立てたいとの事です。

夏のキャンプ情報フォルダ
├キャンプ参加者リスト.xls
└キャンプ場の候補.docs

さて、チームメンバーに、計画する作業を分担したので、みんなが共有フォルダにアクセスして、それぞれのファイル更新を行っていきます。

共有サーバーを使ったバージョン管理の様子

その1週間後、気づけば共有フォルダはこんな状態になっていました。

└夏のキャンプ情報フォルダ
 ├キャンプ参加者リスト_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)

随分見やすくなりました。

この方法がベストだったかどうかは別にして、このような「更新履歴の管理」こそ、いわゆる「バージョン管理」です。更新を整理して記録していくことで、混沌を防ごうという試みです。

上記の例では、1回,2回,3回、・・、誰かが更新するたびに、その都度、その状態のバックアップを残していきます。これらのフォルダの一つ一つは「バージョン(version)」と呼ぶ事ができます。

バージョンをうまいこと管理する

さて、上記の方法でスッキリ感は出たものの、10回、20回と更新があるたびに、どんどんフォルダが増えて、だんだんごちゃごちゃしてきました。本来必要なのはほとんどの場合「最新のフォルダ」だけなので、そのフォルダだけ見える場所に残して、残りを別の場所に隠してしまいましょう。

「昔のデータ」というフォルダを新しく作り、一つ階層を下げて配置してみます。

├夏のキャンプ情報フォルダ
└昔のデータ
 ├夏のキャンプ情報フォルダ(1)
 ├夏のキャンプ情報フォルダ(2)
 ├夏のキャンプ情報フォルダ(3)
 ├ ・・・
 └夏のキャンプ情報フォルダ(23) 


だいぶ良くなりました。

もっときれいにするために、開かれることが少ない「昔のデータ」を完全に別の場所に移して、見えにくくします。

└夏のキャンプ情報フォルダ




     // どこか別の場所・・・
       └昔のデータ

いやー、すごくスッキリしました。

これで、最新を知るためにはどのファイルを見ればいいか、間違えようがないですよね。

もし、どうしても昔のデータが見たくなった時、あれ?昔のデータはどこ?となりますが、別の場所に保存してあるだけで、確実に「残っている」のです(近くに見えないだけ)。もし見たくなったときだけ、そこに行って、探して取ってくればよいのです。

バージョン管理ツールの登場

上記のバージョン管理により、だいぶ混沌は回避できました。

一方で、上記のようなフォルダー操作を手作業で毎回行うのは、そもそも面倒ですし、チームでルールを知らない誰かが、勝手にいろいろ変更してしまって「あれ、あのファイル、どこに置いたの??」「フォルダ構成、勝手に変更したの誰?!」とか、ルールを徹底できるのかどうかも不安があります。

みんなでできるだけシンプルに、そして同じルールで管理方法を統一するための「仕組み」が必要です。

そんなときこそ「バージョン管理ツール」が役に立つときです。みんなで、同じツールを使えば、自動的に同じルールになって、混乱は防げるはずです。

Git = 今一番いけているバージョン管理ツール

さて、いよいよ Gitの登場です。Gitはバージョン管理ツールとして本当にイケていて、いまや大人気です。プログラミングのためにたくさんファイルを更新しなければいけない、いまどきのソフトウェアエンジニアには、Gitはもはや必要不可欠なツールとなっています。

Git を使うと、上記での説明してきたような「バージョンの管理」作業が、すごくシンプルな操作で可能になります。

上記の「キャンプ」の事例はあくまで例ですので、、実際のキャンプの計画で Git を使ってバージョン管理をする事はないと思いますが・・、もっとたくさんのファイルを扱う時、特に複数の人間が一緒にプログラムを開発する「ソフトウェア開発」などには、必要不可欠なツールになっています。

Gitについて、本当に本当に詳しく知りたい人は、あとで、Pro git: gitの内側を読んで見てください。GITを使った事がない人だと、少し(かなり?)難しいかもしれませんが、本当に詳しく、正確な説明があります。

Git はどうやって使うの?

ここからは、実際にGit を使う時はどのような操作を行うのかを、少しだけかいつまんで紹介します。

Git でバージョンの保存

Git で行う操作の80%以上は「ファイルを更新したら、バージョンを保存する」という操作だと思います。そんなとき、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)する」と言います。どこかで聞いたことあるのではないでしょうか?(ラ◯ザップの話じゃないです、念のため)

ターミナルでGit を利用する
MacOSの標準ターミナル。Git の操作に利用できる。

え?ターミナルの利用は、必須なの?

ソフトウェア開発者じゃない人は、ターミナル(文字だけの黒い画面)なんていっさい使わない人も多いと思います。

そういった方にも、使いやすいGitツール(アプリ)があります。例えば「SouceTree」というイケているGitアプリです。結構いけてますので、アプリ上でポチポチやれば、ほとんどのGit操作が可能です。

GitのGUIツール:SourceTree

でも、アプリもいいのですが、ターミナルのコマンド操作に慣れると、アプリでぽちぽちやるより、Git操作は3〜5倍くらい速い(当社比)と思います。

Gitを使って、昔のバージョンと比較して差分を調べる

ついでに、「あれ、このファイル誰が更新したんだろう・・、なんか違うけど、どこが変わったんだろう?」なんてときがよくありますが、Gitでは、簡単に昔のバージョンを見たり、比較したりすることができます。

例えば、以下のコマンドで、すぐに差分を見ることができます。いちいち別の差分比較ツールを開く必要はないです。

git diff <比較元のバージョン名> <比較先のバージョン名>

このコマンド一撃で、簡単に変更内容を調べられます。

「え、さっきどこを変更したの?」なんて会話とはもうさよならです。もちろん、コマンドじゃない方々は、もちろん上記のSourceTreeを使って全て同じ事ができます。

Gitを使って、昔のバージョンに戻す

昔のバージョンを取り戻します。Git でバージョンを保存していくと、このように履歴がたまっていきます。履歴を表示するコマンドは、

// Git で変更履歴のメモを見るコマンド
git log
* a86a1ad 千葉県のキャンプ場を追加。
* ea8c91a キャンプ場候補をたくさん追加。
* a2b0a16 メンバーを追加。
* 2aee3d9 最初のコミット。

先頭のアルファベット記号の羅列が、各バージョンをあらわすIDになっているのですね。ちなみにこのIDは「SHA-1(シャーワン)」と呼ばれる暗号化をつかっていて、自動で生成されれます(くわしくはWikiどうぞ)その後に続く1文はメモのようなもので、Gitではコミットを作るたびにメモを付け加える事になっています。

例えば、最初のコミットの状態を再現したい時は、

git checkout 2aee3d9

と、操作すれば、すぐにその時の記録を Git が一瞬で再現してくれます。Git を使い慣れていない人は、一瞬すぎて何が起きたのか分からないレベルです。コマンド一撃で履歴をさかのぼれるのは、本当に簡単で便利です。

と・・・、ここまで3分くらいでしょうか。以下は、もう話が細かくなってきますので、急いでおられる方は、お仕事に戻っていただいて大丈夫そうです。読んで頂いてありがとうございました。お時間のあるかたは、もうすこし続きます。

Gitについての豆知識

Gitのこれまで

Gitは、2005年末にバージョン管理ツールとしてはじめてリリースされてから、その利便性から順調に広まりを見せます。だいたい2010年前後には、Google社を始め、多くの開発者や、会社に支持されて利用されるようになっていました。ちなみに筆者がGitにはじめて触れたのもこの頃です。

2017年の今日となっては、ソフトウェア開発者が利用するバージョン管理ツールにおいて、Gitのシェアはダントツとなりました。 要は「イケていて、本当にみんな使っているツール」になっているということです。ツールを使う事に抵抗を感じている人も、もはや「長いものには巻かれておくべき」というレベルです。

ちなみに、ひと昔前は「subversion」という別のバージョン管理ツールが最も一般的でしたが、Gitの台頭により、そのシェアはかなり廃れたようです。

参考までに、Google Trendでの検索数の相対的な推移のチャートを貼り付けます。Gitとsubversionとを比較します。どのくらい人気かというと、このくらいうなぎのぼりです、ということです。

2000代年後半のGitの台頭

参考です:

また、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のロゴ

また、プラグラミングで変数名は一般的に小文字で始めるケースが多いです。ですので、固有名詞を小文字のみで綴るのは「ソフトウェア開発に背景がある名称」という可能性が感じられますね。

参考情報

とにかく困ったら、原典(公式の仕様書や、マニュアル)を参考にするのはやはり間違いないです。情報探すの大変だけど・・。

こちらです:

閉じる