43
40

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 5 years have passed since last update.

これだけは押さえておきたいGitの仕組み

Last updated at Posted at 2016-10-02

こんな人が対象

  • 職場のソース管理がGitになったが今だに操作方法がよく分からず、
    毎回詳しい人に聞かないとソースを上げられない
  • 何だかSourceTreeにすぐ怒られる
  • 何だかSourceTreeの線がすぐぐちゃぐちゃになる
  • ネットで調べても丸を線でつないだ絵とかコマンドの説明ばかりで
    どうすればいいのか分からない

Gitは基本的な仕組みを押さえれば、実はそんなに難しくない(かも)

  • 以下の説明は簡単のために細部を思い切ってはしょっているので、
    正確でない記述も含まれています

Gitが管理しているのはこの3つだけ

  1. コミット
  2. タグ
  3. ブランチ

コミット

  • SourceTreeの画面に出ている◯の1つ1つがコミット
    commit

  • コミットは以下の情報を1つの圧縮ファイルにまとめたようなもの

    • 変更されたファイルの中身
    • 作成者や作成日
    • コミットメッセージ
  • 別のコミットを親として持つのが特徴

  • 空のリポジトリに最初にソースをインポートしたときだけ、親のないコミット(1)ができる

img1

  • その後ソースを変更してコミットすると、(1)を親にした新しいコミット(2)ができる

img2

  • これを繰り返すと、◯を線でつないだ図形が伸びていくような感じになる(コミットグラフ)

img3

  • グラフ上の任意のコミットを選んで、その時点のソース全体のスナップショットを取り出すことができる(チェックアウト)

タグ

  • コミットにはそれぞれコミットIDというのが振られている

    • 1ad1cb6e68271f275c331d7c8571449f3c0addb4 <- こんなやつ
  • Gitのコマンドでコミットを操作するときにこのIDを指定する

  • コミットIDは覚えられないし、操作の都度IDを調べるのもしんどい

  • そこで意味のあるコミットにはタグで別名をつけて、
    コミットIDの代わりにタグ名でも指定ができるようになっている

img11

  • リリースした時にバージョン番号をタグ付けしておいて、
    あとで「このリリースではどうなってたっけ?」なんて調べたりするのに使う

ブランチ

基本

  • ブランチの実体はタグと同じで、コミットに別名を付けている

  • タグとの違いは、位置が移動するということ

  • 空のリポジトリに最初にソースをインポートすると、

    • masterというブランチが自動的に作られる
    • masterは最初のコミット(1)を指している

img4

  • その後ソースを変更してコミットすると、
    • 新しいコミット(2)ができる
    • masterの位置が移動して、(2)を指すようになる

img5

  • これを繰り返すと、コミットグラフは伸びていき、masterは常にその先端を指している感じになる

img6

分岐

  • 新しくブランチhogeを作ると、
    • hogeは現在のコミット(4)(masterと同じ位置)を指す
    • ここからはブランチをチェックアウトで切替えて、
      hogeで作業したりmasterに戻ったりすることができる

img7

  • hogeで作業して変更をコミットすると、
    • (4)を親にした新しいコミット(5)ができる
    • hogeは(5)に移動する
    • masterの位置は(4)のまま

img8

  • ブランチを切替えてmasterに戻ってくると、

    • ソースは変更する前の状態(4)に戻る
  • masterで作業して変更をコミットすると、

    • (4)を親にした新しいコミット(6)ができる
    • masterは(6)に移動する
    • ->コミットグラフが枝分かれする

img9

  • ブランチを再度hogeに切替えた場合は、ソースは(5)の状態になる

  • hogeはmasterに影響を受けずに、masterはhogeに影響を受けずに、
    それぞれ開発を進めることができる

マージ

  • ブランチでの開発が終了したら、通常は分岐元にその変更を反映する(マージ)

  • hogeをmasterにマージした場合、

    • hoge(5)とmaster(6)の親をそれぞれ辿っていき、共通の親(4)を見つける
    • (5)と(6)の2つを親に持つ新しいコミット(7)が作られる
    • (7)は(4)->(5)の変更と(4)->(6)の変更を両方含んだものになっている
    • masterが(7)に移動する

img10

実物を見て確認

stuff1
stuff2

  1. .gitフォルダ
    • ローカルリポジトリはこの中にある
  2. 作業コピー(ワーキングツリー)
    • ローカルリポジトリからコピーされたソースが展開されている
    • ブランチをチェックアウトすると、そのブランチのソースにまるごと置き換わる
  3. .git/objectsフォルダ
    • コミットの実体(変更されたファイルを圧縮したようなもの)が入っている
  4. .git/refsフォルダ
    • タグとブランチのそれぞれについてファイルが作られている
    • ファイルの中には現在指しているコミットのIDが書かれている
  5. .git/index
    • インデックスとかステージング領域とか呼ばれている
    • コミット対象のファイルをステージしたときに、ファイル名などがここに書き込まれる

無理やり3行にまとめてみる

  • Gitにソースを入れると、◯ができて、他の◯と線でつながる
  • Gitは◯を線でつなげて履歴を管理している
  • 線は枝分かれさせたり、まとめたりできる

こちらもどうぞ

43
40
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
43
40

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?