Git 研修 Basic【MIXI 24新卒技術研修】

©MIXI ©MIXI MIXI 24新卒技術研修 Git研修 Basic

22 ©MIXI 講師紹介久⽥将成ひさだまさなり 2022年度新卒⼊社ライブエクスペリエンス事業本部ファンコミュニケーション部
Fansta開発グループ業務: Ruby on Rails 、Next.js 、Flutter など趣味: Rust など好きなGitコマンド: git rebase 得意なこと: コンフリクトを起こすこと、夜更かし苦⼿なこと: コンフリクトの解消、早起き

33 ©MIXI 講師紹介登内雅⼈とのうちまさと 2020 年度新卒⼊社 •
業務：開発本部たんぽぽ室たんぽぽグループ • ML系の研究開発やバックエンドを主に担当 • Python、Go、Flutter、Ruby • 趣味：格闘技、将棋、ポーカーとかにハマってる • 好きなGitコマンド：git push -f github pages: https://github.com/tonouchi510

4 ©MIXI タイムテーブル（予定） 10:30 - 12:00 Git研修 Basic （基礎 /
内部構造） 12:00 - 13:00 お昼休憩 13:00 - 16:30 Git Challenge 16:40 - 18:30 Git研修 Advanced（チーム開発について）

5 ©MIXI ⽬次 1. Gitとは 2. Gitの基本的な使い⽅ 3. ブランチの使⽤ 4.
歴史の改変 5. その他便利機能基礎編 1. Gitオブジェクト 2. コミットの仕組み 3. resetの仕組み内部構造編

©MIXI Gitとは

7 ©MIXI Gitとは Gitはバージョン管理システム（VCS）

8 ©MIXI Gitとは例えばファイル名を使ったバージョン管理書類_最新.pdf 書類_修正版.pdf 書類_最終.pdf 書類_提出⽤.pdf 書類.pdf 書類(1).pdf
あるいは書類_0402_2.pdf 書類_0403.pdf 書類_0403_2.pdf 書類_0403_3.pdf 書類_0401.pdf 書類_0402.pdf

9 ©MIXI Gitとは例えばファイル名を使ったバージョン管理書類_最新.pdf 書類_修正版.pdf 書類_最終.pdf 書類_提出⽤.pdf 書類.pdf 書類(1).pdf
最新の版は？ひとつ前の版は？複数⼈で扱うにはちょっと苦しい

10 ©MIXI Gitとは Gitを使⽤したバージョン管理書類.pdf 04/02 15:00 書類.pdf 04/03 10:00
書類.pdf 04/01 12:00 書類.pdf 04/02 13:00 最新版初稿差分が出せたり好きな版に戻れたりこの他にもチーム開発に便利な機能がたくさん！

11 ©MIXI Gitとは現代のソフトウェア開発におけるデファクトスタンダードが Git 今やバージョン管理に留まらず⾃動化されたテストやビルド：CI ⾃動化されたデプロイ：CD の基盤としても使われている
Continuous Integration Continuous Delivery

©MIXI Gitの基本的な使い⽅

13 ©MIXI Gitの基本的な使い⽅はじめにリポジトリ（repository）を作る Gitでバージョン管理したいディレクトリに移動してから $ git init 以下のように表⽰されたら成功！ Initialized
empty Git repository in ディレクトリパスこのディレクトリ内がGitが管理する範囲になり、これをリポジトリと呼ぶちなみに既存のリポジトリで作業を始める場合はクローン（clone）する $ git clone リポジトリURL 参照: git-init Documentation git-clone Documentation もっとちなみにリポジトリ直下には .git というディレクトリが作られる詳しくは内部構造編で！

14 ©MIXI Gitの基本的な使い⽅ Gitでは「コミット（commit）」という単位で変更を保存する書類.pdf 04/01 12:00 コミット書類.pdf 04/02
13:00 コミット書類.pdf 04/02 15:00 コミット変更をコミット対象にする（ステージング）ステージングした変更でコミットする $ git add ファイル名 $ git commit 書類.pdf 04/03 10:00 コミット全部なら -A オプション参照: git-add Documentation git-commit Documentation

15 ©MIXI Gitの基本的な使い⽅変更をコミットするまでの段階はこんな感じワーキングディレクトリファイルを編集した状態ステージングエリアステージングされた状態コミットコミットされた状態
$ git add $ git commit 各ファイルがどの段階にあるかを確認するには $ git status 参照: git-status Documentation

16 ©MIXI Gitの基本的な使い⽅コミットログを⾒てみる $ git log --oneline --graph bca877d40
最初のコミット 6aa4aa7ae 2番⽬のコミット 4e62a7326 3番⽬のコミットコミットID コミットメッセージコミットIDはコミットを⼀意に識別するID コマンド内でコミットを指定する場合に使ったりする例えばコミットの詳細を⾒るには $ git show コミットID 他にもコミット間の差分を⾒るには $ git diff コミットID1 コミットID2 ちなみに最後に ^ をつけるとその１つ前のコミット、 HEAD を指定すると今いるコミットを⽰す [HEAD] もっとちなみに参照: git-log Documentation git-show Documentation git-diﬀ Documentation コミットID部分は正確には参照（refs）も可後述するブランチとかタグとか

17 ©MIXI Gitの基本的な使い⽅コミットをリモートリポジトリにプッシュ（push: アップロード）したり、コミットをリモートリポジトリからプル（pull: ダウンロード）することで変更を共有する Push Pull Pull
Push コミットをプッシュするコミットをプルする $ git push $ git pull 参照: git-push Documentation git-pull Documentation

18 ©MIXI Gitの基本的な使い⽅別のコミットに戻りたいときはチェックアウト（checkout） $ git checkout コミットID $ git
switch コミットID --detach もしくは EXPERIMENTAL ファイルを別のコミット時点に戻したいときもチェックアウト $ git checkout コミットID ファイル名 $ git restore ファイル名 -s コミットID EXPERIMENTAL もしくは参照: git-checkout Documentation git-switch Documentation Git - git-restore Documentation

19 ©MIXI Gitの基本的な使い⽅コミットを打ち消したいときはリバート（revert）指定したコミットと逆のコミットを追加する 1 Hello, World! 2 1
Hello, World! 2 Hello, MIXI! 3 MIXIを追加 1 Hello, World! 2 Hello, MIXI! 3 revert Revert <MIXIを追加> コミットをリバートする $ git revert コミットID 参照: git-revert Documentation

20 ©MIXI Gitの基本的な使い⽅タグ（tag）機能を使うと特定のコミットに⽬印を付けられる $ git tag タグ名コミットID version1.2
version1.1 version1.0 リリースしたらバージョン名のタグを作る運⽤も多い印象タグ名はコミットIDと同じように使える $ git switch タグ名 --detach $ git show タグ名タグのついたコミットに移動するならタグのついたコミットの詳細を⾒るなら参照: git-tag Documentation

©MIXI ブランチの使⽤

22 ©MIXI ブランチの使⽤複数の開発を並⾏して⾏うためにブランチ（branch）という機能がある複数のブランチで開発を進めて、それらをマージ（merge）することで成果物を作る機能B 機能A ブランチマージ

23 ©MIXI main develop ブランチの使⽤まずは develop という名前でブランチを作ってみる $ git
branch develop bca877d40 Commit 1 最初はmainやmasterという名前のブランチが作られているブランチの⼀覧を確認してみる $ git branch * main develop 参照: git-branch Documentation

24 ©MIXI develop ブランチの使⽤まずは develop という名前でブランチを作ってみる $ git branch
develop bca877d40 Commit 1 main 最初はmainやmasterという名前のブランチが作られているブランチの⼀覧を確認してみる $ git branch * main develop develop ブランチに移動してみる $ git checkout develop または $ git switch develop develop 今いるブランチを確認してみる $ git branch main * develop 参照: git-branch Documentation

25 ©MIXI ブランチの使⽤コミットを追加してみる $ git commit 2a673e714 Commit 1
main f20100b9e Commit on develop develop

26 ©MIXI ブランチの使⽤コミットを追加してみる $ git commit 2a673e714 Commit 1
main f20100b9e Commit on develop develop 2f8ff17f6 Commit on main main 仮にmainにコミットが増えるとこうなる

27 ©MIXI ブランチの使⽤マージ先ブランチに移動する $ git checkout main 2a673e714 Commit
1 f20100b9e Commit on develop develop develop main 参照: git-merge Documentation 2f8ff17f6 Commit on main

28 ©MIXI ブランチの使⽤マージ先ブランチに移動する $ git checkout main 2a673e714 Commit
1 f20100b9e Commit on develop develop マージする $ git merge develop develop 95e9ea33b Merge branch ‘develop’ main マージコミット参照: git-merge Documentation

29 ©MIXI ブランチの使⽤マージの際、両ブランチの変更内容は⾃動でいい感じに混ぜられる 1 Hello, World! 2 and 3
Hello, MIXI! 4 1 Hi, World! 2 and 3 Hello, MIXI! 4 1 Hello, World! 2 and 3 Yeah, MIXI! 4 1 Hi, World! 2 and 3 Yeah, MIXI! 4

30 ©MIXI ブランチの使⽤じゃあ、これは？ 1 Hello, World! 2 1 Hello,
e-Mercury! 2 1 Hello, MIXI! 2

31 ©MIXI ブランチの使⽤マージしてみると怒られる Auto-merging hello.txt CONFLICT (content): Merge conflict
in hello.txt Automatic merge failed; fix conflicts and then commit the result. （以下意訳） hello.txt のマージでコンフリクトが起きたよ。⾃動マージが失敗しちゃったからコンフリクトを直してからコミットしてね。このように⾃動マージに失敗した状況をコンフリクト（conﬂict: 競合）と呼ぶコンフリクトが発⽣した場合は⼿動マージが必要

32 ©MIXI ブランチの使⽤直してみる問題のファイルを開くとこうなっている 1 <<<<<<< HEAD 2 Hello,
e-Mercury! 3 4 ======= 5 Hello, MIXI! 6 >>>>>>> mixi コンフリクトーマーカー HEAD（今いるところ）の変更内容ブランチ mixi の変更内容これをあるべき姿に直してコミットすればよい

33 ©MIXI ブランチの使⽤例えば Hello, MIXI! を残すならこうする 1 Hello, MIXI!
2 もしくは両⽅残すならこうする 1 Hello, e-Mercury! 2 Hello, MIXI! 3 忘れずに add してコミットすれば⼿動マージ完了！ $ git add hello.txt $ git commit ちなみに $ git status でコンフリクトしているファイルの⼀覧が確認できるたくさんある場合は直したファイルから add していくのがおすすめ

34 ©MIXI ブランチの使⽤マージは⾏ごとに処理されるのでこの場合もコンフリクトが起きる 1 Hello, World! 2 1 Hi,
World! 2 1 Hello, MIXI! 2 1 <<<<<<< HEAD 2 Hi, World! 3 4 ======= 5 Hello, MIXI! 6 >>>>>>> mixi 1 Hi, MIXI! 2

35 ©MIXI ブランチの使⽤コンフリクトはできるだけ避けたくはあるものの、起こるときは起こる⼿動マージは間違いやすいので注意して作業しようそれぞれのブランチで加えられた変更の意図を理解するのが近道 merge-base コマンドで分岐元が調べられる $ git
merge-base main develop 分岐元からの差分を⾒たり…… 含まれるコミットメッセージやPull requestを読んだり…… ⼤変だけど間違うともっと⼤変なので頑張ろう参照: git-merge-base Documentation

36 ©MIXI ブランチの使⽤ところで fast-forward というマージがあるこの状態で develop を main
にマージすると…… 2a673e714 Commit 1 f20100b9e Commit on develop develop main develop $ git merge develop

37 ©MIXI ブランチの使⽤ところで fast-forward というマージがあるこの状態で develop を main
にマージすると…… こうなる 2a673e714 Commit 1 f20100b9e Commit on develop develop main develop $ git merge develop main

38 ©MIXI main ブランチの使⽤マージ対象ブランチの⽚⽅のみに変更がある場合、マージコミットは必須でないマージ先ブランチをマージ元ブランチの位置に移動することで通常のマージと同じ結果を得られるこれを fast-forward（早送り）と呼ぶ
2a673e714 Commit 1 f20100b9e Commit on develop develop main develop

39 ©MIXI ブランチの使⽤デフォルトだと可能な限りfast-forwardするようになっている fast-forward しないようにするなら逆にfast-forwardを強制するなら fast-forwardマージはコミットログがシンプルになる⼀⽅、マージした形跡が残らない作りたいコミットログやチームの⽂化によって使い分けられるようになろう $
git merge develop --no-ff $ git merge develop --ff-only main 2a673e714 Commit 1 f20100b9e Commit on develop develop main develop

©MIXI 歴史の改変

41 ©MIXI 歴史の改変ここまではコミットログにコミットを追加していく操作を紹介してきたが、コミットログを改変することも可能必然的に破壊的な操作も多くなるので注意深く使⽤すること

42 ©MIXI 歴史を改変してみる前にコミットログの構造を少し説明したい歴史の改変コミットは１つ前がどのコミットかを知っている（参照を持っている） bca877d40 最初のコミット 6aa4aa7ae 2番⽬のコミット 4e62a7326
3番⽬のコミット [HEAD] 新古つまり…… 参照参照新しいコミットから古いコミットは辿れる古いコミットから新しいコミットは辿れないコミットの削除とはそのコミットがどこからも辿れなくなることを意味するちなみに加えて今いるところ（HEAD）やブランチの先端のコミットを別途保存することでコミットログが描画できる

43 ©MIXI 歴史の改変最近のコミットをなかったことにするならリセット（reset） $ git reset コミットID よく使うオプションは以下 HEAD
HEAD 削除 --soft --mixed（デフォルト） --hard ：変更はステージングされた状態で残す：変更はステージングされていない状態で残す：変更は破棄する変更をステージングしたけどやっぱりやめたいときもresetを使う $ git reset . 参照: git-reset Documentation

44 ©MIXI 歴史の改変操作を間違えたら reflog で復旧できる……かも $ git reflog aec805a
(HEAD -> main) HEAD@{0}: reset: moving to head^^ 561f0de HEAD@{1}: commit: Important commit 2 11dd662 HEAD@{2}: commit: Important commit aec805a (HEAD -> main) HEAD@{3}: commit: Add new file. 74c7044 HEAD@{4}: commit (initial): First commit 操作の結果移動した先のコミット操作の内容以下はresetで最新のコミットを２つ消し⾶ばした時のreflog この場合は reset する前にいたコミット 561f0de に再び reset することでもとに戻せる $ git reset 561f0de 参照: git-reflog Documentation

45 ©MIXI 歴史の改変ブランチ上で作業していて分岐元のブランチが進んでしまった時はリベース（rebase）で追従するのが便利歴史を改変するのが怖ければ代わりにマージしても同じ結果が得られるがリベースの⽅がコミットログはシンプルになる HEAD main $
git rebase --continue もしコンフリクトしたら解決後に continue で続⾏できる HEAD 参照: git-rebase Documentation $ git rebase main

46 ©MIXI 歴史の改変もっと⼤胆に歴史を変えるならリベースのインタラクティブモード指定したコミットの次のコミット以降を対象にいろいろできる $ git rebase -i コミットID
HEAD このコミットを指定するとこの範囲が対象になる

47 ©MIXI 歴史の改変よく使うのはコミットをまとめる squash 前のコミットに吸収される w ork1 w ork2
w ork3 pick 56da94f work1 pick 4a1d066 work2 pick f908cb9 work3 pick 56da94f work1 squash 4a1d066 work2 squash f908cb9 work3 w ork1, 2, 3

48 ©MIXI 歴史の改変他にもいろいろできるので⼀部抜粋して紹介 reword edit ：コミットをそのまま残す：コミットメッセージを書き直す：コミットを編集する pick（デフォルト）
fixup exec squash ：コミットを前のコミットとまとめる（前述）：squashっぽいけどメッセージはそのコミットのものを採⽤する：任意のコマンドを実⾏する⾏を並べ替えるとコミットが並べ替えられたり…… ⾏を削除するとコミットが削除できたり…… 開いたエディタにできることが書いてあるので⼀度読んでみるとよい

49 ©MIXI 歴史の改変ところでリモートリポジトリにプッシュする際、通常はコミットの追加のみが許される

50 ©MIXI 歴史の改変過去のコミットを変更してプッシュしようとすると弾かれる削除

51 ©MIXI 歴史の改変これをプッシュするには強制プッシュが必要 $ git push --force (-f) 削除
削除もし他の⼈がコミットをプッシュしていたらそのコミットは消えてしまう

52 ©MIXI 歴史の改変これを他のメンバーがプルするとこちらもまた弾かれるこうなると結構めんどくさい⾃分の変更を退避して…… 強制プルして…… コミットし直して…… みたいになる基本的に⼈と共有しているブランチへの強制プッシュは避けたほうが無難削除削除

53 ©MIXI 歴史の改変多くの⼈で共有している⼤事なブランチはリモートリポジトリ側で強制プッシュを禁⽌する設定をしておくべき（ブランチ保護）とはいえ⾃分のブランチへの操作を誤ってひとりで悲しい思いをするのも切ないので⽐較的安全な強制プッシュを覚えておこう --force-with-lease: リモートリポジトリ側のコミットログに知らない変更があればプッシュを中⽌する $
git push --force-with-lease --force-if-includes --force-if-includes: リモートリポジトリ側の最新のコミットに触った形跡がなければプッシュを中⽌する超ざっくり解説強制プッシュはいつもこれを使うくらいのつもりで問題ない正確な説明は公式ドキュメントへ！ https://git-scm.com/docs/git-push

©MIXI その他便利機能

55 ©MIXI commit コマンドの --amend オプション直前のコミットを上書きしてコミットする他にも便利な機能があるので紹介しておく（その１）その他便利機能 submodule
参照: Git - Submodules リポジトリ内に別のリポジトリを内包できる cherry-pick 参照: git-cherry-pick Documentation 指定したコミットと同じ内容のコミットを今いるブランチに追加する stash 参照: git-stash Documentation コミットしていない変更を⼀時的に退避できる -（ハイフン）１つ前にいたブランチを⽰す（例: $ git switch - で１つ前のブランチに戻る）

56 ©MIXI hooks 参照: Git Hooks 指定した操作の前や後に任意の処理を実⾏したりできる他にも便利な機能があるので紹介しておく（その２）その他便利機能

57 ©MIXI add -A: すべての変更をステージする -p: 変更を部分的にステージする commit -a: すべての変更をステージしてからコミットする
-m ’メッセージ’: コミットメッセージをオプションで渡せる（エディタが開かない） -n: pre-commit, commit-msg hooks を無視する log --graph: コマンドライン上でグラフィカルに表⽰する --oneline: １コミット１⾏で表⽰する --all: 今いるブランチ以外のコミットも表⽰するよく使うかもしれない細かいオプションとか（その１）その他便利機能

58 ©MIXI checkout -b ブランチ名: ブランチを作ってそこに移動する switch -c ブランチ名:ブランチを作ってそこに移動する merge
--abort: コンフリクトでマージが中断したときに、マージを中⽌するよく使うかもしれない細かいオプションとか（その２）その他便利機能

©MIXI ©MIXI MIXI 24新卒技術研修 Git研修内部構造

60 ©MIXI Git の内部構造を学ぶ意義 Git ⾃体は内部を知らなくとも⼗分使える優秀なツール • Git のサブコマンドが実際どういった挙動をしているのか •
内部構造がどうなっているかこれらを知らなくとも⼗分使えるため、学んだことがある⼈は少ないかもしれない⼀⽅で、仕組みや内部構造を知ることで以下のような利点がある • 毎回調べながら Git を使うという状況を脱せる • Git を使っていて何らかの問題が起きたときに⾃⼒で解決できる

61 ©MIXI Git の内部構造を学ぶ意義 Git を使っていてこんな経験はないか？ • ブランチをマージ前に間違えて消してしまった！ • コミットを誤って消してしまった！
• コミット前（ステージングエリア）のファイルを消してしまった！内部構造を学ぶことでこれらの問題に、⾃⼒で対処できるようになる。

62 ©MIXI Gitについての誤解 Git の内部構造を知る前だと、（僕も含め）各コマンドに対する印象は例えば以下のようなイメージになるかもしれない。 1. commit とは、 ◦
add の操作を確定するもの？ ◦ 親 commit との差分を保存しているもの？ 2. branch とは、 ◦ 分岐した時点以降のコミットのこと？ 3. reset とは、 ◦ add や commit を無かったことにできるコマンド？ ◦ ファイルの変更を無かったことにできるコマンド？

63 ©MIXI Gitについての誤解 => 全て間違い（厳密には） Git について、多くの⼈が誤解しているであろうポイントを紹介しました。これらの実態が分かれば、誤った操作をしてしまった時に焦る必要がないことが分かるようになると思います。ここからは、Git
がどのようにしてバージョン管理を実現しているかを理解するために、内部構造を紐解いていきます。具体的には、.gitディレクトリの中⾝について取り扱っていきます。 git init した時にできるあれ

64 ©MIXI .git ディレクトリ⼿元の適当な .gitディレクトリの中を眺めてみてくださいもしなければ以下のリポジトリをクローンして使ってください => https://github.com/mixigroup/sample_repository
$ git clone [email protected]:mixigroup/sample_repository.git $ ls .git/objects info pack # packfileを解凍する $ mkdir temp && cd temp $ git init $ git unpack-objects < ../sample_repository/.git/objects/pack/pack-147de79371a5b4f88389ef990099a091983da7f8.pack $ find .git/objects -not -name 'pack' -a -not -name 'info' -type d -mindepth 1 | xargs -I {} mv {} ../sample_repository/.git/objects/ $ cd ../sample_repository 最初はPackfileに圧縮されてしまっている Packfileについて興味ある⽅はこちら

65 ©MIXI .git ディレクトリとりあえず ls して中⾝を⾒てみるまずは objects ディレクトリを⾒ていく
中にさらにサブディレクトリがあり、その中にファイルがある => Gitオブジェクト $ ls .git COMMIT_EDITMSG HEAD conﬁg description hooks index info logs objects packed-refs refs $ ls .git/objects 2c 2e 2f 3e 3f 5e 63 77 7c 9c 9d a3 aa b4 b6 bc bd c6 f7 f9 info pack $ ls .git/objects/2c/ 14dﬀ3277ae4751173f3c26802620de960aaa1

©MIXI Git オブジェクト

67 ©MIXI Git オブジェクト Git はバージョン管理に必要なデータを主に「オブジェクト」と呼ばれる概念で表現し、 `.git/objects`ディレクトリで管理しています。オブジェクトは以下の4種類 • blob
オブジェクト ◦ ファイルの情報が⼊っているオブジェクト（バックアップ） • tree オブジェクト ◦ ディレクトリ情報が⼊っているオブジェクト • commit オブジェクト ◦ コミットの情報が⼊っているオブジェクト • tag オブジェクト ◦ annotated tag の情報が⼊っているオブジェクト ◦ 重要度が低いので省略 => 興味がある⼈はこちらを参照してください

68 ©MIXI Git オブジェクト Git はこれらのオブジェクトを Key-Value Store として管理している。 1.
それぞれのオブジェクト（Value）を作成 2. オブジェクトの中⾝を SHA-1 ハッシュ化した値をKeyとする 3. オブジェクトを zlib 圧縮した上で、.git/objects/以下に Key をファイル名として保存 ◦ 検索効率性のために、Key の先頭2⽂字でサブディレクトリを切る $ ls .git/objects 2c 2e 2f 3e 3f 5e 63 77 7c 9c 9d a3 aa b4 b6 bc bd c6 f7 f9 info pack $ ls .git/objects/2c/ 14dﬀ3277ae4751173f3c26802620de960aaa1 ※SHA-1：https://ja.wikipedia.org/wiki/SHA-1 ※Zlib：https://ja.wikipedia.org/wiki/Zlib

69 ©MIXI オブジェクトファイルの基本構成 • オブジェクトの種類：blob or tree or commit or
tag • オブジェクトのサイズ：数値（単位はbyte） • オブジェクトのコンテンツ：オブジェクトの種類によってさまざま最初にオブジェクトの種類やサイズなどのメタデータが記録され、そのあとにコンテンツが続きます。これからオブジェクトの種類ごとに、順番に中⾝を⾒ていきます。

70 ©MIXI commit オブジェクト commit オブジェクトは、コミットの情報を記録するオブジェクトです。実際に、Key=bdcc6040408bacfb69727c0f2637bbcec1dbc487 の commit オブジェク
トの中⾝を⾒てみます。そのままだとファイルは zlib 圧縮されているので意味のない⽂字列が表⽰されます。 $ cat .git/objects/bd/cc6040408bacfb69727c0f2637bbcec1dbc487 x��M �0F]�� 2��_ADO"�db �)%�o7^��=>n�<umȞ�&��G�5c�P=bvB� �`] �\r�A�i��kO�J2R�Z,�P�#�s�F,�J{ۦ 7��]}L��4�/��F��d�u��c��l�(E��#�4�� X�I�%

71 ©MIXI commit オブジェクト Git オブジェクトの内容を⾒たい場合は、cat-file というサブコマンドを使⽤します。 # tオプションはオブジェクトの種類 $
git cat-file -t c6c63202bf8abde33a80dfc0a230ad1e9791a33b commit # sオプションはオブジェクトのサイズ $ git cat-file -s c6c63202bf8abde33a80dfc0a230ad1e9791a33b 234 # pオプションはオブジェクトの中⾝ $ git cat-file -p bdcc6040408bacfb69727c0f2637bbcec1dbc487 tree f9ccb461cbfb1837f611b5e31a070945b8cdb867 parent 63c833da2ed9fd43d3f000f35d2ee141ba42e411 author tonouchi510 <[email protected]> 1670215632 +0900 committer tonouchi510 <[email protected]> 1670215632 +0900 Add chapter_2.txt

72 ©MIXI commit オブジェクト commit オブジェクトに含まれている情報は以下の通り。 • リポジトリのルートディレクトリの tree オブジェクトのハッシュ値（Key）
• 親 commit のハッシュ値 • committer と author のタイムスタンプ‧名前‧メールアドレス • コミットメッセージ $ git cat-ﬁle -p bdcc6040408bacfb69727c0f2637bbcec1dbc487 tree f9ccb461cbfb1837f611b5e31a070945b8cdb867 parent 63c833da2ed9fd43d3f000f35d2ee141ba42e411 author tonouchi510 <[email protected]> 1670215632 +0900 committer tonouchi510 <[email protected]> 1670215632 +0900 Add chapter_2.txt 後ほど解説

• 親 commit のハッシュ値 • committer と author のタイムスタンプ‧名前‧メールアドレス • コミットメッセージ $ git cat-ﬁle -p bdcc6040408bacfb69727c0f2637bbcec1dbc487 tree f9ccb461cbfb1837f611b5e31a070945b8cdb867 parent 63c833da2ed9fd43d3f000f35d2ee141ba42e411 author tonouchi510 <[email protected]> 1670215632 +0900 committer tonouchi510 <[email protected]> 1670215632 +0900 Add chapter_2.txt

• 親 commit のハッシュ値 • committer と author のタイムスタンプ‧名前‧メールアドレス • コミットメッセージ $ git cat-ﬁle -p bdcc6040408bacfb69727c0f2637bbcec1dbc487 tree f9ccb461cbfb1837f611b5e31a070945b8cdb867 parent 63c833da2ed9fd43d3f000f35d2ee141ba42e411 author tonouchi510 <[email protected]> 1670215632 +0900 committer tonouchi510 <[email protected]> 1670215632 +0900 Add chapter_2.txt これをSHA-1ハッシュ化したものがKeyになる

• 親 commit のハッシュ値 • committer と author のタイムスタンプ‧名前‧メールアドレス • コミットメッセージこれらのいずれか1つでも変わると、（SHA-1が衝突しない限り）別の commit ハッシュになる。=> コミットは⼀意に定まる親コミットのハッシュも含んでいるため、改ざんにも強い。次に新出のこれを解説

78 ©MIXI tree オブジェクト treeオブジェクトはディレクトリとしての情報を保持しています。バージョンごとに、Git 管理下の全てのディレクトリに対応する tree オブジェクトが作成されます。実際に、Key=3f1c1a8a1e11f3147eee31b2bd9f9fb52936f87b のオブジェクトの中⾝を
みていきます。 $ git cat-file -t 3f1c1a8a1e11f3147eee31b2bd9f9fb52936f87b tree $ git cat-file -s 3f1c1a8a1e11f3147eee31b2bd9f9fb52936f87b 82 $ git cat-file -p 3f1c1a8a1e11f3147eee31b2bd9f9fb52936f87b 100644 blob bc96df368963ca37edb955c1c0403471b7c90720 chapter_1.txt 100644 blob aaa8bd84e6e4837be33eee9d1ddb9d06d8d2e46c chapter_2.txt

79 ©MIXI tree オブジェクトこちらは reports ディレクトリのある時点の tree オブジェクトです。左から順に、パーミッション、種類、Key、ファイル名が記録されています。
=> この tree オブジェクトが作られた時点での、「そのディレクトリに存在したファイル」と、「そのバージョンの blobハッシュ値（Key）」 ※（再）blob オブジェクトはファイルの情報が⼊っているオブジェクト $ git cat-ﬁle -p 3f1c1a8a1e11f3147eee31b2bd9f9fb52936f87b 100644 blob bc96df368963ca37edb955c1c0403471b7c90720 chapter_1.txt 100644 blob aaa8bd84e6e4837be33eee9d1ddb9d06d8d2e46c chapter_2.txt

80 ©MIXI tree オブジェクト次に、同じバージョンでの、リポジトリのルートディレクトリに対応するtreeオブジェクトも⾒ていきます。ルートディレクトリにあるファイルの他に、先ほどの reports ディレクトリに関する tree
オブジェクトへの参照（Key=3f1c1a8a1e11f3147eee31b2bd9f9fb52936f87b）も保持していることが分かると思います。 $ git cat-ﬁle -p f9ccb461cbfb1837f611b5e31a070945b8cdb867 100644 blob c6c63202bf8abde33a80dfc0a230ad1e9791a33b README.md 040000 tree 3f1c1a8a1e11f3147eee31b2bd9f9fb52936f87b reports 100644 blob 9daeafb9864cf43055ae93beb0afd6c7d144bfa4 test.txt

81 ©MIXI tree オブジェクトルートディレクトリの tree オブジェクトから、順に辿ることでリポジトリの全てのblob オブジェクト（つまり、その時点のファイルの内容）にアクセスすることができます。このように、Git はファイルシステム
になっているのです。最後に blob オブジェクトについても⾒ていきます。

82 ©MIXI blob オブジェクト blobオブジェクトは、ファイルの実際のバックアップに当たるオブジェクトで、ある時点（バージョン）でのファイルの情報を記録しています。この2つはどちらも同⼀ファイル（README.md）の blob オブジェクトで、それぞれ特定のバージョンに対応する
blob オブジェクトとなっています。ここで重要なのは、blob オブジェクトは「ファイルの差分ではなく、ある時点でのファイルの中⾝そのものを記録している」ということです。 => Gitの機能を語る上で重要な要素 $ git cat-ﬁle -p f733735eb5e737a9c15756e0556f2155660fa4b0 # git-tutorial-3 $ git cat-ﬁle -p c6c63202bf8abde33a80dfc0a230ad1e9791a33b # git-chapter-3 差分が記録されているわけではない

©MIXI コミットの仕組み

84 ©MIXI commit の仕組みここまで紹介した 3つのオブジェクトに関する内容を踏まえて、コミットの仕組みを解説していきます。まずここまでの話を整理すると • commit
オブジェクトは、その時点のリポジトリのルートにあたる tree オブジェクトを参照 • tree オブジェクトは、その時点のディレクトリ配下の tree オブジェクトと blob オブジェクトへの参照を持つ • blob オブジェクトは、その時点のファイルのフルバックアップ => commit オブジェクトを参照することで、そこから辿ることで commit 時点のリポジトリの状態を完全に再現できる => スナップショット

85 ©MIXI 補⾜ Gitの checkout/switch で、かなり遠い履歴に移る際にも瞬時にリポジトリの状態を復元できることに驚いた経験はないでしょうか？ Gitがファイルを差分で管理しているとしたら、checkout/switch の⾼速な移動は実現できません。コミットの実態がスナップショットになっていることが⾼速な
checkout/switch を可能にしています。 Gitではバージョン間を遷移する際にかかる時間は、履歴の遠さには依存せず、変更されたファイル数に依存します。

86 ©MIXI commit の流れコミットには⼤きく3つの段階があります。 1. コードを編集する 2. 編集したコードをaddする 3.
commitするステップ2で編集したコードを add しています。この時、Git 内部で⾏われていることを深掘りしていきます。

87 ©MIXI index について add について、「コミットに含めたいファイルをステージング（index）に登録している」という説明を⾒たことはあるかもしれません。これをもう少し具体的に解説します。 add の説明に⼊る前に、index について解説していきます。
index の情報は .git/index に記録されているので、オブジェクトと同じように⾒ていきます。 $ cat .git/index DIRCc�[��c�c�[�d:�KCH��S_X�/�S��2��:��0��; README.mdc�b�WF;c�b�Te�KK��S_X�/�S��6�c�7�U��@4q�� reports/chapter_1.txtc�b��uc�b��9KK��S_X�/�S0�� {�>�۝��lreports/chapter_2.txtc�w�2�c�w�2�Ka��S_X�/�S��L�0U�� D�test.txtTREE94 1 �̴a��7�� E�͸greports2 0 ?��~�1��)6�{�\��(l ��y}8ܗ.cA

88 ©MIXI index についてバイナリファイルなので、そのまま cat するだけだと⽂字化けしてしまいます。 index の中⾝を⾒るためのサブコマンドも⽤意されているので、そちらを使います。左から、ファイルの種類＋パーミッション、blob
ハッシュ、コンフリクトフラグ、ファイル名が並んでいます。 index には、現在参照しているバージョン（コミット）で管理対象（ステージングエリア含め）の全ての blob オブジェクトへの参照をもっています。 $ git ls-ﬁles --stage 100644 c6c63202bf8abde33a80dfc0a230ad1e9791a33b 0 README.md 100644 bc96df368963ca37edb955c1c0403471b7c90720 0 reports/chapter_1.txt 100644 aaa8bd84e6e4837be33eee9d1ddb9d06d8d2e46c 0 reports/chapter_2.txt 100644 9daeafb9864cf43055ae93beb0afd6c7d144bfa4 0 test.txt

90 ©MIXI add の内部動作例えば、適当にファイルを作成してaddすると、indexは以下のように更新されています。 temp/hoge.txtがindexに追加されていることがわかります。また、blobハッシュも記録されており、該当Keyを⾒にいくとblobオブジェクトも⽣成されていることが分かると思います。すでにあるファイルを編集した場合も、新しいblobオブジェクトが⽣成され、indexがそのハッシュ値に書き変わります。
$ echo hoge > temp/hoge.txt $ git add temp/hoge.txt $ git ls-ﬁles --stage 100644 c6c63202bf8abde33a80dfc0a230ad1e9791a33b 0 README.md 100644 bc96df368963ca37edb955c1c0403471b7c90720 0 reports/chapter_1.txt 100644 aaa8bd84e6e4837be33eee9d1ddb9d06d8d2e46c 0 reports/chapter_2.txt 100644 9c595a6fb7692405a5c4a10e1caf93d7a5bd9c37 0 temp/hoge.txt

91 ©MIXI commit の内部挙動次に、commit した時に起こる内部挙動は、以下の通りです。 • index から tree
オブジェクトを⽣成 • commit オブジェクトを⽣成 • HEAD を新しい commit ハッシュに書き換えそれぞれ詳しく解説していきます。

92 ©MIXI commit の内部挙動 ~tree オブジェクトの作成~ tree オブジェクトの作成はこの段階で⾏われます。 commit すると、新たに作成されたディレクトリに対する
tree オブジェクトだけでなく、リポジトリのルートディレクトリを含むすべてのディレクトリに対する tree オブジェクトの構築処理が動きます。 => index に記録された情報から構築可能この時、効率化のために index に変更があった部分だけが新しい blob および tree オブジェクトに書き換えられ、それ以外の参照が変わらない部分はそのまま流⽤します。

93 ©MIXI commit の内部挙動 ~commit オブジェクトの作成~ 新しいルートディレクトリまでの tree オブジェクトが⽣成できたら、次は commit
オブジェクトを作成します。 commit オブジェクトに記録する情報（再掲） • リポジトリのルートディレクトリのtreeオブジェクトのハッシュ値（Key） • 親commitのハッシュ値 • committerとauthorのタイムスタンプ‧名前‧メールアドレス • コミットメッセージ先述の通り、リポジトリのルートにあたるtreeオブジェクトを参照しているため、そこからリポジトリ全体をたどることができます。

94 ©MIXI commit の内部挙動 ~HEAD を新しい commit ハッシュに書き換え~ 最後に、現在参照しているコミットを指す .git/HEAD
を必要に応じて書き換えます。 .git/HEAD についても中⾝を⾒てみます。 refs/heads/main（mainブランチ）を参照しているとあるのでそちらを辿って⾒ます。ここに記録されているのが commit ハッシュです。ここを新しいコミットのハッシュ値（commit オブジェクトのKey）に書き換えることで、コミット操作を完了します。 $ cat .git/HEAD ref: refs/heads/main $ cat .git/refs/heads/main a311bf20bbd5d272f9286b10dd3c8dc4adc96306

95 ©MIXI refs について refs は特定のコミットを指すポインタのようなものです。コミットハッシュのエイリアスとも⾔えます。具体的には以下のものが refs に該当します。 •
tag ◦ light-weight tag ◦ annotated tag（省略） • branch • HEAD（すでにcommitの仕組みで登場）

96 ©MIXI refs について ~light-weight tag~ light-weight tag を作成して確認します。タグは .git/refs/tags/
に保存されます。 tag を付与した時点のコミットハッシュが記録されていることがわかると思います。 $ git tag test-1 $ git log -n 1 --oneline bdcc604 (HEAD -> main, tag: test-1) Add chapter_2.txt $ cat .git/refs/tags/test-1 bdcc6040408bacfb69727c0f2637bbcec1dbc487

97 ©MIXI refs について ~branch~ 次に branch です。こちらは基本的には light-weight tag
と同様です。違いとしては、保存場所が .git/refs/heads 以下になっている点と、branch の場合はその branch でコミットを実⾏すると、branch が指しているコミットハッシュが⾃動で書き変わっていくことです。 ※「commitの内部挙動 ~HEADを新しい commit ハッシュに書き換え~」で解説した通り branch の実態も、単に特定のコミットへのポインタなので、branch を削除してしまったとしても焦る必要はありません。 $ cat .git/refs/heads/main bdcc6040408bacfb69727c0f2637bbcec1dbc487

98 ©MIXI refs について ~HEAD~ 最後に HEAD です。HEAD は先ほども⾔った通り、現在の commit
を指す refs です。 .git/HEAD に保存されており、commit や checkout/switch などで書き変わります。また、branch 名で checkout/switch した時はコミットハッシュではなく branch の場所が書き込まれるようになっています。

99 ©MIXI commit の仕組み（再掲）ここまでで、commit に関連する全てのオブジェクトと、仕組みを解説してきました。 commit の流れを再度まとめておきます。 • コードを編集する
• 編集したコードをaddする ◦ add したファイルの blob オブジェクトの⽣成 ◦ index の更新 • commitする ◦ リポジトリ全体の tree オブジェクトの⽣成 ◦ commit オブジェクトを⽣成 ◦ HEAD の書き換え

101 ©MIXI reset コマンド reset はオプション次第で⾊々なことが可能なサブコマンドです。以下の⽤途で使ったことがあるかもしれません。 • 作業の取り消し •
add の取り消し • commit の取り消し reset についても実際の内部挙動を⾒ていきます。

102 ©MIXI reset コマンド reset では、基本的には以下の 3 つを書き換えることでそれらを実現しています。 • ワークツリー(作業ディレクトリ)
• index • HEAD おおまかには soft, mixed, hard の 3 種類のオプションがあり、指定した commit ハッシュに向けて、それぞれの内容を書き換える。   HEAD  index  ワークツリー  git reset --soft <commit ハッシュ> 書き換える      git reset --mixed <commit ハッシュ> 書き換える  書き換える    git reset --hard <commit ハッシュ> 書き換える  書き換える  書き換える 

103 ©MIXI reset コマンドどのオプションでも HEAD の書き換えはある。なお、checkout/switch と異なり、reset では
branch の参照先も書き換わる。 checkout/switch の場合 first commit  master.txt を追加  README.md に  「master」と追記  develop.txt を追加  master  README.md に  「develop」と追記  develop  HEAD 

branch の参照先も書き換わる。 checkout/switch の場合 first commit  master.txt を追加  README.md に  「master」と追記  develop.txt を追加  master  README.md に  「develop」と追記  develop  HEAD 

branch の参照先も書き換わる。 reset の場合 first commit  master.txt を追加  README.md に  「master」と追記  develop.txt を追加  master  README.md に  「develop」と追記  develop  HEAD 

107 ©MIXI reset コマンドここまで解説した機能があることで、前述した⽤途を実現できます。（再掲） • commit の取り消し ◦
1 つ前の commit ハッシュに branch を向けることで、最新のコミットをなかったことにできる（branch の参照先を変えられる機能があるため） • add の取り消し ◦ git reset --mixed HEAD とすると、index を HEAD の状況に戻せるので、add を取り消すことができる • 作業の取り消し ◦ git reset —hard HEAD とすると、ワークツリーの状況を HEAD に戻せる ◦ ※現在では、restore の⽅が推奨

108 ©MIXI reset コマンド add, commitの取り消しについて補⾜あくまで reset で⾏われているのは以下の操作です。 add
や commit の内部動作で⾏なっていたことを完全に無かったことにできているでしょうか？   HEAD  index  ワークツリー  git reset --soft <commit ハッシュ> 書き換える      git reset --mixed <commit ハッシュ> 書き換える  書き換える    git reset --hard <commit ハッシュ> 書き換える  書き換える  書き換える 

109 ©MIXI add と commit の内部挙動再掲 add した時に起こる内部挙動 •
blob オブジェクトの⽣成 • index の更新 commit した時の内部挙動 • index から tree オブジェクトを⽣成 • commit オブジェクトを⽣成 • HEAD を新しい commit ハッシュに書き換え

110 ©MIXI まとめ以降はこの後の git challenge で取り組んでください。ここまでの内容が分かっていれば、講義の最初に挙げた以下の問題が起きた時にも、焦らず対処できるはずです。 •
ブランチをマージ前に間違えて消してしまった！ • コミットを誤って消してしまった！ • コミット前（ステージングエリア）のファイルを消してしまった！

©MIXI

Git 研修 Basic【MIXI 24新卒技術研修】

Git 研修 Basic【MIXI 24新卒技術研修】

Video

Transcript

More Decks by MIXI ENGINEERS

Other Decks in Technology

Featured