Asial Blog

Recruit! Asialで一緒に働きませんか?

イラストでわかる!git入門の入門

カテゴリ :
バックエンド(インフラ)
タグ :
Tech
git
バージョン管理
こんにちは、アシアルの志田です。
社内でもgitが浸透し、皆バージョン管理といえばgitだよね、という空気になってきました。

ですが、これまでバージョン管理システムを使ったことがない人にオススメしても、
「gitて…まあ…そりゃ…ねえ、いつかやらないといけないけど…」
「ギット?ジット?俺はgiはジと読む派なので、gitは胡散臭いと思う」
「そもそもバージョン管理して何が嬉しいの?なんか難しそうでいやだ」
というような反応ばかりでした。

きっとみんな、gitって難しくて訳のわからんもんだと思っているのでは?と思い、
今回はgit入門の入門、gitってなんだ?というところから、簡単にgitを使う際の流れについてご説明します。
ちょっと不安を覚えるようなイラストがついていますので、頑張って読んでください。

バージョン管理ってなに?



プログラムを書いていて、こんなことありませんか?私はあります…何度も…

・修正前は動いていたのに!
・ああ、数時間前のコードに戻りたい…
・別の人のコードを古いコードで上書きしちゃった!!やばい…
・こっちは本番用、こっちは開発用。さて、どれがどこまで最新だっけ…?

戻りたい!戻れない!大変だ!
こんなとき、バージョン(履歴)を管理しておくのがいいんです。


バージョン管理をするには?



じゃあその、バージョン管理をするには何が必要でしょうか?
そこで、バージョン管理システムが必要になってきます。
少し前まではSubversion(サブバージョン)が主流でした。

ですが、現在はgit(ギット)が主流です。
みんな!便利なgitを使おうよ!

gitはLinuxカーネルの開発にも使われているのです。すごいのです。


Subversionとは



ではgitについて勉強する前に、Subversionについて触れておきましょう。

Subversionとは、集中型バージョン管理システムという分類にあたるシステムです。
(1) サーバ上に「中央リポジトリ」を作り、そこからソースコードを取得する。
(2) ソースコードを編集後、「コミット」すると、内容が中央リポジトリに反映される
(3) ファイルをロックして、他人から編集されないようにもできる



ここで、不明な単語「リポジトリ」について説明します。
リポジトリとは、訳すと「貯蔵庫」という意味になります。
いろいろな情報、例えば、ソースコードそのものや、誰が編集したか?どのように編集したか?といった履歴(バージョン)などが保持されています。

また、「コミット」というのは、ドラクエでいう「セーブ」のことです。
修正した内容や、新規作成したファイルをセーブすることを、バージョン管理システムでは格好良く「コミット」と言います。

このコミットは、機能ごとに行うことが多いです。どういうことかというと…
(1) edit.tpl(編集画面のテンプレート)とedit.php(編集機能)を作った
(2) よし、これでひとまず「編集機能」はOKだな
(3) じゃあ、保存っと ← これがコミットするっていうこと!


Subversionのデメリット



Subversionには、中央集中だからこそ起こるいろいろなデメリットがあります。

代表的なものが、サーバに接続できない環境だと、最新のソースコードが取得できないというものです。
社内でのみ開発するならば問題ないかもしれませんが、サーバに接続できない場所でもコードが書きたいときもありますよね。
サーバに接続できなければ編集もできないのは不便です。
それに、サーバがダウンし、データが全部吹っ飛んでしまったら、泣くしかないです…。

また、他者から編集されるのを防ぐロック機能があるとご説明しましたが、
ロックしたまま放置されると、その間誰もそのファイルを編集できなくて不便です。

gitとは



ここで、gitの出番です!
gitは分散型バージョン管理システムに分類されるシステムです。
その名の通り、リポジトリが分散しています。



自分のPC上、ローカル環境で編集して、自分のリポジトリにコミットしていきます。

複数人での開発



gitを使って複数人で開発するときはこんなかんじです。
(1) 自分のある時点までのコミット内容をpush(送る、押し出すというイメージ)できる
(2) 他人のコードの差分をpull(取得、引っ張ってくるイメージ)できる
(3) pullすると自動的にマージされ、自分+他人の最新コードになる



(3)の、マージというのがイメージしづらいかもしれません。

ポケモンでいうと、サトシがイッシュ地方でポケモンを捕まえたセーブデータ(コミット内容)があり、
タケシがジョウト地方でポケモンを捕まえたセーブデータ(コミット内容)があるという状態を想像してください。

サトシがタケシのセーブをpullすると、マージされ、タケシの捕まえたポケモンのデータまで、
サトシのポケモン図鑑やパソコンに保存されるということです。
(※余計わかりづらいですか?がんばってください!)


・・・でもこれって、サトシとタケシだけのときはいいですけど、
カスミもムサシもコジロウも参加したら、どうなっちゃうでしょうか。
いちいち、自分のコミット内容をpullしてくれとみんなに言うのは面倒ですよね。


gitとSubversionのいいとこどりをしよう!



・普段はローカルで開発、コミットをして(gitのいいところ)
・キリのいいところで中央リポジトリにpush(Subversionのいいところ)
…こうしたら、きっと中央リポジトリを介して、カスミとムサシとコジロウもpushしたりpullしたりできるはず。

gitでそれを実現するには、共有リポジトリを置けばOK!!



これで、共有リポジトリを介して他人のコードをpullできるようになりました。
pullしたりpushしたりすると、自分のリポジトリも共有リポジトリも最新版になります。
なので、例えば共有リポジトリのサーバが爆発しても、誰かが持っている最新版のリポジトリからコピーすればいいんです。

便利ですね!では、どんな流れでgitをはじめて、どういう流れで使っていくのかについて、説明します。


gitプロジェクト作成



まず、gitで管理する空のディレクトリを作ります。
そのディレクトリ上で、git initと入力すると、.gitというディレクトリができて、git管理下になります。



.gitディレクトリとは、個人リポジトリの管理ファイルやpush先の情報など、要するに大事なディレクトリなのです。
.gitディレクトリを消せば、すぐにgit管理をやめることができます。

ディレクトリのトップに.gitがあるだけで、それ以下の入れ子のディレクトリまですべて管理することができます!
Subversionだと、管理下に入れこのディレクトリを作ると、.svnというディレクトリがたくさんできてしまい、ちょっと煩雑です。


ファイルの作成



git管理下のディレクトリにファイルを作成します。
ただし、作っただけではgit管理にはなりません。
git status とコマンドを入力すると、現在の状態がわかります。
Untracked file(gitがトラックしていないファイル=未管理のファイル)と表示が出ます。

  1. git status
  2. # On branch master
  3. #
  4. # Initial commit
  5. #
  6. # Untracked files:
  7. #   (use "git add <file>…" to include in what will be committed)
  8. #
  9. # edit.php
  10. nothing added to commit but untracked files present (use "git add" to track)

「こういうファイルを作ったので、gitが管理してね」と通達する必要があります。


ファイルを管理対象にする



では、作ったファイルをgitに管理させましょう。
git add <ファイル名> とコマンドを打つと、そのファイルが管理対象になります。
git statusすると、先程Untrackedだったファイルが、Changes to be commited(コミットされる変更点=このファイルがコミットできすよー!)という状態になっています。

  1. git add edit.php
  2. git status
  3. # On branch master
  4. #
  5. # Initial commit
  6. #
  7. # Changes to be committed:
  8. #   (use "git rm --cached <file>…" to unstage)
  9. #
  10. # new file:   edit.php
  11. #

このgit add コマンドは新規作成時のほか、編集時にも行う必要があります。
既に管理対象になっているファイルでも、変更したからコミットするのだ!追加してくれ!というイメージです。


commitする



先程addした内容をgit commitでコミットします。



コミットすることで、新しいセーブデータとして保存されます。
ドラクエと違うのは、古いセーブデータも残っていることと、コミットメッセージが残せることです。

ドラクエでいうと、中ボス前にセーブした内容とボス前にセーブしたデータが残っていて、
それぞれに「中ボス前 薬草の数注意」「ボス前 選択肢はいいえを押すこと」といった、コミットに対するメッセージが残せるかんじです。
こうすることで、ボスを倒したあとで、「いややっぱり中ボスからやり直したい」と思ったら、
コミットメッセージを参考に中ボス前のデータまで戻ればいいのです。


pushする



プッシュすることで、これまでのコミット内容を共有リポジトリに送ることができます。



pushした後も開発は続き、コミット内容もたまっていきますね。
そうすると、次回pushするのは、前回pushした内容より新しいコミット達です。
未pushのデータをどんどんpushしていきます。




pullする



みんなの更新内容を取得してくるのがpullです。
自分以外の開発者たちも、皆それぞれpushを繰り返しています。
pullすることで、自分のコードと他人のコードがマージされ、最新の状態にすることができます。



もしも、他人と同じところを編集していたらどうでしょうか?
他人とかち合ってしまうことを「コンフリクト」といいます。
コンフリクトが起きたときは、gitがそう教えてくれるので自分と他人のコードのどちらを生かすか決めます。
(gitにはどちらのコードを優先すべきかわからないので、コンフリクトが起きたことはわかっても、解消まではできません)


おさらい!



・gitは便利なバージョン管理システム
・自分の編集内容をcommitし、共有リポジトリへpushしていく
・共有リポジトリからpullし、他人のコードを取得する

以上が、gitを使うときの基本的な流れになります。
導入してみると、「どうして今までバージョン管理をしてなかったんだろう!?」と思うくらい変わりますよ!
gitに助けられたこと、何回もあります。

みなさんも、gitを使ってみてくださいね。

コメント

  • 通りすがり

    >Subversionだと、管理下に入れこのディレクトリを作ると、.svnというディレクトリがたくさんできてしまい、ちょっと煩雑です。

    ご存知かもしれませんが、version1.7でGitと同じようにトップレベルに一つしかできませんよ。

  • 山田

    すごくわかりやすいです!

    non fast forward(でしたっけ?)の解説もよろしくお願いします!><

  • 志田

    >通りすがり様
    コメントありがとうございます。私の勉強不足です。
    調べてみたところ、version1.7系は2011年の10月リリースだったようですね。
    .svnディレクトリがたくさんできるのがちょっと嫌だなぁと思っていたので、嬉しいですね!

    >山田様
    ありがとうございます。
    今回は自分が初めてgitに触れた時に思った、gitって?バージョン管理って?という、
    初めてならではの疑問をまとめてみました。
    使っていくうちに、どんどんgitでしたいことが増えてくると思うので、
    順を追って解説できたらなと思っています。

  • kaz

    分かりやすかったです。
    公式のドキュメントにもこんな図がほしいですね。

  • 通りすがり

    Subversionのデメリットとして

    > それに、サーバがダウンし、データが全部吹っ飛んでしまったら、泣くしかないです…。

    とありますが、gitも同様ではないですか?

  • 志田

    >kaz様
    ありがとうございます。
    難しい言葉より、図のほうがキャッチーですよね。

    >通りすがり様
    ありがとうございます。
    共有サーバがダウンしても、誰かはローカルに最新のコードを持っているので、
    そこから共有サーバへ復帰できます。
    リポジトリを分散しているメリットが享受できます。

    ただし、共有サーバも飛んで、ローカルのリポジトリも皆飛んだ…
    というような状況では、さすがに復活は難しいかと思います。

  • とおりすがり

    > サーバに接続できなければ編集もできないのは不便です。
    編集出来ませんか?

    > ロックしたまま放置されると、その間誰もそのファイルを編集できなくて不便です。
    ロック破壊で対応できませんか?

  • Saisse

    Subversionが「サーバに接続できない環境だと、最新のソースコードが取得できない」というのはgitも同じはずなのでおかしくないですか?「たぶんコミットできない」なのでは?

  • 志田

    >とおりすがり様
    コメントありがとうございます。
    編集できないというのは、記事を書いた段階では接続できないから編集できないと思っていましたが、
    サーバに接続できないため、最新コードが取得できない
    →新しいファイルでないため編集ができない(古いコードを編集しても意味がない)
    という意味のほうが正しいかな?と思います。
    言葉足らずで申し訳ありません。

    また、ロック破壊については、そうすることで編集が可能にはなるものの、
    誰かがロックしたということは、その必要性があったということだと思います。
    そのため、どういう意図でロックしたかがわかるまでは、破壊を行わないほうがよいかと思います。

    >Saisse様
    コメントありがとうございます。
    gitですと、最新のソースコードを誰かが持っているという前提なので、
    サーバを介して他者のソースコードを得ることはかないませんが、
    直接ソースコードは取得できると思います。

  • beginner

    google app engineを何とか使いたい初心者です。
    google code(gitのようなものですか?)のiap-hello-world
    を私のgaeに移植したいのです。
    google codeにクローンというボタンがあるのですが
    移植先のpathを入力する欄が見つかりません。
    例:c://user//xxxx → 私のpcでのapp.yaml main.pyの保存場所
    gaeでは上記のパスを指定してプロジェクトを呼び出す感じです。
    (gae launcherの場合)
    質問を纏めますと
    1.google codeはgitのようなコードホスティング機能があるのでしょうか?
    2.yesであればローカルpcにクローンのディレクトリを作成し
      それでgaeを動かすことができますでしょうか?
    的外れや誤解に満ちている質問かもしれませんがアドバイス頂けると幸甚です。

  • 志田

    >beginnerさま
    1. コードホスティング機能はあるようです。
    http://ja.wikipedia.org/wiki/OSS%E3%83%9B%E3%82%B9%E3%83%86%E3%82%A3%E3%83%B3%E3%82%B0%E3%82%B5%E3%83%BC%E3%83%93%E3%82%B9%E3%81%AE%E6%AF%94%E8%BC%83

    2. クローンするボタンでなく、その下のコマンドラインを参考にして
      ローカルPCにgit cloneをし、gaeにデプロイすれば良いかと思います。

    本記事はgitの入門記事で、Google App Engineについて触れていないため、回答も要領を得ず申し訳ありません。

  • 志田 様

    早速のご返答ありがとうございます。
    頂いたアドバイスをコツコツ実行してみます。
    志田さんの解説は専門用語に満ち満ちておらず、
    図も適切で、解りやすいです。今後とも
    ご解説を楽しみにwatchしたいと思います。

  • 駆け出しPG

    今まで開発はSubversionでしかやったことがなかったのですが
    今のプロジェクトではGitを使っててかなり手こずっていました。
    でもこのサイトを見てとても理解が深まり、自分の中であれは
    ああいうことだったのかという繋がりを持てました。
    ありがとうございます^^

  • 時平

    参考になりました。

  • もも

    ゲームの例えがとてもわかりやすかったです!ありがとうございました。

  • Subversionは悪くない

    Subversionのデメリットの節はちょっと違うんじゃないかと思います。
    サーバと切り離されると手も足も出ないのはCVSです。
    checkoutやupdateで最新を持ってきたらサーバと切断していても好きなだけ編集できます。差分も見れます。
    他人のプロジェクトの場合、いったん最新を持ってこないといけないはgitだって同じです。
    違うのはローカルでも履歴管理してるってことです。それだけです。
    各自の編集履歴の記録と中央リポジトリへの反映が切り離されてるってことです。
    あと中央リポジトリが吹っ飛んでもSubversionだって各自最新持ってますから復旧は出来ます。
    出来なかったら大変じゃないですか。
    あと、ふつうはロック機能なんか使いません。
    あれはコピー・マージ方式に慣れてない人(昔のVSSは共有フォルダをロックして編集する方式)向けです。

  • xyz

    おかげさまで、コミットとかプッシュとかがどういう動作なのかわかりました!(セーブデータはわかりやすかったです)

  • 通りすがり2

    ロックがSVNのデメリットのように理解するのは、大きな誤りです。
    当初SVNもロックは持たない思想でしたが、強い要望によって追加された機能ですからね。
    GITが最高のシステムなどとは、夢にも思わないほうがいいです。

  • タナミ

    単語がわからず困っていましたが、素人の私でもとても良くわかりました。プログラマーと話ができます。ありがとうございました。

  • zzz

    図にとてもセンスがあり引き寄せられました
    内容が初心者の私にもとても分かりやすくて、
    まずザックリ概要を理解したい入門者向けの記事として
    素晴らしかったです!
    楽しく勉強できました、ありがとうございました ^^

  • 通りすがったー

    素朴な疑問ですが、他のメンバーがコード改変する事で自分のコーディングに矛盾点て出ないもんなのでしょうか?ギットに限らずですが。事前に打ち合わせして作業進めるもんですか?

  • 通りすがったー

    素朴な疑問ですが、他のメンバーがコード改変する事で自分のコーディングに矛盾点て出ないもんなのでしょうか?ギットに限らずですが。事前に打ち合わせして作業進めるもんですか?

コメントフォーム



captcha_key

アシアルの会社情報

アシアル株式会社はPHP、HTML5、JavaScriptに特化したWebエンジニアリング企業です。ユーザーエクスペリエンス設計から大規模システム構築まで、アシアルメンバーが各々の専門性を通じてインターネットの進化に貢献します。

会社情報詳細

最近の記事