gitことはじめ

Gitことはじめ

bleis-tift

February 26, 2011

自己紹介

id:bleis-tift / @bleis

名古屋で働くプログラマGitとかHudson（あ、Jenkins・・・）大好き

自己紹介


名古屋で働くプログラマ

GitとかHudson（あ、Jenkins・・・）大好き

自己紹介


名古屋で働くプログラマGitとかHudson（あ、Jenkins・・・）大好き

今日話すこと

Gitの導入方法Gitの使い方mergeや rebaseの話リポジトリが複数ある場合の話

Gitがなぜそうなっているか

今日話すこと

Gitの導入方法

Gitの使い方mergeや rebaseの話リポジトリが複数ある場合の話


今日話すこと

Gitの導入方法Gitの使い方

mergeや rebaseの話リポジトリが複数ある場合の話


今日話すこと

Gitの導入方法Gitの使い方mergeや rebaseの話

リポジトリが複数ある場合の話


今日話すこと

Gitの導入方法Gitの使い方mergeや rebaseの話リポジトリが複数ある場合の話


Gitって何？

分散バージョン管理システム（DVCS）のひとつ高速かつ高機能だけど概念はシンプル

Gitって何？

分散バージョン管理システム（DVCS）のひとつ

高速かつ高機能だけど概念はシンプル

Gitって何？

分散バージョン管理システム（DVCS）のひとつ高速かつ高機能

だけど概念はシンプル

Gitって何？

分散バージョン管理システム（DVCS）のひとつ高速かつ高機能だけど概念はシンプル

え、Rubyと関係あるの？

RubyはGitと仲良し！

というか GitHubと仲良し？

つまりGitを覚えると世界が広がる！あと単純にGit（というかDVCS）便利


RubyはGitと仲良し！というか GitHubと仲良し？




つまりGitを覚えると世界が広がる！

あと単純にGit（というかDVCS）便利

Gitに対するイメージ

無駄にコマンド数が多い

→ 難しそう無駄に複雑 → 難しそうリビジョン番号ない → 難しそうetc...

「なぜそうなっているか」を知ることでGitを覚えるハードルを下げる！


無駄にコマンド数が多い

→ 難しそう

無駄に複雑 → 難しそうリビジョン番号ない → 難しそうetc...



無駄にコマンド数が多い → 難しそう

無駄に複雑

→ 難しそうリビジョン番号ない → 難しそうetc...



無駄にコマンド数が多い → 難しそう無駄に複雑

→ 難しそう

リビジョン番号ない → 難しそうetc...



無駄にコマンド数が多い → 難しそう無駄に複雑 → 難しそう

リビジョン番号ない

→ 難しそうetc...



無駄にコマンド数が多い → 難しそう無駄に複雑 → 難しそうリビジョン番号ない

→ 難しそう

etc...



無駄にコマンド数が多い → 難しそう無駄に複雑 → 難しそうリビジョン番号ない → 難しそう

etc...



無駄にコマンド数が多い → 難しそう無駄に複雑 → 難しそうリビジョン番号ない → 難しそうetc...


注意

概念の話と言いつつ、インデックスの話はしません。

より知っておいてほしいことを重点的に解説します。

注意

概念の話と言いつつ、インデックスの話はしません。より知っておいてほしいことを

重点的に解説します。

いくつかの観点

動作実装概念


動作

実装概念


動作

実装

概念


動作実装概念

動作という観点

このコマンドを実行したらこうなる、という観点コマンドの絶対数を見て難しいと思うのは、この観点のみで見ているから一番目につく部分ではある


このコマンドを実行したらこうなる、という観点

コマンドの絶対数を見て難しいと思うのは、この観点のみで見ているから一番目につく部分ではある


このコマンドを実行したらこうなる、という観点コマンドの絶対数を見て難しいと思うのは、この観点のみで見ているから

一番目につく部分ではある


このコマンドを実行したらこうなる、という観点コマンドの絶対数を見て難しいと思うのは、この観点のみで見ているから一番目につく部分ではある

概念という観点

なぜそうなっているのか？につながる観点概念と動作を結び付けることができれば理解が早まるGitの概念は実は結構シンプルでわかりやすい

（と、俺は思う）


なぜそうなっているのか？につながる観点

概念と動作を結び付けることができれば理解が早まるGitの概念は実は結構シンプルでわかりやすい



なぜそうなっているのか？につながる観点概念と動作を結び付けることができれば理解が早まる

Gitの概念は実は結構シンプルでわかりやすい



なぜそうなっているのか？につながる観点概念と動作を結び付けることができれば理解が早まるGitの概念は実は結構シンプルでわかりやすい



なぜそうなっているのか？につながる観点概念と動作を結び付けることができれば理解が早まるGitの概念は実は結構シンプルでわかりやすい（と、俺は思う）

実装という観点

どう実現されているか、という観点これを意識できるようになると理解が深まる低レベルコマンドもある程度理解できるようになる


どう実現されているか、という観点

これを意識できるようになると理解が深まる低レベルコマンドもある程度理解できるようになる


どう実現されているか、という観点これを意識できるようになると理解が深まる

低レベルコマンドもある程度理解できるようになる


どう実現されているか、という観点これを意識できるようになると理解が深まる低レベルコマンドもある程度理解できるようになる

どういう順で学べばいい？

とりあえず概念を学び、

それと結びつく動作（コマンド）を学んで、余裕があったら実装も学ぶ


とりあえず概念を学び、それと結びつく動作（コマンド）を学んで、

余裕があったら実装も学ぶ


とりあえず概念を学び、それと結びつく動作（コマンド）を学んで、余裕があったら実装も学ぶ

参考までに

ProGit 概念寄りの動作の説明が中心のサイト。入門Git 概念の説明が中心の本。最初の一冊に

どうぞ。実用Git 実装寄りの概念中心の本。入門Gitで物

足りなくなったら。入門 git 動作の説明が中心の本。上二冊が難し

いならこれで補助。

SVNとの概念上の大きな違い

分散か非分散か？いやいや・・・

SVNではリポジトリ一個に対して作業ディレクトリが複数Gitではリポジトリ一個に対して作業ディレクトリが一個

ひとつのリポジトリに着目すると実はGitの方がシンプル！


分散か非分散か？いやいや・・・SVNではリポジトリ一個に対して作業ディレクトリが複数

Gitではリポジトリ一個に対して作業ディレクトリが一個



分散か非分散か？いやいや・・・SVNではリポジトリ一個に対して作業ディレクトリが複数Gitではリポジトリ一個に対して作業ディレクトリが一個


何が嬉しいの？

SVNでは各作業ディレクトリがリポジトリを介して共有されている→競合怖い・・・

Gitでは独立している→そもそも競合が発生しない

Gitではやりたい放題できる！

何が嬉しいの？

SVNでは各作業ディレクトリがリポジトリを介して共有されている→競合怖い・・・Gitでは独立している→そもそも競合が発生しない

Gitではやりたい放題できる！

Gitのオブジェクト

Gitには 4つのオブジェクトがあるそのすべてが一度作られたらその後変更されない（イミュータブル）オブジェクトを一意に決定するために SHA-1ハッシュを使用


Gitには 4つのオブジェクトがある

そのすべてが一度作られたらその後変更されない（イミュータブル）オブジェクトを一意に決定するために SHA-1ハッシュを使用


Gitには 4つのオブジェクトがあるそのすべてが一度作られたらその後変更されない（イミュータブル）

オブジェクトを一意に決定するために SHA-1ハッシュを使用


Gitには 4つのオブジェクトがあるそのすべてが一度作られたらその後変更されない（イミュータブル）オブジェクトを一意に決定するために SHA-1ハッシュを使用

4つのオブジェクト

commit コミットを表すオブジェクト。親commitのハッシュ、treeオブジェクトのハッシュ、コミット日時、コミットメッセージなどを保持。

tree ディレクトリを表すオブジェクト。保持する子 tree、子 blobオブジェクトのハッシュやファイルモードやファイル名などを保持。

blob ファイルの中身を表すオブジェクト。tag 注釈つきのタグを表すオブジェクト。説明は省略。




blob ファイルの中身を表すオブジェクト。

tag 注釈つきのタグを表すオブジェクト。説明は省略。




blob ファイルの中身を表すオブジェクト。tag 注釈つきのタグを表すオブジェクト。説明は省略。

よく見る図

ひとつひとつの丸が commitオブジェクトちょっと拡大してみましょう

よく見る図

ひとつひとつの丸が commitオブジェクト

ちょっと拡大してみましょう

よく見る図

ひとつひとつの丸が commitオブジェクトちょっと拡大してみましょう

拡大

拡大

三角は treeオブジェクト

拡大

三角は treeオブジェクトcommitはひとつの treeを持つ

拡大

Gitリポジトリの作られ方


git add .

するとtreeオブジェクトや

blobオブジェクトが作られる


git commit

でcommitオブジェクトが

作られる


aを編集してa'に



ハッシュ値は

子要素に影響を

受ける



ハッシュ値は

子要素に影響を

受ける

t以下は弄ってないので

そのままのものが使われる


a'をt配下に移動

ハッシュを使う理由

リビジョン番号ではリポジトリ内での一意性しか確保できない全てのオブジェクトを統一的に扱えるいろいろと高速

メリットのほうが大きいと思うよ！ブランチとかタグ使えばそんなに不便じゃないですし！


リビジョン番号ではリポジトリ内での一意性しか確保できない

全てのオブジェクトを統一的に扱えるいろいろと高速



リビジョン番号ではリポジトリ内での一意性しか確保できない全てのオブジェクトを統一的に扱える

いろいろと高速




メリットのほうが大きいと思うよ！

ブランチとかタグ使えばそんなに不便じゃないですし！

ブランチとタグ

commitオブジェクトのハッシュ値を保持しているだけ。

ブランチとタグの違い

ブランチ動くタグ動かない

ブランチとタグの違い

reset

個人的には一番重要と思っているコマンドブランチの場所を設定しなおす「リセット」という語感に反して、未来に進むこともできるresetが使いこなせるようになれば、Gitに慣れてきたといっていいかも

reset

個人的には一番重要と思っているコマンド

ブランチの場所を設定しなおす「リセット」という語感に反して、未来に進むこともできるresetが使いこなせるようになれば、Gitに慣れてきたといっていいかも

reset

個人的には一番重要と思っているコマンドブランチの場所を設定しなおす

「リセット」という語感に反して、未来に進むこともできるresetが使いこなせるようになれば、Gitに慣れてきたといっていいかも

reset

個人的には一番重要と思っているコマンドブランチの場所を設定しなおす「リセット」という語感に反して、未来に進むこともできる

resetが使いこなせるようになれば、Gitに慣れてきたといっていいかも

reset

個人的には一番重要と思っているコマンドブランチの場所を設定しなおす「リセット」という語感に反して、未来に進むこともできるresetが使いこなせるようになれば、Gitに慣れてきたといっていいかも

reset

git reset --hard hoge

reset

git reset --hard master~2

reset

git reset --hard a

reset

git reset --hard b~4

resetが理解できれば・・・

コミットグラフを頭に思い浮かべやすくなる簡単に好きな時点を取り出せるようになるresetしてしまえば、

そこから新しいブランチを生やすミスったもの（マージ含む）をなかったことになどなど自由自在

俺TUEEE！感checkout派もいるので注意が必要


コミットグラフを頭に思い浮かべやすくなる

簡単に好きな時点を取り出せるようになるresetしてしまえば、





そこから新しいブランチを生やす

ミスったもの（マージ含む）をなかったことになどなど自由自在




そこから新しいブランチを生やすミスったもの（マージ含む）をなかったことに

などなど自由自在





俺TUEEE！感

checkout派もいるので注意が必要

まとめ

ひつとのリポジトリに注目すれば、SVNよりシンプルGitはなんでもイミュータブル動作が高速→概念がシンプルかつ素晴らしい概念を理解できれば使い方は後からついてくる

まとめ

ひつとのリポジトリに注目すれば、SVNよりシンプル

Gitはなんでもイミュータブル動作が高速→概念がシンプルかつ素晴らしい概念を理解できれば使い方は後からついてくる

まとめ

ひつとのリポジトリに注目すれば、SVNよりシンプルGitはなんでもイミュータブル

動作が高速→概念がシンプルかつ素晴らしい概念を理解できれば使い方は後からついてくる

まとめ

ひつとのリポジトリに注目すれば、SVNよりシンプルGitはなんでもイミュータブル動作が高速→概念がシンプルかつ素晴らしい

概念を理解できれば使い方は後からついてくる

まとめ

ひつとのリポジトリに注目すれば、SVNよりシンプルGitはなんでもイミュータブル動作が高速→概念がシンプルかつ素晴らしい概念を理解できれば使い方は後からついてくる

gitことはじめ

Technology