Git研修【ミクシィ22新卒技術研修】

Slide 1

Slide 1 text

ミクシィGit研修  (22新卒)  1

Slide 2

Slide 2 text

講師について  2

Slide 3

Slide 3 text

自己紹介    登内雅人 (26)  株式会社ミクシィ 2020 年度新卒       ● みてね事業部（家族アルバムみてね）でMLエンジニアやってます   ○ CV系の研究開発したり、MLOps整備したり   ○ #machine-learning でML系書籍の輪読会やってます（宣伝）   ● 業務外では DDDとかマイクロサービスアーキテクチャらへんにハマってる   ● 趣味は最近は筋トレ、ランニング、将棋、ポーカーとかにハマってる   3 github pages: https://github.com/tonouchi510 普段使っている技術とかその他の活動はこちら

Slide 4

Slide 4 text

事前アンケートについて  4

Slide 5

Slide 5 text

事前アンケートについて  Q. Git は普段どのようなシーンで使いますか？  → 全員使ったことがある  → 業務やチーム開発で使ったことがある人も大体半分くらいいる    Q. 今まで経験したエラーで解決できなかったものはありますか？  → いくつかあったのであとで解説  5

Slide 6

Slide 6 text

事前アンケートについて  Q. 特に解説してほしいgitコマンドはありますか？    ● rebaseが一番多い    ● bisectとかニッチなやつも出てきた    この辺も少し解説していきます。  6

Slide 7

Slide 7 text

事前アンケートについて  今日は、事前アンケートの要望も取り入れつつ  - Git の基礎  - Git によるチーム開発のいろは  - Git の内部構造  についてやっていきます。  最後に、今日学んだことを生かして GitChallenge に挑戦してもらいます。  7

Slide 8

Slide 8 text

というわけで  8

Slide 9

Slide 9 text

今日の予定  9 shumon.fujita  10:30 Git の基礎  11:30 Git によるチーム開発のいろは  12:00 昼食  13:00 Git の内部構造  15:00 GitChallenge に挑戦  17:30 解説  18:30 終了 

Slide 10

Slide 10 text

Git の基礎  10 shumon.fujita 

Slide 11

Slide 11 text

Git の基礎  Git はバージョン管理システム(VCS) の 1 つ。  11 shumon.fujita 

Slide 12

Slide 12 text

Git の基礎  Git はバージョン管理システム(VCS) の 1 つ。  バージョン管理とは？    12 shumon.fujita 

Slide 13

Slide 13 text

Git の基礎  Git はバージョン管理システム(VCS) の 1 つ。  バージョン管理とは？  卒論.pdf / 卒論(1).pdf / 卒論_最新.pdf / 卒論_修正版.pdf / 卒論_最終稿.pdf / 卒論_提出用.pdf     13 shumon.fujita 

Slide 14

Slide 14 text

Git の基礎  Git はバージョン管理システム(VCS) の 1 つ。  バージョン管理とは？  卒論.pdf / 卒論(1).pdf / 卒論_最新.pdf / 卒論_修正版.pdf / 卒論_最終稿.pdf / 卒論_提出用.pdf   → どれが最新？  14 shumon.fujita 

Slide 15

Slide 15 text

Git の基礎  Git はバージョン管理システム(VCS) の 1 つ。  バージョン管理とは？  卒論.pdf / 卒論(1).pdf / 卒論_最新.pdf / 卒論_修正版.pdf / 卒論_最終稿.pdf / 卒論_提出用.pdf   → どれが最新？ 1 つ前の版は？     15 shumon.fujita 

Slide 16

Slide 16 text

Git の基礎  Git はバージョン管理システム(VCS) の 1 つ。  バージョン管理とは？  卒論.pdf / 卒論(1).pdf / 卒論_最新.pdf / 卒論_修正版.pdf / 卒論_最終稿.pdf / 卒論_提出用.pdf   → どれが最新？ 1 つ前の版は？ 5 つ前の版は？       16 shumon.fujita 

Slide 17

Slide 17 text

Slide 18

Slide 18 text

Slide 19

Slide 19 text

Git の基礎  Git はバージョン管理システム(VCS) の 1 つ。  バージョン管理とは？  卒論.pdf / 卒論(1).pdf / 卒論_最新.pdf / 卒論_修正版.pdf / 卒論_最終稿.pdf / 卒論_提出用.pdf   → どれが最新？ 1 つ前の版は？ 5 つ前の版は？   卒論_20210118.pdf / 卒論_20210120.pdf / 卒論20210201.pdf   → 新しいバージョン保存するたびに容量が 2 倍 3 倍になっていく......     1 人で書いている卒論ならこれでもなんとかなるけど、100 人で数年かけて開発するソフトウェアならヤバイ     19 shumon.fujita 

Slide 20

Slide 20 text

Slide 21

Slide 21 text

Slide 22

Slide 22 text

Git の基礎  Git を使う上で重要な機能として branch と merge がある。       22 shumon.fujita 

Slide 23

Slide 23 text

Git の基礎  Git を使う上で重要な機能として branch と merge がある。     Git は単に時系列順にバージョンを管理するだけでなく、別々の時間軸のバージョンを管理できる。     23 shumon.fujita 

Slide 24

Slide 24 text

Git の基礎  Git を使う上で重要な機能として branch と merge がある。     Git は単に時系列順にバージョンを管理するだけでなく、別々の時間軸のバージョンを管理できる。   さらにそれらを統合することができる。   24 shumon.fujita 

Slide 25

Slide 25 text

Git の基礎  Git を使う上で重要な機能として branch と merge がある。     Git は単に時系列順にバージョンを管理するだけでなく、別々の時間軸のバージョンを管理できる。   さらにそれらを統合することができる。   別々の時間軸のことを branch と呼び、それらを統合することを merge と言う。   25 shumon.fujita 

Slide 26

Slide 26 text

Git の基礎  Git を使う上で重要な機能として branch と merge がある。     Git は単に時系列順にバージョンを管理するだけでなく、別々の時間軸のバージョンを管理できる。   さらにそれらを統合することができる。   別々の時間軸のことを branch と呼び、それらを統合することを merge と言う。         この merge ができるので、branchを分けて独立に進めることができる。   26 shumon.fujita  元バージョン  A  A’  元バージョンに  A A’ B B’ を足したもの  B  B’ 

Slide 27

Slide 27 text

branch と merge を経験してみる。     Git の基礎  27 shumon.fujita 

Slide 28

Slide 28 text

Git の基礎  branch と merge を経験してみる。   まずは Git リポジトリを作って、適当に commit を作る。 $ mkdir hoge && cd hoge $ git init $ echo Hello > README.md $ git add README.md $ git commit -m "first commit" $ git log --oneline 45e2f9c (HEAD -> master) first commit   28 shumon.fujita 

Slide 29

Slide 29 text

git branch で現在作られている branch 一覧を見たり、新しい branch を作ったりできる。       Git の基礎  29 shumon.fujita 

Slide 30

Slide 30 text

Git の基礎  git branch で現在作られている branch 一覧を見たり、新しい branch を作ったりできる。     $ git branch * master   30 shumon.fujita 

Slide 31

Slide 31 text

Git の基礎  git branch で現在作られている branch 一覧を見たり、新しい branch を作ったりできる。     $ git branch * master   31 shumon.fujita  master はデフォルトで  作られる branch 

Slide 32

Slide 32 text

Git の基礎  git branch で現在作られている branch 一覧を見たり、新しい branch を作ったりできる。   ちなみに Git 2.28 以降なら git config --global init.defaultBranch で init 時に作られる branch を変更できる。   $ git branch * master   32 shumon.fujita  master はデフォルトで  作られる branch 

Slide 33

Slide 33 text

Slide 34

Slide 34 text

Git の基礎  git branch で現在作られている branch 一覧を見たり、新しい branch を作ったりできる。   ちなみに Git 2.28 以降なら git config --global init.defaultBranch で init 時に作られる branch を変更できる。   $ git branch * master $ git branch develop $ git branch develop * master   34 shumon.fujita  master はデフォルトで  作られる branch 

Slide 35

Slide 35 text

Git の基礎  git branch で現在作られている branch 一覧を見たり、新しい branch を作ったりできる。   ちなみに Git 2.28 以降なら git config --global init.defaultBranch で init 時に作られる branch を変更できる。   $ git branch * master $ git branch develop $ git branch develop * master   35 shumon.fujita  master はデフォルトで  作られる branch  develop という新しい  branch が作られている 

Slide 36

Slide 36 text

Git の基礎  git branch で現在作られている branch 一覧を見たり、新しい branch を作ったりできる。   ちなみに Git 2.28 以降なら git config --global init.defaultBranch で init 時に作られる branch を変更できる。   $ git branch * master $ git branch develop $ git branch develop * master 新しい branch を作っただけで、まだ master にいることは注意。   36 shumon.fujita  master はデフォルトで  作られる branch  develop という新しい  branch が作られている 

Slide 37

Slide 37 text

branch を移動したい場合は、 git checkout を使う。    Git の基礎  37 shumon.fujita 

Slide 38

Slide 38 text

Git の基礎  branch を移動したい場合は、 git checkout を使う。    $ git branch develop * master   38 shumon.fujita 

Slide 39

Slide 39 text

Git の基礎  branch を移動したい場合は、 git checkout を使う。    $ git branch develop * master $ git checkout develop   39 shumon.fujita 

Slide 40

Slide 40 text

Git の基礎  branch を移動したい場合は、 git checkout を使う。    $ git branch develop * master $ git checkout develop $ git branch * develop master   40 shumon.fujita 

Slide 41

Slide 41 text

Git の基礎  branch を移動したい場合は、 git checkout を使う。    $ git branch develop * master $ git checkout develop $ git branch * develop master   41 shumon.fujita  * が現在の branch を  表している 

Slide 42

Slide 42 text

Git の基礎  branch を移動したい場合は、 git checkout を使う。  あとは、それぞれの branch を好きに移動しながら開発を進めていく。   $ git branch develop * master $ git checkout develop $ git branch * develop master   42 shumon.fujita  * が現在の branch を  表している 

Slide 43

Slide 43 text

Git の基礎  master と develop でそれぞれ開発を進める。   43 shumon.fujita 

Slide 44

Slide 44 text

Git の基礎  master と develop でそれぞれ開発を進める。   $ git log --oneline master e0d4607 (master) README.md に「master」と追記 76d6092 master.txt を追加 45e2f9c first commit 44 shumon.fujita 

Slide 45

Slide 45 text

Git の基礎  master と develop でそれぞれ開発を進める。   $ git log --oneline master e0d4607 (master) README.md に「master」と追記 76d6092 master.txt を追加 45e2f9c first commit $ git log --oneline develop a81fbd0 (develop) README.md に「develop」と追記 52ad527 develop.txt を追加 45e2f9c first commit 45 shumon.fujita 

Slide 46

Slide 46 text

Slide 47

Slide 47 text

Git の基礎  図で表すとこんな感じ。            47 shumon.fujita  first commit  master.txt を追加  README.md に  「master」と追記  develop.txt を追加  master  README.md に  「develop」と追記  develop 

Slide 48

Slide 48 text

Git の基礎  図で表すとこんな感じ。次はこれを merge してみる。             48 shumon.fujita  first commit  master.txt を追加  README.md に  「master」と追記  develop.txt を追加  master  README.md に  「develop」と追記  develop 

Slide 49

Slide 49 text

Git の基礎  図で表すとこんな感じ。次はこれを merge してみる。           Git では、「merge する branch」= “theirs”、「merge される branch」= “ours” と呼ぶ。    49 shumon.fujita  first commit  master.txt を追加  README.md に  「master」と追記  develop.txt を追加  master  README.md に  「develop」と追記  develop 

Slide 50

Slide 50 text

Git の基礎  図で表すとこんな感じ。次はこれを merge してみる。           Git では、「merge する branch」= “theirs”、「merge される branch」= “ours” と呼ぶ。  今回は theirs = develop, ours = master として merge していく。    50 shumon.fujita  first commit  master.txt を追加  README.md に  「master」と追記  develop.txt を追加  master  README.md に  「develop」と追記  develop 

Slide 51

Slide 51 text

Git の基礎  merge するには、ours に checkout している状態で、 git merge とする。    $ git branch develop * master   51 shumon.fujita 

Slide 52

Slide 52 text

Git の基礎  merge するには、ours に checkout している状態で、 git merge とする。    $ git branch develop * master   52 shumon.fujita 

Slide 53

Slide 53 text

Git の基礎  merge するには、ours に checkout している状態で、 git merge とする。    $ git branch develop * master $ git merge develop   53 shumon.fujita 

Slide 54

Slide 54 text

Git の基礎  merge するには、ours に checkout している状態で、 git merge とする。    $ git branch develop * master $ git merge develop Auto-merging README.md CONFLICT (content): Merge conflict in README.md Automatic merge failed; fix conflicts and then commit the result.   54 shumon.fujita 

Slide 55

Slide 55 text

Slide 56

Slide 56 text

Git の基礎  merge するには、ours に checkout している状態で、 git merge とする。  README.md でコンフリクト(競合)を起こして、Automatic merge に失敗した。   $ git branch develop * master $ git merge develop Auto-merging README.md CONFLICT (content): Merge conflict in README.md Automatic merge failed; fix conflicts and then commit the result.   56 shumon.fujita 

Slide 57

Slide 57 text

Git の基礎  merge すると、Git は theirs で開発した差分を自動的に ours に取り込んでくれる。         57 shumon.fujita 

Slide 58

Slide 58 text

Git の基礎  merge すると、Git は theirs で開発した差分を自動的に ours に取り込んでくれる。   しかし、ours と theirs で同じ箇所を変更していた場合、どちらの変更を残すべきか自動的に判定できない。         58 shumon.fujita 

Slide 59

Slide 59 text

Git の基礎  merge すると、Git は theirs で開発した差分を自動的に ours に取り込んでくれる。   しかし、ours と theirs で同じ箇所を変更していた場合、どちらの変更を残すべきか自動的に判定できない。   → これがコンフリクト        59 shumon.fujita 

Slide 60

Slide 60 text

Git の基礎  merge すると、Git は theirs で開発した差分を自動的に ours に取り込んでくれる。   しかし、ours と theirs で同じ箇所を変更していた場合、どちらの変更を残すべきか自動的に判定できない。   → これがコンフリクト    コンフリクトが起きたら、人間が手動で差分を取り込んで、コンフリクトを解消させる必要がある。       60 shumon.fujita 

Slide 61

Slide 61 text

Slide 62

Slide 62 text

git status で、どのファイルでコンフリクトしているか確認できる。       Git の基礎  62 shumon.fujita 

Slide 63

Slide 63 text

Git の基礎  git status で、どのファイルでコンフリクトしているか確認できる。     $ git status On branch master -- 省略 -- Unmerged paths: (use "git add ..." to mark resolution) both modified: README.md   63 shumon.fujita 

Slide 64

Slide 64 text

Git の基礎  git status で、どのファイルでコンフリクトしているか確認できる。   both modified となっているファイルがコンフリクト中。   $ git status On branch master -- 省略 -- Unmerged paths: (use "git add ..." to mark resolution) both modified: README.md   64 shumon.fujita 

Slide 65

Slide 65 text

Slide 66

Slide 66 text

Git の基礎  コンフリクト中のファイルを開けば、どの行がどのようにコンフリクトしているのか Git が教えてくれるが、   自動で検出していることもあって、あまり適切でないことが多い。       66 shumon.fujita 

Slide 67

Slide 67 text

Slide 68

Slide 68 text

Git の基礎  コンフリクト中のファイルを開けば、どの行がどのようにコンフリクトしているのか Git が教えてくれるが、   自動で検出していることもあって、あまり適切でないことが多い。     コンフリクト解消の基本は、それぞれの branch がそのファイルに対して、どのような修正を施したのかの、   意図や内容をきちんと確認してから手を付けること。  ついついコンフリクト行だけを眺めて、手癖でコンフリクト解消したくなるけど、先に確認するコストと、   不適切な merge になってしまった場合の後始末のコストを比べたら、絶対先に確認するべき。      68 shumon.fujita 

Slide 69

Slide 69 text

Slide 70

Slide 70 text

Slide 71

Slide 71 text

Git の基礎  ours と theirs の変更を比較したい場合、まずそれぞれの branch がどこから分岐しているかを調べる。     71 shumon.fujita 

Slide 72

Slide 72 text

Git の基礎  ours と theirs の変更を比較したい場合、まずそれぞれの branch がどこから分岐しているかを調べる。   git merge-base で分岐した commit を調べられる。       72 shumon.fujita 

Slide 73

Slide 73 text

Slide 74

Slide 74 text

Git の基礎  ours と theirs の変更を比較したい場合、まずそれぞれの branch がどこから分岐しているかを調べる。   git merge-base で分岐した commit を調べられる。   $ git merge-base master develop 45e2f9c8827024f53ca982c70676614f781205d7       74 shumon.fujita  first commit  master.txt を追加  README.md に  「master」と追記  develop.txt を追加  master  README.md に  「develop」と追記  develop 

Slide 75

Slide 75 text

Git の基礎  ours と theirs の変更を比較したい場合、まずそれぞれの branch がどこから分岐しているかを調べる。   git merge-base で分岐した commit を調べられる。   $ git merge-base master develop 45e2f9c8827024f53ca982c70676614f781205d7       75 shumon.fujita  first commit  master.txt を追加  README.md に  「master」と追記  develop.txt を追加  master  README.md に  「develop」と追記  develop  この commit ハッシュが分かる 

Slide 76

Slide 76 text

Git の基礎  git diff で、merge-base から README.md にどんな修正を加えたのか確認する。     76 shumon.fujita 

Slide 77

Slide 77 text

Git の基礎  git diff で、merge-base から README.md にどんな修正を加えたのか確認する。   $ git diff 45e2f9c8827024f53ca982c70676614f781205d7 develop README.md   77 shumon.fujita 

Slide 78

Slide 78 text

Slide 79

Slide 79 text

Git の基礎  git diff で、merge-base から README.md にどんな修正を加えたのか確認する。   $ git diff 45e2f9c8827024f53ca982c70676614f781205d7 develop README.md diff --git a/README.md b/README.md index e965047..214c073 100644 --- a/README.md +++ b/README.md @@ -1 +1 @@ -Hello +Hello develop $ git diff 45e2f9c8827024f53ca982c70676614f781205d7 master README.md   79 shumon.fujita 

Slide 80

Slide 80 text

Slide 81

Slide 81 text

Git の基礎  結果、master と develop でやりたかったことは次の通り。   - master : Hello → Hello master に変更   - develop : Hello → Hello develop に変更           81 shumon.fujita 

Slide 82

Slide 82 text

Git の基礎  結果、master と develop でやりたかったことは次の通り。   - master : Hello → Hello master に変更   - develop : Hello → Hello develop に変更     今回は ours が master なので、Hello master にすることにしたとする。         82 shumon.fujita 

Slide 83

Slide 83 text

Git の基礎  結果、master と develop でやりたかったことは次の通り。   - master : Hello → Hello master に変更   - develop : Hello → Hello develop に変更     今回は ours が master なので、Hello master にすることにしたとする。   $ emacs README.md # README.md を修正する       83 shumon.fujita 

Slide 84

Slide 84 text

Slide 85

Slide 85 text

Slide 86

Slide 86 text

Slide 87

Slide 87 text

Git の基礎  コンフリクト解消は人間の手が入るため、必要な差分が消えたり、不要な差分が混入したりする可能性がある。             87 shumon.fujita 

Slide 88

Slide 88 text

Git の基礎  コンフリクト解消は人間の手が入るため、必要な差分が消えたり、不要な差分が混入したりする可能性がある。   → 大前提として、コンフリクトは起きないのが 1 番。             88 shumon.fujita 

Slide 89

Slide 89 text

Git の基礎  コンフリクト解消は人間の手が入るため、必要な差分が消えたり、不要な差分が混入したりする可能性がある。   → 大前提として、コンフリクトは起きないのが 1 番。     Git には fast-forward merge という絶対にコンフリクトが起きない merge がある。           89 shumon.fujita 

Slide 90

Slide 90 text

Slide 91

Slide 91 text

Git の基礎  コンフリクト解消は人間の手が入るため、必要な差分が消えたり、不要な差分が混入したりする可能性がある。   → 大前提として、コンフリクトは起きないのが 1 番。     Git には fast-forward merge という絶対にコンフリクトが起きない merge がある。   fast-forward merge とは、 merge-base が ours のときに起こる merge のこと。   さっきの例で言うと、↓のような状態で merge すると fast-foward merge が発生する。           91 shumon.fujita  first commit  master.txt を追加  README.md に  「master」と追記  develop.txt を追加  master  README.md に  「develop」と追記  develop 

Slide 92

Slide 92 text

Git の基礎  コンフリクト解消は人間の手が入るため、必要な差分が消えたり、不要な差分が混入したりする可能性がある。   → 大前提として、コンフリクトは起きないのが 1 番。     Git には fast-forward merge という絶対にコンフリクトが起きない merge がある。   fast-forward merge とは、 merge-base が ours のときに起こる merge のこと。   さっきの例で言うと、↓のような状態で merge すると fast-foward merge が発生する。         この状態で merge すると、Git は merge 作業をサボって、master の向き先を develop にするだけになる。   92 shumon.fujita  first commit  master.txt を追加  README.md に  「master」と追記  develop.txt を追加  master  README.md に  「develop」と追記  develop 

Slide 93

Slide 93 text

Git の基礎  コンフリクト解消は人間の手が入るため、必要な差分が消えたり、不要な差分が混入したりする可能性がある。   → 大前提として、コンフリクトは起きないのが 1 番。     Git には fast-forward merge という絶対にコンフリクトが起きない merge がある。   fast-forward merge とは、 merge-base が ours のときに起こる merge のこと。   さっきの例で言うと、↓のような状態で merge すると fast-foward merge が発生する。         この状態で merge すると、Git は merge 作業をサボって、master の向き先を develop にするだけになる。   93 shumon.fujita  first commit  master.txt を追加  README.md に  「master」と追記  develop.txt を追加  master  README.md に  「develop」と追記  develop 

Slide 94

Slide 94 text

要望の多かったrebaseについて         Git の基礎  94

Slide 95

Slide 95 text

要望の多かったrebaseについて   rebaseでできることその１        Git の基礎  95

Slide 96

Slide 96 text

要望の多かったrebaseについて   rebaseでできることその１  ● ブランチの分岐元を変更する       Git の基礎  96

Slide 97

Slide 97 text

Git の基礎  97 要望の多かったrebaseについて   rebaseでできることその１  ● ブランチの分岐元を変更する                

Slide 98

Slide 98 text

Git の基礎  98 要望の多かったrebaseについて   rebaseでできることその１  ● ブランチの分岐元を変更する           developブランチを、最新のmasterから分岐したことにする。        

Slide 99

Slide 99 text

Git の基礎  99 要望の多かったrebaseについて   rebaseでできることその１  ● ブランチの分岐元を変更する           developブランチを、最新のmasterから分岐したことにする。   こうすると、masterにマージする際に fast-forward merge できる。    

Slide 100

Slide 100 text

Git の基礎  100 要望の多かったrebaseについて   rebaseでできることその１  ● ブランチの分岐元を変更する           developブランチを、最新のmasterから分岐したことにする。   こうすると、masterにマージする際に fast-forward merge できる。   pushしてからだとややこしいことになる可能性もあるので、やるならpush前のブランチの方が良いかも    

Slide 101

Slide 101 text

Git の基礎  101 要望の多かったrebaseについて   rebaseでできることその２ 

Slide 102

Slide 102 text

Git の基礎  102 要望の多かったrebaseについて   rebaseでできることその２  ● コミット履歴の修正（-iオプション）   ○ コミットの並び替え  ○ いくつかのコミットを一つに合体   ○ コミットメッセージを変更  ○ 過去のコミットに戻って修正  

Slide 103

Slide 103 text

Git の基礎  103 要望の多かったrebaseについて   rebaseでできることその２  ● コミット履歴の修正（-iオプション）   ○ コミットの並び替え  ○ いくつかのコミットを一つに合体   ○ コミットメッセージを変更  ○ 過去のコミットに戻って修正   $ git rebase -i HEAD~3 # 修正を行うコミットと修正コマンドを選ぶ。コミットごとに修正が完了したら以下 $ git rebase --continue # 全て修正が終わったら完了

Slide 104

Slide 104 text

Git の基礎  104 $ git rebase -i HEAD~3 1 pick 2ff810a 2st commit 2 pick 80e4e22 3rd commit 3 pick 6bb05cb 4th commit 4 5 # Rebase 17c2008..6bb05cb onto 17c2008 (3 commands) 6 # 7 # Commands: 8 # p, pick = use commit 9 # r, reword = use commit, but edit the commit message 10 # e, edit = use commit, but stop for amending 11 # s, squash = use commit, but meld into previous commit 12 # f, fixup = like "squash", but discard this commit's log message 13 # x, exec = run command (the rest of the line) using shell 14 # b, break = stop here (continue rebase later with 'git rebase --continue') 15 # d, drop = remove commit 16 # l, label = label current HEAD with a name 17 # t, reset = reset HEAD to a label ・・・

Slide 105

Slide 105 text

Git の基礎  105 $ git rebase -i HEAD~3 1 pick 2ff810a 2st commit 2 pick 80e4e22 3rd commit 3 pick 6bb05cb 4th commit 4 5 # Rebase 17c2008..6bb05cb onto 17c2008 (3 commands) 6 # 7 # Commands: 8 # p, pick = use commit 9 # r, reword = use commit, but edit the commit message 10 # e, edit = use commit, but stop for amending 11 # s, squash = use commit, but meld into previous commit 12 # f, fixup = like "squash", but discard this commit's log message 13 # x, exec = run command (the rest of the line) using shell 14 # b, break = stop here (continue rebase later with 'git rebase --continue') 15 # d, drop = remove commit 16 # l, label = label current HEAD with a name 17 # t, reset = reset HEAD to a label ・・・ここ目的のコマンドに変更する

Slide 106

Slide 106 text

bisectについて            Git の基礎  106

Slide 107

Slide 107 text

bisectについて  バグが混入したコミットを二分探索で効率的に特定するためのコマンド             Git の基礎  107

Slide 108

Slide 108 text

bisectについて  バグが混入したコミットを二分探索で効率的に特定するためのコマンド                       Git の基礎  108 $ git bisect start #チェックアウトした時点でテスト実行、もしくは動作確認 $ git bisect good (もしくは git bisect bad) #次の版にチェックアウト 1st commit   2nd commit   3rd commit   4th commit   5th commit   6th commit   7th commit   8th commit   9th commit   bad good checkout

Slide 109

Slide 109 text

bisectについて  バグが混入したコミットを二分探索で効率的に特定するためのコマンド               チェックは自動化させることも可         Git の基礎  109 $ git bisect start #チェックアウトした時点でテスト実行、もしくは動作確認 $ git bisect good (もしくは git bisect bad) #次の版にチェックアウト 1st commit   2nd commit   3rd commit   4th commit   5th commit   6th commit   7th commit   8th commit   9th commit   bad good checkout $ git bisect start $ git bisect run <テストスクリプトのファイル名 >

Slide 110

Slide 110 text

submoduleについて            Git の基礎  110

Slide 111

Slide 111 text

submoduleについて  あるプロジェクトから、別のプロジェクトを使用する必要がある時に使用             Git の基礎  111

Slide 112

Slide 112 text

submoduleについて  あるプロジェクトから、別のプロジェクトを使用する必要がある時に使用   ● サードパーティが開発したモジュール           Git の基礎  112

Slide 113

Slide 113 text

submoduleについて  あるプロジェクトから、別のプロジェクトを使用する必要がある時に使用   ● サードパーティが開発したモジュール   ● 複数のリポジトリから使われる共通モジュール             Git の基礎  113

Slide 114

Slide 114 text

submoduleについて  あるプロジェクトから、別のプロジェクトを使用する必要がある時に使用   ● サードパーティが開発したモジュール   ● 複数のリポジトリから使われる共通モジュール               Git の基礎  114 $ git submodule add https://github.com/chaconinc/DbConnector $ git status On branch master Your branch is up-to-date with 'origin/master'. Changes to be committed: (use "git reset HEAD ..." to unstage) new file: .gitmodules new file: DbConnector $ git submodule status # submoduleのどのコミットハッシュを参照しているか確認できる

Slide 115

Slide 115 text

submoduleについて  あるプロジェクトから、別のプロジェクトを使用する必要がある時に使用   ● サードパーティが開発したモジュール   ● 複数のリポジトリから使われる共通モジュール               Git の基礎  115 $ git submodule add https://github.com/chaconinc/DbConnector $ git status On branch master Your branch is up-to-date with 'origin/master'. Changes to be committed: (use "git reset HEAD ..." to unstage) new file: .gitmodules new file: DbConnector $ git submodule status # submoduleのどのコミットハッシュを参照しているか確認できる個人的にはパッケージングできるならその方が好み

Slide 116

Slide 116 text

一旦休憩 5 分くらい  116 shumon.fujita 

Slide 117

Slide 117 text

Git によるチーム開発のいろは  117 shumon.fujita 

Slide 118

Slide 118 text

Git 誕生秘話  チーム開発の話をする前に、なぜこの世に Git が存在するかご存知ですか       118 shumon.fujita 

Slide 119

Slide 119 text

Git 誕生秘話  チーム開発の話をする前に、なぜこの世に Git が存在するかご存知ですか   → Linux を開発するため      119 shumon.fujita 

Slide 120

Slide 120 text

Git 誕生秘話  チーム開発の話をする前に、なぜこの世に Git が存在するかご存知ですか   → Linux を開発するため    もともと Linux はメーリスに投稿されたパッチを、気合いで適用しながら開発していた     120 shumon.fujita 

Slide 121

Slide 121 text

Git 誕生秘話  チーム開発の話をする前に、なぜこの世に Git が存在するかご存知ですか   → Linux を開発するため    もともと Linux はメーリスに投稿されたパッチを、気合いで適用しながら開発していた   → 2002 年、「BitKeeper」という有料の VCS を無料で使わせてもらえることになった     121 shumon.fujita 

Slide 122

Slide 122 text

Slide 123

Slide 123 text

Slide 124

Slide 124 text

Git 誕生秘話  チーム開発の話をする前に、なぜこの世に Git が存在するかご存知ですか   → Linux を開発するため    もともと Linux はメーリスに投稿されたパッチを、気合いで適用しながら開発していた   → 2002 年、「BitKeeper」という有料の VCS を無料で使わせてもらえることになった   → 2005 年、なんやかんやあって、あくまで厚意で無料で使えていただけの BitKeeper を有料化されてしまった   → 他の VCS を探す必要がある   → 他の VCS は Linux ぐらいデカいプロジェクトを扱うには遅すぎるし、開発者が大勢いる状態に対応できない     124 shumon.fujita 

Slide 125

Slide 125 text

Slide 126

Slide 126 text

Slide 127

Slide 127 text

Git 誕生秘話  それから 2 週間すぎたころ  BitKeeper の流れを汲んだ高速な VCS  Git  が誕生しました  127 shumon.fujita 

Slide 128

Slide 128 text

Git の特徴  というわけで、Git には Linux 並にデカいソフトウェアを大人数で開発するために生まれた。       128 shumon.fujita 

Slide 129

Slide 129 text

Git の特徴  というわけで、Git には Linux 並にデカいソフトウェアを大人数で開発するために生まれた。     その結果、Git 以前の VCS に比べて次のような特徴がある。   - 高速な merge と checkout   - 分散型  - branch  129 shumon.fujita 

Slide 130

Slide 130 text

高速な merge と checkout  Git の merge と checkout は、実はかなり高速       130 shumon.fujita 

Slide 131

Slide 131 text

高速な merge と checkout  Git の merge と checkout は、実はかなり高速   特に、「履歴の遠さ」は merge や checkout の時間に影響を与えない      131 shumon.fujita 

Slide 132

Slide 132 text

高速な merge と checkout  Git の merge と checkout は、実はかなり高速   特に、「履歴の遠さ」は merge や checkout の時間に影響を与えない  変更されているファイルの数が支配的なのが特徴      132 shumon.fujita 

Slide 133

Slide 133 text

高速な merge と checkout  Git の merge と checkout は、実はかなり高速   特に、「履歴の遠さ」は merge や checkout の時間に影響を与えない  変更されているファイルの数が支配的なのが特徴    → 理由は後述の Git の内部構造を聞くと分かります   133 shumon.fujita 

Slide 134

Slide 134 text

分散型  Git の解説で毎回聞くやつ。         134 shumon.fujita 

Slide 135

Slide 135 text

分散型  Git の解説で毎回聞くやつ。     世の中のVCS(バージョン管理システム/Version Control System)には大きく分けて集中型と分散型の2つがある。       135 shumon.fujita 

Slide 136

Slide 136 text

分散型  Git の解説で毎回聞くやつ。     世の中のVCS(バージョン管理システム/Version Control System)には大きく分けて集中型と分散型の2つがある。   分散型のVCSは「リポジトリの全履歴を含めた完全なコピーをローカルに持つ」という意味。      136 shumon.fujita 

Slide 137

Slide 137 text

Slide 138

Slide 138 text

Slide 139

Slide 139 text

分散型  Git の解説で毎回聞くやつ。     世の中のVCS(バージョン管理システム/Version Control System)には大きく分けて集中型と分散型の2つがある。   分散型のVCSは「リポジトリの全履歴を含めた完全なコピーをローカルに持つ」という意味。    例えば集中型のSubversionは、リポジトリは完全にサーバが管理してる。   自分が触りたいファイルだけをローカルにコピーし、修正後サーバにpushする。   その間は他人は自分が使ってるファイルを編集することはできない。     139 shumon.fujita 

Slide 140

Slide 140 text

Slide 141

Slide 141 text

Slide 142

Slide 142 text

branch  Git は branch 機能のおかげで、大人数で並行して開発を進めることができる。           142 shumon.fujita 

Slide 143

Slide 143 text

branch  Git は branch 機能のおかげで、大人数で並行して開発を進めることができる。   でも無秩序に branch を使うとコンフリクトしまくるし、どこでどの機能が実装されているのか分からない。         143 shumon.fujita 

Slide 144

Slide 144 text

branch  Git は branch 機能のおかげで、大人数で並行して開発を進めることができる。   でも無秩序に branch を使うとコンフリクトしまくるし、どこでどの機能が実装されているのか分からない。   → 複雑なコンフリクトの仕方をすると、解消に失敗してバグが混入するかも。       144 shumon.fujita 

Slide 145

Slide 145 text

branch  Git は branch 機能のおかげで、大人数で並行して開発を進めることができる。   でも無秩序に branch を使うとコンフリクトしまくるし、どこでどの機能が実装されているのか分からない。   → 複雑なコンフリクトの仕方をすると、解消に失敗してバグが混入するかも。   → どの branch にどの機能が実装されているか分からないので、最新版がどれなのか分からない。     145 shumon.fujita 

Slide 146

Slide 146 text

Slide 147

Slide 147 text

Git Flow  147 shumon.fujita 

Slide 148

Slide 148 text

Git Flow  Git では、おそらく最も一般的な branch 運用。       148 shumon.fujita 

Slide 149

Slide 149 text

Git Flow  Git では、おそらく最も一般的な branch 運用。   皆でリモートリポジトリを1つに決めて、Git を中央集権的に扱えるようにした。       149 shumon.fujita  https://nvie.com/posts/a-successful-git-branching-model/

Slide 150

Slide 150 text

Git Flow  Git では、おそらく最も一般的な branch 運用。   皆でリモートリポジトリを1つに決めて、Git を中央集権的に扱えるようにした。   → 集中型と分散型の良いとこ取りができる。       150 shumon.fujita  https://nvie.com/posts/a-successful-git-branching-model/

Slide 151

Slide 151 text

Git Flow  Git では、おそらく最も一般的な branch 運用。   皆でリモートリポジトリを1つに決めて、Git を中央集権的に扱えるようにした。   → 集中型と分散型の良いとこ取りができる。     大体のチームは、Git Flow をちょっとアレンジして使ってるんじゃないかな。     151 shumon.fujita  https://nvie.com/posts/a-successful-git-branching-model/

Slide 152

Slide 152 text

Git Flow  Git では、おそらく最も一般的な branch 運用。   皆でリモートリポジトリを1つに決めて、Git を中央集権的に扱えるようにした。   → 集中型と分散型の良いとこ取りができる。     大体のチームは、Git Flow をちょっとアレンジして使ってるんじゃないかな。   Git Flow という名前を知らなくても、慣習として Git Flow と同じようなことを   している人も多いと思う。  152 shumon.fujita  https://nvie.com/posts/a-successful-git-branching-model/

Slide 153

Slide 153 text

Git Flow  Git Flow では、まずリモートリポジトリを1つに決める必要がある。     153 shumon.fujita 

Slide 154

Slide 154 text

Git Flow  Git Flow では、まずリモートリポジトリを1つに決める必要がある。   GitHub なり GitLab なり BitBucket なりなんでもいい。ちなみに弊社では基本的にGitHub。     154 shumon.fujita 

Slide 155

Slide 155 text

Git Flow  Git Flow では、まずリモートリポジトリを1つに決める必要がある。   GitHub なり GitLab なり BitBucket なりなんでもいい。ちなみに弊社では基本的にGitHub。   とにかくそのリモートリポジトリを開発者同士で口裏を合わせて常に正とみなす。     155 shumon.fujita 

Slide 156

Slide 156 text

Slide 157

Slide 157 text

Git Flow  Git Flow では、まずリモートリポジトリを1つに決める必要がある。   GitHub なり GitLab なり BitBucket なりなんでもいい。ちなみに弊社では基本的にGitHub。   とにかくそのリモートリポジトリを開発者同士で口裏を合わせて常に正とみなす。     そんなの当たり前すぎて、逆にリモートリポジトリが複数ある状態なんて、よく分からない人もいるかも。   でも Git では、複数のリモートリポジトリを持つことができる。   157 shumon.fujita 

Slide 158

Slide 158 text

Slide 159

Slide 159 text

Slide 160

Slide 160 text

Git Flow - developとmaster  Git Flowで最も重要なのが、masterとdevelopの関係。   (去年 master じゃなくて main を使おうという動きがありましたが、原典は master を使っているのでこのまま行きます)       160 shumon.fujita  https://nvie.com/posts/a-successful-git-branching-model/

Slide 161

Slide 161 text

Git Flow - developとmaster  Git Flowで最も重要なのが、masterとdevelopの関係。   (去年 master じゃなくて main を使おうという動きがありましたが、原典は master を使っているのでこのまま行きます)     開発は develop で行い、 master はリリース時に初めて commit される。     161 shumon.fujita  https://nvie.com/posts/a-successful-git-branching-model/

Slide 162

Slide 162 text

Git Flow - developとmaster  Git Flowで最も重要なのが、masterとdevelopの関係。   (去年 master じゃなくて main を使おうという動きがありましたが、原典は master を使っているのでこのまま行きます)     開発は develop で行い、 master はリリース時に初めて commit される。   master の commit にはリリースごとに tag を打つ。     162 shumon.fujita  https://nvie.com/posts/a-successful-git-branching-model/

Slide 163

Slide 163 text

Git Flow - developとmaster  Git Flowで最も重要なのが、masterとdevelopの関係。   (去年 master じゃなくて main を使おうという動きがありましたが、原典は master を使っているのでこのまま行きます)     開発は develop で行い、 master はリリース時に初めて commit される。   master の commit にはリリースごとに tag を打つ。   masterの先頭が常にプロダクトの最新のリリースになる。     163 shumon.fujita  https://nvie.com/posts/a-successful-git-branching-model/

Slide 164

Slide 164 text

Git Flow - feature  ここから先は、全部 develop と master をサポートするための branch 。         164 shumon.fujita 

Slide 165

Slide 165 text

Git Flow - feature  ここから先は、全部 develop と master をサポートするための branch 。     feature は複数人で develop を開発するときに使う。       165 shumon.fujita  https://nvie.com/posts/a-successful-git-branching-model/

Slide 166

Slide 166 text

Git Flow - feature  ここから先は、全部 develop と master をサポートするための branch 。     feature は複数人で develop を開発するときに使う。   1機能ごとに develop から branch を切る。機能の開発が終われば develop に merge する。       166 shumon.fujita  https://nvie.com/posts/a-successful-git-branching-model/

Slide 167

Slide 167 text

Slide 168

Slide 168 text

Git Flow - feature  ここから先は、全部 develop と master をサポートするための branch 。     feature は複数人で develop を開発するときに使う。   1機能ごとに develop から branch を切る。機能の開発が終われば develop に merge する。   「1 機能 = 1 feature」ルールは守ろう。複数の機能にまたがる feature はデメリットが多い。   - どの機能がどの branch に入っているのか分かりにくい。       168 shumon.fujita  https://nvie.com/posts/a-successful-git-branching-model/

Slide 169

Slide 169 text

Git Flow - feature  ここから先は、全部 develop と master をサポートするための branch 。     feature は複数人で develop を開発するときに使う。   1機能ごとに develop から branch を切る。機能の開発が終われば develop に merge する。   「1 機能 = 1 feature」ルールは守ろう。複数の機能にまたがる feature はデメリットが多い。   - どの機能がどの branch に入っているのか分かりにくい。   - 差分が大きくなってコンフリクトしやすい。       169 shumon.fujita  https://nvie.com/posts/a-successful-git-branching-model/

Slide 170

Slide 170 text

Git Flow - feature  ここから先は、全部 develop と master をサポートするための branch 。     feature は複数人で develop を開発するときに使う。   1機能ごとに develop から branch を切る。機能の開発が終われば develop に merge する。   「1 機能 = 1 feature」ルールは守ろう。複数の機能にまたがる feature はデメリットが多い。   - どの機能がどの branch に入っているのか分かりにくい。   - 差分が大きくなってコンフリクトしやすい。   - revert する際は、機能単位で revert したいことがほとんど。       170 shumon.fujita  https://nvie.com/posts/a-successful-git-branching-model/

Slide 171

Slide 171 text

Git Flow - feature  ここから先は、全部 develop と master をサポートするための branch 。     feature は複数人で develop を開発するときに使う。   1機能ごとに develop から branch を切る。機能の開発が終われば develop に merge する。   「1 機能 = 1 feature」ルールは守ろう。複数の機能にまたがる feature はデメリットが多い。   - どの機能がどの branch に入っているのか分かりにくい。   - 差分が大きくなってコンフリクトしやすい。   - revert する際は、機能単位で revert したいことがほとんど。     大きい機能の場合は feature からさらに feature を切ったりもする。     171 shumon.fujita  https://nvie.com/posts/a-successful-git-branching-model/

Slide 172

Slide 172 text

Git Flow - feature  ここから先は、全部 develop と master をサポートするための branch 。     feature は複数人で develop を開発するときに使う。   1機能ごとに develop から branch を切る。機能の開発が終われば develop に merge する。   「1 機能 = 1 feature」ルールは守ろう。複数の機能にまたがる feature はデメリットが多い。   - どの機能がどの branch に入っているのか分かりにくい。   - 差分が大きくなってコンフリクトしやすい。   - revert する際は、機能単位で revert したいことがほとんど。     大きい機能の場合は feature からさらに feature を切ったりもする。   概念実証のような、最終的に製品に入れるか分からないものもここ。   172 shumon.fujita  https://nvie.com/posts/a-successful-git-branching-model/

Slide 173

Slide 173 text

Git Flow - release  release は develop から master へ merge するための準備をする branch 。           173 shumon.fujita 

Slide 174

Slide 174 text

Git Flow - release  release は develop から master へ merge するための準備をする branch 。   チームによっては、staging という名前で呼んでるかも。           174 shumon.fujita 

Slide 175

Slide 175 text

Git Flow - release  release は develop から master へ merge するための準備をする branch 。   チームによっては、staging という名前で呼んでるかも。     具体的にどんな「準備」をするかは、プロジェクトによってまちまち         175 shumon.fujita 

Slide 176

Slide 176 text

Git Flow - release  release は develop から master へ merge するための準備をする branch 。   チームによっては、staging という名前で呼んでるかも。     具体的にどんな「準備」をするかは、プロジェクトによってまちまち   - 新規実装を凍結し、bugfix のみに使う         176 shumon.fujita 

Slide 177

Slide 177 text

Slide 178

Slide 178 text

Git Flow - release  release は develop から master へ merge するための準備をする branch 。   チームによっては、staging という名前で呼んでるかも。     具体的にどんな「準備」をするかは、プロジェクトによってまちまち   - 新規実装を凍結し、bugfix のみに使う   - version 表記やタイムスタンプを更新する   - Apple や Google の審査のために使う         178 shumon.fujita 

Slide 179

Slide 179 text

Slide 180

Slide 180 text

Git Flow - hotfix  hotfix は本番環境で発生したバグの内、緊急性の高いものを修正するための branch。       180 shumon.fujita  https://nvie.com/posts/a-successful-git-branching-model/

Slide 181

Slide 181 text

Git Flow - hotfix  hotfix は本番環境で発生したバグの内、緊急性の高いものを修正するための branch。     develop 以外で、唯一 master から切られる branch 。     181 shumon.fujita  https://nvie.com/posts/a-successful-git-branching-model/

Slide 182

Slide 182 text

Git Flow - hotfix  hotfix は本番環境で発生したバグの内、緊急性の高いものを修正するための branch。     develop 以外で、唯一 master から切られる branch 。   修正が完了したら master と develop (or release)に merge する。     182 shumon.fujita  https://nvie.com/posts/a-successful-git-branching-model/

Slide 183

Slide 183 text

Git Flow - hotfix  hotfix は本番環境で発生したバグの内、緊急性の高いものを修正するための branch。     develop 以外で、唯一 master から切られる branch 。   修正が完了したら master と develop (or release)に merge する。     hotfix から master を更新した場合は、patch バージョンを上げることが多い。   (1.2 → 1.3 ではなく、1.2 → 1.2.1)   183 shumon.fujita  https://nvie.com/posts/a-successful-git-branching-model/

Slide 184

Slide 184 text

Git Flow  ここまでの話を全部まとめると、右の図になる。           184 shumon.fujita  https://nvie.com/posts/a-successful-git-branching-model/

Slide 185

Slide 185 text

Git Flow  ここまでの話を全部まとめると、右の図になる。     前述の通り、大体のチームでは Git Flowをそのままではなく、         185 shumon.fujita  https://nvie.com/posts/a-successful-git-branching-model/

Slide 186

Slide 186 text

Git Flow  ここまでの話を全部まとめると、右の図になる。     前述の通り、大体のチームでは Git Flowをそのままではなく、   ちょっとアレンジして使っていると思う。         186 https://nvie.com/posts/a-successful-git-branching-model/

Slide 187

Slide 187 text

Git Flow  ここまでの話を全部まとめると、右の図になる。     前述の通り、大体のチームでは Git Flowをそのままではなく、   ちょっとアレンジして使っていると思う。     他にもGitHub Flowとか、トランクベース開発などの手法もある。         187 https://nvie.com/posts/a-successful-git-branching-model/

Slide 188

Slide 188 text

Git Flow  ここまでの話を全部まとめると、右の図になる。     前述の通り、大体のチームでは Git Flowをそのままではなく、   ちょっとアレンジして使っていると思う。     他にもGitHub Flowとか、トランクベース開発などの手法もある。     組織やリポジトリの特性などから適したものを選んで行ってください。         188 https://nvie.com/posts/a-successful-git-branching-model/

Slide 189

Slide 189 text

GitHub について  189 shumon.fujita 

Slide 190

Slide 190 text

GitHub について  Git 単体で使うのではなく、リポジトリホスティングサービスと併用することで Git は真価を発揮する。           190 shumon.fujita 

Slide 191

Slide 191 text

GitHub について  Git 単体で使うのではなく、リポジトリホスティングサービスと併用することで Git は真価を発揮する。   弊社では GitHub を使っているので、GitHub の機能について話します。           191 shumon.fujita 

Slide 192

Slide 192 text

GitHub について  Git 単体で使うのではなく、リポジトリホスティングサービスと併用することで Git は真価を発揮する。   弊社では GitHub を使っているので、GitHub の機能について話します。     GitHub は Git をチームで使うにあたって便利な機能がいっぱい入っている         192 shumon.fujita 

Slide 193

Slide 193 text

GitHub について  Git 単体で使うのではなく、リポジトリホスティングサービスと併用することで Git は真価を発揮する。   弊社では GitHub を使っているので、GitHub の機能について話します。     GitHub は Git をチームで使うにあたって便利な機能がいっぱい入っている   基本的な機能はリポジトリのトップページのタブでまとめられている。         193 shumon.fujita 

Slide 194

Slide 194 text

Slide 195

Slide 195 text

Slide 196

Slide 196 text

Issue について  気になったことをなんでもMarkdownで書いておくところ。     196 shumon.fujita 

Slide 197

Slide 197 text

Issue について  気になったことをなんでもMarkdownで書いておくところ。   (実際の運用はチームによるけど大体のところは何書いても良いと思う)     197 shumon.fujita 

Slide 198

Slide 198 text

Issue について  気になったことをなんでもMarkdownで書いておくところ。   (実際の運用はチームによるけど大体のところは何書いても良いと思う)   ここに実タスクを並べて、後述の Projectsで管理するチームもあれば、    198 shumon.fujita 

Slide 199

Slide 199 text

Slide 200

Slide 200 text

Issue について  気になったことをなんでもMarkdownで書いておくところ。   (実際の運用はチームによるけど大体のところは何書いても良いと思う)   ここに実タスクを並べて、後述の Projectsで管理するチームもあれば、  「テストが遅いから改善したい」とか「あの負債をどうやって解消しよう」とかの   相談事を書いて議論の土台にするチームもある。  ラベルをつけて、種類別に整理しやすくしたり、    200 shumon.fujita 

Slide 201

Slide 201 text

Slide 202

Slide 202 text

Slide 203

Slide 203 text

Slide 204

Slide 204 text

Pull Request について  GitHub 関連の機能で一番重要。         204 shumon.fujita 

Slide 205

Slide 205 text

Pull Request について  GitHub 関連の機能で一番重要。     特定の branch や、fork 元のリポジトリに、「私がやった作業を取り込んでくれ」とお願いを出せる機能。       205 shumon.fujita 

Slide 206

Slide 206 text

Pull Request について  GitHub 関連の機能で一番重要。     特定の branch や、fork 元のリポジトリに、「私がやった作業を取り込んでくれ」とお願いを出せる機能。   → 元々は fork 元のリポジトリにお願いする機能なので “Merge Request” ではなく “Pull Request”      206 shumon.fujita 

Slide 207

Slide 207 text

Pull Request について  GitHub 関連の機能で一番重要。     特定の branch や、fork 元のリポジトリに、「私がやった作業を取り込んでくれ」とお願いを出せる機能。   → 元々は fork 元のリポジトリにお願いする機能なので “Merge Request” ではなく “Pull Request”    お願いされた側は取り込む前に差分をよく吟味し、大丈夫そうなら merge して差分を取り込む。     207 shumon.fujita 

Slide 208

Slide 208 text

Slide 209

Slide 209 text

Slide 210

Slide 210 text

PR を出す側の注意点  210 shumon.fujita 

Slide 211

Slide 211 text

PR を出す側の注意点  - できるだけ細かい単位で PR を出すよう心がける   211 shumon.fujita 

Slide 212

Slide 212 text

PR を出す側の注意点  - できるだけ細かい単位で PR を出すよう心がける   - 巨大 PR はレビューに時間がかかる   212 shumon.fujita 

Slide 213

Slide 213 text

PR を出す側の注意点  - できるだけ細かい単位で PR を出すよう心がける   - 巨大 PR はレビューに時間がかかる   - レビューに時間がかかると merge までの時間も当然伸びる   213 shumon.fujita 

Slide 214

Slide 214 text

PR を出す側の注意点  - できるだけ細かい単位で PR を出すよう心がける   - 巨大 PR はレビューに時間がかかる   - レビューに時間がかかると merge までの時間も当然伸びる   - 別の PR がどんどん先に merge されていく     214 shumon.fujita 

Slide 215

Slide 215 text

PR を出す側の注意点  - できるだけ細かい単位で PR を出すよう心がける   - 巨大 PR はレビューに時間がかかる   - レビューに時間がかかると merge までの時間も当然伸びる   - 別の PR がどんどん先に merge されていく   - その結果コンフリクトする  215 shumon.fujita 

Slide 216

Slide 216 text

PR を出す側の注意点  - できるだけ細かい単位で PR を出すよう心がける   - 巨大 PR はレビューに時間がかかる   - レビューに時間がかかると merge までの時間も当然伸びる   - 別の PR がどんどん先に merge されていく   - その結果コンフリクトする  - さらにコンフリクトの解消に失敗してバグるかも     216 shumon.fujita 

Slide 217

Slide 217 text

Slide 218

Slide 218 text

Slide 219

Slide 219 text

Slide 220

Slide 220 text

PR を出す側の注意点  - できるだけ細かい単位で PR を出すよう心がける   - 巨大 PR はレビューに時間がかかる   - レビューに時間がかかると merge までの時間も当然伸びる   - 別の PR がどんどん先に merge されていく   - その結果コンフリクトする  - さらにコンフリクトの解消に失敗してバグるかも   - 巨大にならざるをえないときは、途中でレビューしてもらう   - Git Flow で少し話をした、feature から feature を切るテク   - 最初の feature には WIP をタイトルに付けたり、draft PR として出したりすると ○   - コミットログはできるだけ綺麗にしておこう     220 shumon.fujita 

Slide 221

Slide 221 text

Slide 222

Slide 222 text

Slide 223

Slide 223 text

Slide 224

Slide 224 text

PR を見る側の注意点  224 shumon.fujita 

Slide 225

Slide 225 text

PR を見る側の注意点  - 機械的にチェックできる部分は CI に任せる   225 shumon.fujita 

Slide 226

Slide 226 text

PR を見る側の注意点  - 機械的にチェックできる部分は CI に任せる   - テストはしっかり書こうね    226 shumon.fujita 

Slide 227

Slide 227 text

PR を見る側の注意点  - 機械的にチェックできる部分は CI に任せる   - テストはしっかり書こうね  - コードフォーマッタを使うと、細かいスペースの差分とかが生まれなくて便利   227 shumon.fujita 

Slide 228

Slide 228 text

PR を見る側の注意点  - 機械的にチェックできる部分は CI に任せる   - テストはしっかり書こうね  - コードフォーマッタを使うと、細かいスペースの差分とかが生まれなくて便利   - 人間が見るべきポイントにしっかり集中する   228 shumon.fujita 

Slide 229

Slide 229 text

PR を見る側の注意点  - 機械的にチェックできる部分は CI に任せる   - テストはしっかり書こうね  - コードフォーマッタを使うと、細かいスペースの差分とかが生まれなくて便利   - 人間が見るべきポイントにしっかり集中する   - 仕様の穴、セキュリティ/法的にヤバそうなところ     229 shumon.fujita 

Slide 230

Slide 230 text

Slide 231

Slide 231 text

Slide 232

Slide 232 text

Slide 233

Slide 233 text

Slide 234

Slide 234 text

PR を見る側の注意点  - 機械的にチェックできる部分は CI に任せる   - テストはしっかり書こうね  - コードフォーマッタを使うと、細かいスペースの差分とかが生まれなくて便利   - 人間が見るべきポイントにしっかり集中する   - 仕様の穴、セキュリティ/法的にヤバそうなところ   - 負債になりそうなところ、設計的にまずいところ、計算量・レイテンシ的に厳しいところ   - 意外と実装中に気づかなかった問題点が見つかることも多いので、自分のPRもレビューしておくと吉   - なかなか人間の目ではバグは見つかりません！高品質なコードは高品質なテストから   - 実装者のことを思いやる  - 「このコードは良くない」のような抽象的な言い方はやめて、どこがどういう理由で良くないのか書く   234 shumon.fujita 

Slide 235

Slide 235 text

Slide 236

Slide 236 text

Slide 237

Slide 237 text

Slide 238

Slide 238 text

Slide 239

Slide 239 text

Actions について  GitHub が提供している CI/CD 環境。       239 shumon.fujita 

Slide 240

Slide 240 text

Actions について  GitHub が提供している CI/CD 環境。   他のサービスと連携させる必要がないので、簡単に使える + パブリックリポジトリでは無料で使える点がメリット。       240 shumon.fujita 

Slide 241

Slide 241 text

Actions について  GitHub が提供している CI/CD 環境。   他のサービスと連携させる必要がないので、簡単に使える + パブリックリポジトリでは無料で使える点がメリット。   また、汎用的な部分は GitHub で公開されている Action を利用することができることもありがたい。       241 shumon.fujita 

Slide 242

Slide 242 text

Actions について  GitHub が提供している CI/CD 環境。   他のサービスと連携させる必要がないので、簡単に使える + パブリックリポジトリでは無料で使える点がメリット。   また、汎用的な部分は GitHub で公開されている Action を利用することができることもありがたい。     hook したいイベントとワークフローを書いた yaml を .github/workflows/ に配置すると、勝手に走ってくれる。     242 shumon.fujita 

Slide 243

Slide 243 text

Slide 244

Slide 244 text

Slide 245

Slide 245 text

Projects について  カンバンスタイルのタスク管理ツール。           245 shumon.fujita 

Slide 246

Slide 246 text

Projects について  カンバンスタイルのタスク管理ツール。   アジャイルとかスクラム開発でよく使う。           246 shumon.fujita 

Slide 247

Slide 247 text

Projects について  カンバンスタイルのタスク管理ツール。   アジャイルとかスクラム開発でよく使う。       issue や PR を付箋のようにタブを移動   させて進捗状況を可視化できる。       247 shumon.fujita 

Slide 248

Slide 248 text

Projects について  カンバンスタイルのタスク管理ツール。   アジャイルとかスクラム開発でよく使う。       issue や PR を付箋のようにタブを移動   させて進捗状況を可視化できる。     機能も少ないため、実際にはあまり使っている部署はないかも（？）       248 shumon.fujita 

Slide 249

Slide 249 text

Projects について  カンバンスタイルのタスク管理ツール。   アジャイルとかスクラム開発でよく使う。       issue や PR を付箋のようにタブを移動   させて進捗状況を可視化できる。     機能も少ないため、実際にはあまり使っている部署はないかも（？）   ZenHubという有料拡張ツールつかうとかなり便利になる。     249 shumon.fujita 

Slide 250

Slide 250 text

Wiki について  いわゆる Wiki を究極にシンプルにしたやつ。           250 shumon.fujita 

Slide 251

Slide 251 text

Wiki について  いわゆる Wiki を究極にシンプルにしたやつ。   基本的にチームメンバーが自由に記事を追加・編集・削除できるだけの機能。           251 shumon.fujita 

Slide 252

Slide 252 text

Wiki について  いわゆる Wiki を究極にシンプルにしたやつ。   基本的にチームメンバーが自由に記事を追加・編集・削除できるだけの機能。     機能がかなり貧弱なので、ちゃんと運用してるチームは多分あんまりないんじゃないかなと思う。   docbase 契約してるので、docbase で良さそう...   252 shumon.fujita 

Slide 253

Slide 253 text

Security について  主に↓の 3 つの機能についてのあれこれをするタブ。   - Security Policy  - Security Advisories  - Dependabot          253 shumon.fujita 

Slide 254

Slide 254 text

Security について  主に↓の 3 つの機能についてのあれこれをするタブ。   - Security Policy  - Security Advisories  - Dependabot    Security Policy は脆弱性報告の手順を Markdown で書いておく。         254 shumon.fujita 

Slide 255

Slide 255 text

Slide 256

Slide 256 text

Security について  主に↓の 3 つの機能についてのあれこれをするタブ。   - Security Policy  - Security Advisories  - Dependabot    Security Policy は脆弱性報告の手順を Markdown で書いておく。   Security Advisories は非公開の issue のようなもので、脆弱性が対策されるまでは秘匿した状態で議論し、   対応パッチがリリースされると、その議論を公開できる。   Dependabot はコードから依存パッケージのバージョンを解析して、脆弱性があればアラートを飛ばしてくれる。       256 shumon.fujita 

Slide 257

Slide 257 text

Slide 258

Slide 258 text

Insights について  リポジトリの活発度を色々な指標で確認できる場所。           258 shumon.fujita 

Slide 259

Slide 259 text

Insights について  リポジトリの活発度を色々な指標で確認できる場所。     時系列でコミット数や差分の量がグラフ化されていたり、リポジトリの色々な統計情報が見られる。         259 shumon.fujita 

Slide 260

Slide 260 text

Insights について  リポジトリの活発度を色々な指標で確認できる場所。     時系列でコミット数や差分の量がグラフ化されていたり、リポジトリの色々な統計情報が見られる。     自分のリポジトリでこのタブを使うことはあんまりない。       260 shumon.fujita 

Slide 261

Slide 261 text

Insights について  リポジトリの活発度を色々な指標で確認できる場所。     時系列でコミット数や差分の量がグラフ化されていたり、リポジトリの色々な統計情報が見られる。     自分のリポジトリでこのタブを使うことはあんまりない。     新しいライブラリやツールの導入を検討しているとき、それが GitHub でホストされているならこのタブを見ると、   どれくらいメンテされているのかが一目瞭然なので、ぜひ使ってみてね。   261 shumon.fujita 

Slide 262

Slide 262 text

Settings について  リポジトリの設定を変えるタブ(それはそう)           262 shumon.fujita 

Slide 263

Slide 263 text

Settings について  リポジトリの設定を変えるタブ(それはそう)     各種機能の on/off や、Secretsの登録、デフォルトブランチの変更、PRのマージに関するルールの設定など色々できる。         263 shumon.fujita 

Slide 264

Slide 264 text

Settings について  リポジトリの設定を変えるタブ(それはそう)     各種機能の on/off や、Secretsの登録、デフォルトブランチの変更、PRのマージに関するルールの設定など色々できる。     おそらく開発中に最もよく使うのは Branch protection rules。      264 shumon.fujita 

Slide 265

Slide 265 text

Slide 266

Slide 266 text

Settings について  リポジトリの設定を変えるタブ(それはそう)     各種機能の on/off や、Secretsの登録、デフォルトブランチの変更、PRのマージに関するルールの設定など色々できる。     おそらく開発中に最もよく使うのは Branch protection rules。  指定した正規表現にマッチした branch に対して、PR を経ない直接の push や force push を禁止したり...etc   master(main) と develop には、大体なんらかのルールが設定されていると思う。       266 shumon.fujita 

Slide 267

Slide 267 text

Slide 268

Slide 268 text

Git の内部構造  268 shumon.fujita 

Slide 269

Slide 269 text

Git の内部構造  ついにきました本日のメインです。   ここからの話が理解できれば Git の 5 割ぐらいは自作できます。   目指せ Git マスター。  269 shumon.fujita 

Slide 270

Slide 270 text

Git の内部構造  Git をよく使っていても、実は全然 Git のことを理解できていない     - commit って親 commit との差分を保存してるんでしょ  - branch って分かれた枝のことでしょ  - reset って commit をなかったことにするコマンドでしょ      270 shumon.fujita 

Slide 271

Slide 271 text

Git の内部構造  Git をよく使っていても、実は全然 Git のことを理解できていない     - commit って親 commit との差分を保存してるんでしょ  - branch って分かれた枝のことでしょ  - reset って commit をなかったことにするコマンドでしょ    ↑は全部間違い    271 shumon.fujita 

Slide 272

Slide 272 text

Git の内部構造  Git をよく使っていても、実は全然 Git のことを理解できていない     - commit って親 commit との差分を保存してるんでしょ  - branch って分かれた枝のことでしょ  - reset って commit をなかったことにするコマンドでしょ    ↑は全部間違い  自分も学生時代は勘違いしたまま使ってた     272 shumon.fujita 

Slide 273

Slide 273 text

Git の内部構造  Git をよく使っていても、実は全然 Git のことを理解できていない     - commit って親 commit との差分を保存してるんでしょ  - branch って分かれた枝のことでしょ  - reset って commit をなかったことにするコマンドでしょ    ↑は全部間違い  自分も学生時代は勘違いしたまま使ってた   ここからの話を聞けば「reset や rebase 叩くときは毎回検索してコピペしてる」みたいな状況を脱せるはず   273 shumon.fujita 

Slide 274

Slide 274 text

Git の内部構造  特に↓について詳しく処理を追っていく。   - コミットの仕組み  - checkout, reset の仕組み   274 shumon.fujita 

Slide 275

Slide 275 text

コミットの仕組み  275 shumon.fujita 

Slide 276

Slide 276 text

276 Git を使っていると、大きく3つの段階を踏んで commit する   コミットの仕組み  shumon.fujita 

Slide 277

Slide 277 text

277 Git を使っていると、大きく3つの段階を踏んで commit する   1. コードを編集する  2. 編集したコードを add する   3. commit する    コミットの仕組み  shumon.fujita 

Slide 278

Slide 278 text

278 Git を使っていると、大きく3つの段階を踏んで commit する   1. コードを編集する  2. 編集したコードを add する   3. commit する  2 と 3 のときに、Git 内部で一体何が起こっているのかを追っていく     コミットの仕組み  shumon.fujita 

Slide 279

Slide 279 text

こんなリポジトリを用意して実験してみる。     $ tree . └── README.md 0 directories, 1 file   ルートに README.md があるだけ。   279 コミットの仕組み  shumon.fujita 

Slide 280

Slide 280 text

編集したコードを add すると、内部的には何が起こっているのか       280 コミットの仕組み  shumon.fujita 

Slide 281

Slide 281 text

編集したコードを add すると、内部的には何が起こっているのか   → 教科書的な回答は「コミットに含めたいファイルを index に登録している」       281 コミットの仕組み  shumon.fujita 

Slide 282

Slide 282 text

編集したコードを add すると、内部的には何が起こっているのか   → 教科書的な回答は「コミットに含めたいファイルを index に登録している」     具体的に index はどこにあるかというと、.git/index に保存されている。     282 コミットの仕組み  shumon.fujita 

Slide 283

Slide 283 text

編集したコードを add すると、内部的には何が起こっているのか   → 教科書的な回答は「コミットに含めたいファイルを index に登録している」     具体的に index はどこにあるかというと、.git/index に保存されている。   とりあえず cat してみる。  $ cat .git/index DIRC`m�� \D�`m�� \D��_A��S]:7��U��W��V�9� README.mdTREE1 0 Z�� c�ؤ�c$-�Y�T1`^:qȋ�r��g�p;��T��   283 コミットの仕組み  shumon.fujita 

Slide 284

Slide 284 text

編集したコードを add すると、内部的には何が起こっているのか   → 教科書的な回答は「コミットに含めたいファイルを index に登録している」     具体的に index はどこにあるかというと、.git/index に保存されている。   とりあえず cat してみる。バイナリファイルで文字化けしてるけど、それっぽい文字列が見える。   $ cat .git/index DIRC`m�� \D�`m�� \D��_A��S]:7��U��W��V�9� README.mdTREE1 0 Z�� c�ؤ�c$-�Y�T1`^:qȋ�r��g�p;��T��   284 コミットの仕組み  shumon.fujita 

Slide 285

Slide 285 text

index の中身を確認するコマンドがあるので、それで確認してみる。   285 コミットの仕組み  shumon.fujita 

Slide 286

Slide 286 text

index の中身を確認するコマンドがあるので、それで確認してみる。     $ git ls-files --stage     286 コミットの仕組み  shumon.fujita 

Slide 287

Slide 287 text

index の中身を確認するコマンドがあるので、それで確認してみる。     $ git ls-files --stage 100644 e2022389da0c18f0c8a0e2f9b27d58d197f41b32 0 README.md     287 コミットの仕組み  shumon.fujita 

Slide 288

Slide 288 text

index の中身を確認するコマンドがあるので、それで確認してみる。     $ git ls-files --stage 100644 e2022389da0c18f0c8a0e2f9b27d58d197f41b32 0 README.md     288 コミットの仕組み  shumon.fujita  ファイルの種類  +  パーミッション 

Slide 289

Slide 289 text

index の中身を確認するコマンドがあるので、それで確認してみる。     $ git ls-files --stage 100644 e2022389da0c18f0c8a0e2f9b27d58d197f41b32 0 README.md     289 コミットの仕組み  shumon.fujita  ファイルの種類  +  パーミッション  blob ハッシュ(後述)  

Slide 290

Slide 290 text

index の中身を確認するコマンドがあるので、それで確認してみる。     $ git ls-files --stage 100644 e2022389da0c18f0c8a0e2f9b27d58d197f41b32 0 README.md     290 コミットの仕組み  shumon.fujita  ファイルの種類  +  パーミッション  blob ハッシュ(後述)   コンフリクトフラグ  (0ならコンフリクトなし) 

Slide 291

Slide 291 text

index の中身を確認するコマンドがあるので、それで確認してみる。     $ git ls-files --stage 100644 e2022389da0c18f0c8a0e2f9b27d58d197f41b32 0 README.md     291 コミットの仕組み  shumon.fujita  ファイルの種類  +  パーミッション  blob ハッシュ(後述)   コンフリクトフラグ  (0ならコンフリクトなし)  ファイル名 

Slide 292

Slide 292 text

index の中身を確認するコマンドがあるので、それで確認してみる。     $ git ls-files --stage 100644 e2022389da0c18f0c8a0e2f9b27d58d197f41b32 0 README.md   ファイル名と一緒に何やら色んな情報が出てくる。     292 コミットの仕組み  shumon.fujita  ファイルの種類  +  パーミッション  blob ハッシュ(後述)   コンフリクトフラグ  (0ならコンフリクトなし)  ファイル名 

Slide 293

Slide 293 text

index の中身を確認するコマンドがあるので、それで確認してみる。     $ git ls-files --stage 100644 e2022389da0c18f0c8a0e2f9b27d58d197f41b32 0 README.md   ファイル名と一緒に何やら色んな情報が出てくる。     ちなみに index は、ここに表示されていない情報も持っている。   293 コミットの仕組み  shumon.fujita  ファイルの種類  +  パーミッション  blob ハッシュ(後述)   コンフリクトフラグ  (0ならコンフリクトなし)  ファイル名 

Slide 294

Slide 294 text

index の中身を確認するコマンドがあるので、それで確認してみる。     $ git ls-files --stage 100644 e2022389da0c18f0c8a0e2f9b27d58d197f41b32 0 README.md   ファイル名と一緒に何やら色んな情報が出てくる。     ちなみに index は、ここに表示されていない情報も持っている。   気になる人は --debug を付けると index が持ってる全情報を確認できる(詳しくは index-format.txt 参照)  294 コミットの仕組み  shumon.fujita  ファイルの種類  +  パーミッション  blob ハッシュ(後述)   コンフリクトフラグ  (0ならコンフリクトなし)  ファイル名 

Slide 295

Slide 295 text

295 blob ハッシュってなに？    コミットの仕組み  shumon.fujita 

Slide 296

Slide 296 text

296 blob ハッシュってなに？→ Git に管理されているオブジェクトの 1 種(の key) のこと。    コミットの仕組み  shumon.fujita 

Slide 297

Slide 297 text

297 blob ハッシュってなに？→ Git に管理されているオブジェクトの 1 種(の key) のこと。  Git には様々なデータを、「オブジェクト」と呼ばれる概念で表現している。     コミットの仕組み  shumon.fujita 

Slide 298

Slide 298 text

298 blob ハッシュってなに？→ Git に管理されているオブジェクトの 1 種(の key) のこと。  Git には様々なデータを、「オブジェクト」と呼ばれる概念で表現している。   オブジェクトには以下の 4 種類がある。   - commit オブジェクト  - コミットの情報が入っているオブジェクト   - tree オブジェクト  - ディレクトリの情報が入っているオブジェクト   - blob オブジェクト  - ファイルの情報が入っているオブジェクト   - tag オブジェクト  - annotated tag の情報が入っているオブジェクト       コミットの仕組み  shumon.fujita 

Slide 299

Slide 299 text

299 blob ハッシュってなに？→ Git に管理されているオブジェクトの 1 種(の key) のこと。  Git には様々なデータを、「オブジェクト」と呼ばれる概念で表現している。   オブジェクトには以下の 4 種類がある。   - commit オブジェクト  - コミットの情報が入っているオブジェクト   - tree オブジェクト  - ディレクトリの情報が入っているオブジェクト   - blob オブジェクト  - ファイルの情報が入っているオブジェクト   - tag オブジェクト  - annotated tag の情報が入っているオブジェクト       コミットの仕組み  shumon.fujita 

Slide 300

Slide 300 text

300 blob ハッシュってなに？→ Git に管理されているオブジェクトの 1 種(の key) のこと。  Git には様々なデータを、「オブジェクト」と呼ばれる概念で表現している。   オブジェクトには以下の 4 種類がある。   - commit オブジェクト  - コミットの情報が入っているオブジェクト   - tree オブジェクト  - ディレクトリの情報が入っているオブジェクト   - blob オブジェクト  - ファイルの情報が入っているオブジェクト   - tag オブジェクト  - annotated tag の情報が入っているオブジェクト       コミットの仕組み  shumon.fujita 

Slide 301

Slide 301 text

301 blob ハッシュってなに？→ Git に管理されているオブジェクトの 1 種(の key) のこと。  Git には様々なデータを、「オブジェクト」と呼ばれる概念で表現している。   オブジェクトには以下の 4 種類がある。   - commit オブジェクト  - コミットの情報が入っているオブジェクト   - tree オブジェクト  - ディレクトリの情報が入っているオブジェクト   - blob オブジェクト  - ファイルの情報が入っているオブジェクト（バックアップ）   - tag オブジェクト  - annotated tag の情報が入っているオブジェクト       コミットの仕組み  shumon.fujita 

Slide 302

Slide 302 text

302 blob ハッシュってなに？→ Git に管理されているオブジェクトの 1 種(の key) のこと。  Git には様々なデータを、「オブジェクト」と呼ばれる概念で表現している。   オブジェクトには以下の 4 種類がある。   - commit オブジェクト  - コミットの情報が入っているオブジェクト   - tree オブジェクト  - ディレクトリの情報が入っているオブジェクト   - blob オブジェクト  - ファイルの情報が入っているオブジェクト（バックアップ）   - tag オブジェクト  - annotated tag の情報が入っているオブジェクト       コミットの仕組み  shumon.fujita 

Slide 303

Slide 303 text

303 blob ハッシュってなに？→ Git に管理されているオブジェクトの 1 種(の key) のこと。  Git には様々なデータを、「オブジェクト」と呼ばれる概念で表現している。   オブジェクトには以下の 4 種類がある。   - commit オブジェクト  - コミットの情報が入っているオブジェクト   - tree オブジェクト  - ディレクトリの情報が入っているオブジェクト   - blob オブジェクト  - ファイルの情報が入っているオブジェクト（バックアップ）   - tag オブジェクト  - annotated tag の情報が入っているオブジェクト     ただしGit で扱うデータが全てオブジェクトなわけではない。例えば branch はオブジェクトで管理していない。   コミットの仕組み  shumon.fujita 

Slide 304

Slide 304 text

304 オブジェクトの実体は .git/objects の中に zlib で圧縮して保存されている。         コミットの仕組み  shumon.fujita 

Slide 305

Slide 305 text

305 オブジェクトの実体は .git/objects の中に zlib で圧縮して保存されている。     例えば、key が e2022389da0c18f0c8a0e2f9b27d58d197f41b32 のオブジェクトのパスは、   .git/objects/e2/022389da0c18f0c8a0e2f9b27d58d197f41b32 になる。      コミットの仕組み  shumon.fujita 

Slide 306

Slide 306 text

306 オブジェクトの実体は .git/objects の中に zlib で圧縮して保存されている。     例えば、key が e2022389da0c18f0c8a0e2f9b27d58d197f41b32 のオブジェクトのパスは、   .git/objects/e2/022389da0c18f0c8a0e2f9b27d58d197f41b32 になる。    このように、Git は一種の Key-Value Store としてオブジェクトを管理している。     コミットの仕組み  shumon.fujita 

Slide 307

Slide 307 text

README.md の blob (e2022389da0c18f0c8a0e2f9b27d58d197f41b32) の中身を確認してみる。   307 コミットの仕組み 

Slide 308

Slide 308 text

Slide 309

Slide 309 text

Slide 310

Slide 310 text

README.md の blob (e2022389da0c18f0c8a0e2f9b27d58d197f41b32) の中身を確認してみる。   $ cat README.md # 21 卒 Git 研修用リポジトリ $ cat .git/objects/e2/022389da0c18f0c8a0e2f9b27d58d197f41b32 | zlib d blob 38# 21 卒 Git 研修用リポジトリファイルの先頭に、オブジェクトの種類とファイルサイズを付けたものを、zlib で圧縮している事が分かる。   blobオブジェクトはファイルの差分ではなくファイルの中身そのものを記録している事も分かる。   310 コミットの仕組み 

Slide 311

Slide 311 text

Slide 312

Slide 312 text

Slide 313

Slide 313 text

各オブジェクトの中身を確認するには、自分で zlib で伸長してもいいけど、git cat-file を使えば簡単にできる。     313 コミットの仕組み  shumon.fujita 

Slide 314

Slide 314 text

各オブジェクトの中身を確認するには、自分で zlib で伸長してもいいけど、git cat-file を使えば簡単にできる。   $ git cat-file -p <オブジェクトハッシュ>   314 コミットの仕組み  shumon.fujita 

Slide 315

Slide 315 text

各オブジェクトの中身を確認するには、自分で zlib で伸長してもいいけど、git cat-file を使えば簡単にできる。   $ git cat-file -p <オブジェクトハッシュ> -p オプションを付けると、自動でオブジェクトの種類を判別して読みやすく整形して表示してくれる。   315 コミットの仕組み  shumon.fujita 

Slide 316

Slide 316 text

316 各オブジェクトの中身を確認するには、自分で zlib で伸長してもいいけど、git cat-file を使えば簡単にできる。   $ git cat-file -p <オブジェクトハッシュ> -p オプションを付けると、自動でオブジェクトの種類を判別して読みやすく整形して表示してくれる。     $ git cat-file -p e2022389da0c18f0c8a0e2f9b27d58d197f41b32 # 21 卒 Git 研修用リポジトリ   コミットの仕組み  shumon.fujita 

Slide 317

Slide 317 text

317 本題に戻って、編集したコードを add すると何が起こるのか。   $ git ls-files --stage 100644 e2022389da0c18f0c8a0e2f9b27d58d197f41b32 0 README.md   コミットの仕組み  shumon.fujita 

Slide 318

Slide 318 text

318 本題に戻って、編集したコードを add すると何が起こるのか。   $ git ls-files --stage 100644 e2022389da0c18f0c8a0e2f9b27d58d197f41b32 0 README.md $ echo hoge > hoge.txt   コミットの仕組み  shumon.fujita 

Slide 319

Slide 319 text

319 本題に戻って、編集したコードを add すると何が起こるのか。   $ git ls-files --stage 100644 e2022389da0c18f0c8a0e2f9b27d58d197f41b32 0 README.md $ echo hoge > hoge.txt $ git add hoge.txt   コミットの仕組み  shumon.fujita 

Slide 320

Slide 320 text

320 本題に戻って、編集したコードを add すると何が起こるのか。   $ git ls-files --stage 100644 e2022389da0c18f0c8a0e2f9b27d58d197f41b32 0 README.md $ echo hoge > hoge.txt $ git add hoge.txt $ git ls-files --stage   コミットの仕組み  shumon.fujita 

Slide 321

Slide 321 text

321 本題に戻って、編集したコードを add すると何が起こるのか。   $ git ls-files --stage 100644 e2022389da0c18f0c8a0e2f9b27d58d197f41b32 0 README.md $ echo hoge > hoge.txt $ git add hoge.txt $ git ls-files --stage 100644 e2022389da0c18f0c8a0e2f9b27d58d197f41b32 0 README.md 100644 2262de0c121f22df8e78f5a37d6e114fd322c0b0 0 hoge.txt   コミットの仕組み  shumon.fujita 

Slide 322

Slide 322 text

322 本題に戻って、編集したコードを add すると何が起こるのか。   $ git ls-files --stage 100644 e2022389da0c18f0c8a0e2f9b27d58d197f41b32 0 README.md $ echo hoge > hoge.txt $ git add hoge.txt $ git ls-files --stage 100644 e2022389da0c18f0c8a0e2f9b27d58d197f41b32 0 README.md 100644 2262de0c121f22df8e78f5a37d6e114fd322c0b0 0 hoge.txt   コミットの仕組み  shumon.fujita 

Slide 323

Slide 323 text

323 本題に戻って、編集したコードを add すると何が起こるのか。   $ git ls-files --stage 100644 e2022389da0c18f0c8a0e2f9b27d58d197f41b32 0 README.md $ echo hoge > hoge.txt $ git add hoge.txt $ git ls-files --stage 100644 e2022389da0c18f0c8a0e2f9b27d58d197f41b32 0 README.md 100644 2262de0c121f22df8e78f5a37d6e114fd322c0b0 0 hoge.txt index が更新されて、新しいエントリが追加されていることが分かる(このとき blob も一緒に生成される)   コミットの仕組み  shumon.fujita 

Slide 324

Slide 324 text

add は基本的に index の更新 + blob オブジェクトの生成しかしていない。   $ mkdir fuga $ echo fuga > fuga/fuga.txt   324 コミットの仕組み  shumon.fujita 

Slide 325

Slide 325 text

add は基本的に index の更新 + blob オブジェクトの生成しかしていない。   $ mkdir fuga $ echo fuga > fuga/fuga.txt $ git add fuga/fuga.txt   325 コミットの仕組み  shumon.fujita 

Slide 326

Slide 326 text

add は基本的に index の更新 + blob オブジェクトの生成しかしていない。   $ mkdir fuga $ echo fuga > fuga/fuga.txt $ git add fuga/fuga.txt $ git ls-files --stage   326 コミットの仕組み  shumon.fujita 

Slide 327

Slide 327 text

add は基本的に index の更新 + blob オブジェクトの生成しかしていない。   $ mkdir fuga $ echo fuga > fuga/fuga.txt $ git add fuga/fuga.txt $ git ls-files --stage 100644 e2022389da0c18f0c8a0e2f9b27d58d197f41b32 0 README.md 100644 9128c3eb56a3547e2cca631042366bf0f37abe67 0 fuga/fuga.txt 100644 2262de0c121f22df8e78f5a37d6e114fd322c0b0 0 hoge.txt   327 コミットの仕組み  shumon.fujita 

Slide 328

Slide 328 text

Slide 329

Slide 329 text

Slide 330

Slide 330 text

330 blob オブジェクトは add 時に、tree オブジェクトは commit 時に生成する。       コミットの仕組み  shumon.fujita 

Slide 331

Slide 331 text

331 blob オブジェクトは add 時に、tree オブジェクトは commit 時に生成する。     commit すると内部的に実行している処理は大まかには次の通り。   1. index から tree オブジェクトを生成   2. commit オブジェクトを生成   3. HEAD を新しい commit ハッシュに書き換え       コミットの仕組み  shumon.fujita 

Slide 332

Slide 332 text

332 blob オブジェクトは add 時に、tree オブジェクトは commit 時に生成する。     commit すると内部的に実行している処理は大まかには次の通り。   1. index から tree オブジェクトを生成   2. commit オブジェクトを生成   3. HEAD を新しい commit ハッシュに書き換え     それぞれ細かく見ていく。  コミットの仕組み  shumon.fujita 

Slide 333

Slide 333 text

333 commit オブジェクトを作る前に、index から tree オブジェクトを生成する。     コミットの仕組み  shumon.fujita 

Slide 334

Slide 334 text

334 commit オブジェクトを作る前に、index から tree オブジェクトを生成する。   tree オブジェクトの構造はこんな感じ。   $ cat .git/objects/18/4135bd0b06f80372a29a35c32ba2e8a5609dc6 | zlib d | hexdump -C 00000000 74 72 65 65 20 33 37 00 31 30 30 36 34 34 20 52 |tree 37.100644 R| 00000010 45 41 44 4d 45 2e 6d 64 00 e2 02 23 89 da 0c 18 |EADME.md...#....| 00000020 f0 c8 a0 e2 f9 b2 7d 58 d1 97 f4 1b 32 |......}X....2|   コミットの仕組み  shumon.fujita 

Slide 335

Slide 335 text

335 commit オブジェクトを作る前に、index から tree オブジェクトを生成する。   tree オブジェクトの構造はこんな感じ。   $ cat .git/objects/18/4135bd0b06f80372a29a35c32ba2e8a5609dc6 | zlib d | hexdump -C 00000000 74 72 65 65 20 33 37 00 31 30 30 36 34 34 20 52 |tree 37.100644 R| 00000010 45 41 44 4d 45 2e 6d 64 00 e2 02 23 89 da 0c 18 |EADME.md...#....| 00000020 f0 c8 a0 e2 f9 b2 7d 58 d1 97 f4 1b 32 |......}X....2|   コミットの仕組み  shumon.fujita 

Slide 336

Slide 336 text

336 commit オブジェクトを作る前に、index から tree オブジェクトを生成する。   tree オブジェクトの構造はこんな感じ。   $ cat .git/objects/18/4135bd0b06f80372a29a35c32ba2e8a5609dc6 | zlib d | hexdump -C 00000000 74 72 65 65 20 33 37 00 31 30 30 36 34 34 20 52 |tree 37.100644 R| 00000010 45 41 44 4d 45 2e 6d 64 00 e2 02 23 89 da 0c 18 |EADME.md...#....| 00000020 f0 c8 a0 e2 f9 b2 7d 58 d1 97 f4 1b 32 |......}X....2|   コミットの仕組み  shumon.fujita 

Slide 337

Slide 337 text

337 commit オブジェクトを作る前に、index から tree オブジェクトを生成する。   tree オブジェクトの構造はこんな感じ。   $ cat .git/objects/18/4135bd0b06f80372a29a35c32ba2e8a5609dc6 | zlib d | hexdump -C 00000000 74 72 65 65 20 33 37 00 31 30 30 36 34 34 20 52 |tree 37.100644 R| 00000010 45 41 44 4d 45 2e 6d 64 00 e2 02 23 89 da 0c 18 |EADME.md...#....| 00000020 f0 c8 a0 e2 f9 b2 7d 58 d1 97 f4 1b 32 |......}X....2|   コミットの仕組み  shumon.fujita 

Slide 338

Slide 338 text

338 commit オブジェクトを作る前に、index から tree オブジェクトを生成する。   tree オブジェクトの構造はこんな感じ。   $ cat .git/objects/18/4135bd0b06f80372a29a35c32ba2e8a5609dc6 | zlib d | hexdump -C 00000000 74 72 65 65 20 33 37 00 31 30 30 36 34 34 20 52 |tree 37.100644 R| 00000010 45 41 44 4d 45 2e 6d 64 00 e2 02 23 89 da 0c 18 |EADME.md...#....| 00000020 f0 c8 a0 e2 f9 b2 7d 58 d1 97 f4 1b 32 |......}X....2|   コミットの仕組み  shumon.fujita 

Slide 339

Slide 339 text

339 commit オブジェクトを作る前に、index から tree オブジェクトを生成する。   tree オブジェクトの構造はこんな感じ。   $ cat .git/objects/18/4135bd0b06f80372a29a35c32ba2e8a5609dc6 | zlib d | hexdump -C 00000000 74 72 65 65 20 33 37 00 31 30 30 36 34 34 20 52 |tree 37.100644 R| 00000010 45 41 44 4d 45 2e 6d 64 00 e2 02 23 89 da 0c 18 |EADME.md...#....| 00000020 f0 c8 a0 e2 f9 b2 7d 58 d1 97 f4 1b 32 |......}X....2| ファイルの種類とパーミッションのフラグとファイル名、blob ハッシュが 0x00 区切りで書き込まれている。     コミットの仕組み  shumon.fujita 

Slide 340

Slide 340 text

340 commit オブジェクトを作る前に、index から tree オブジェクトを生成する。   tree オブジェクトの構造はこんな感じ。   $ cat .git/objects/18/4135bd0b06f80372a29a35c32ba2e8a5609dc6 | zlib d | hexdump -C 00000000 74 72 65 65 20 33 37 00 31 30 30 36 34 34 20 52 |tree 37.100644 R| 00000010 45 41 44 4d 45 2e 6d 64 00 e2 02 23 89 da 0c 18 |EADME.md...#....| 00000020 f0 c8 a0 e2 f9 b2 7d 58 d1 97 f4 1b 32 |......}X....2| ファイルの種類とパーミッションのフラグとファイル名、blob ハッシュが 0x00 区切りで書き込まれている。   → 全部 index が持っていた情報     コミットの仕組み  shumon.fujita 

Slide 341

Slide 341 text

341 commit オブジェクトを作る前に、index から tree オブジェクトを生成する。   tree オブジェクトの構造はこんな感じ。   $ cat .git/objects/18/4135bd0b06f80372a29a35c32ba2e8a5609dc6 | zlib d | hexdump -C 00000000 74 72 65 65 20 33 37 00 31 30 30 36 34 34 20 52 |tree 37.100644 R| 00000010 45 41 44 4d 45 2e 6d 64 00 e2 02 23 89 da 0c 18 |EADME.md...#....| 00000020 f0 c8 a0 e2 f9 b2 7d 58 d1 97 f4 1b 32 |......}X....2| ファイルの種類とパーミッションのフラグとファイル名、blob ハッシュが 0x00 区切りで書き込まれている。   → 全部 index が持っていた情報     コミットの仕組み 

Slide 342

Slide 342 text

342 ちなみに tree オブジェクトも cat-file で確認できる。     コミットの仕組み  shumon.fujita 

Slide 343

Slide 343 text

343 ちなみに tree オブジェクトも cat-file で確認できる。       $ git cat-file -p 184135 100644 blob e2022389da0c18f0c8a0e2f9b27d58d197f41b32 README.md     コミットの仕組み  shumon.fujita 

Slide 344

Slide 344 text

344 ちなみに tree オブジェクトも cat-file で確認できる。   16進数でダンプするよりも、もっと人間にやさしく表示してくれる。     $ git cat-file -p 184135 100644 blob e2022389da0c18f0c8a0e2f9b27d58d197f41b32 README.md     コミットの仕組み  shumon.fujita 

Slide 345

Slide 345 text

345 ちなみに tree オブジェクトも cat-file で確認できる。   16進数でダンプするよりも、もっと人間にやさしく表示してくれる。     $ git cat-file -p 184135 100644 blob e2022389da0c18f0c8a0e2f9b27d58d197f41b32 README.md コミットの仕組み  shumon.fujita 

Slide 346

Slide 346 text

346 commit すると差分だけでなく、リポジトリのルートディレクトリを含む全ディレクトリ分の tree を自動で作る。        コミットの仕組み  https://git-scm.com/book/en/v2/Git-Internals-Git-Objects 

Slide 347

Slide 347 text

347 commit すると差分だけでなく、リポジトリのルートディレクトリを含む全ディレクトリ分の tree を自動で作る。  この時、変更があった部分だけ新しい blob 及び tree オブジェクト   に書き換えられ、それ以外はコピーされる。     コミットの仕組み  https://git-scm.com/book/en/v2/Git-Internals-Git-Objects 

Slide 348

Slide 348 text

348 commit すると差分だけでなく、リポジトリのルートディレクトリを含む全ディレクトリ分の tree を自動で作る。  この時、変更があった部分だけ新しい blob 及び tree オブジェクト   に書き換えられ、それ以外はコピーされる。   tree オブジェクトを作ったら、次は後述する   commit オブジェクトを作る。     コミットの仕組み  https://git-scm.com/book/en/v2/Git-Internals-Git-Objects 

Slide 349

Slide 349 text

349 commit すると差分だけでなく、リポジトリのルートディレクトリを含む全ディレクトリ分の tree を自動で作る。  この時、変更があった部分だけ新しい blob 及び tree オブジェクト   に書き換えられ、それ以外はコピーされる。   tree オブジェクトを作ったら、次は後述する   commit オブジェクトを作る。   commit オブジェクトは、リポジトリのルートにあたる   tree オブジェクトを参照していて、commit 時のリポジトリの   状態を再現できるようになっている。       コミットの仕組み  https://git-scm.com/book/en/v2/Git-Internals-Git-Objects 

Slide 350

Slide 350 text

350 commit すると差分だけでなく、リポジトリのルートディレクトリを含む全ディレクトリ分の tree を自動で作る。  この時、変更があった部分だけ新しい blob 及び tree オブジェクト   に書き換えられ、それ以外はコピーされる。   tree オブジェクトを作ったら、次は後述する   commit オブジェクトを作る。   commit オブジェクトは、リポジトリのルートにあたる   tree オブジェクトを参照していて、commit 時のリポジトリの   状態を再現できるようになっている。   => コミットはある時点のスナップショット         コミットの仕組み  https://git-scm.com/book/en/v2/Git-Internals-Git-Objects 

Slide 351

Slide 351 text

351 commit すると差分だけでなく、リポジトリのルートディレクトリを含む全ディレクトリ分の tree を自動で作る。  この時、変更があった部分だけ新しい blob 及び tree オブジェクト   に書き換えられ、それ以外はコピーされる。   tree オブジェクトを作ったら、次は後述する   commit オブジェクトを作る。   commit オブジェクトは、リポジトリのルートにあたる   tree オブジェクトを参照していて、commit 時のリポジトリの   状態を再現できるようになっている。   => コミットはある時点のスナップショット   checkoutなどで別のコミットに移った時にすぐにその状態を   復元できるのはこれが理由。       コミットの仕組み  https://git-scm.com/book/en/v2/Git-Internals-Git-Objects 

Slide 352

Slide 352 text

352 commit オブジェクトの構造はこんな感じ。     $ cat .git/objects/56/4d5425c6eff4fab2be1cec9562003b6b64eea0 | zlib d commit 232tree 184135bd0b06f80372a29a35c32ba2e8a5609dc6 parent dd08f09944c8c97a718548030886514d8ef4b887 author shumon84 1617805187 +0900 committer shumon84 1617805187 +0900 README.md を追加  コミットの仕組み  shumon.fujita 

Slide 353

Slide 353 text

353 commit オブジェクトの構造はこんな感じ。   他のオブジェクトと同様に、これの SHA-1 ハッシュが commit ハッシュになる。   $ cat .git/objects/56/4d5425c6eff4fab2be1cec9562003b6b64eea0 | zlib d commit 232tree 184135bd0b06f80372a29a35c32ba2e8a5609dc6 parent dd08f09944c8c97a718548030886514d8ef4b887 author shumon84 1617805187 +0900 committer shumon84 1617805187 +0900 README.md を追加  コミットの仕組み  shumon.fujita 

Slide 354

Slide 354 text

354 commit オブジェクトの構造はこんな感じ。   他のオブジェクトと同様に、これの SHA-1 ハッシュが commit ハッシュになる。   $ cat .git/objects/56/4d5425c6eff4fab2be1cec9562003b6b64eea0 | zlib d commit 232tree 184135bd0b06f80372a29a35c32ba2e8a5609dc6 parent dd08f09944c8c97a718548030886514d8ef4b887 author shumon84 1617805187 +0900 committer shumon84 1617805187 +0900 README.md を追加  コミットの仕組み  shumon.fujita 

Slide 355

Slide 355 text

355 commit オブジェクトの構造はこんな感じ。   他のオブジェクトと同様に、これの SHA-1 ハッシュが commit ハッシュになる。   $ cat .git/objects/56/4d5425c6eff4fab2be1cec9562003b6b64eea0 | zlib d commit 232tree 184135bd0b06f80372a29a35c32ba2e8a5609dc6 parent dd08f09944c8c97a718548030886514d8ef4b887 author shumon84 1617805187 +0900 committer shumon84 1617805187 +0900 README.md を追加  コミットの仕組み  shumon.fujita 

Slide 356

Slide 356 text

356 commit オブジェクトの構造はこんな感じ。   他のオブジェクトと同様に、これの SHA-1 ハッシュが commit ハッシュになる。   $ cat .git/objects/56/4d5425c6eff4fab2be1cec9562003b6b64eea0 | zlib d commit 232tree 184135bd0b06f80372a29a35c32ba2e8a5609dc6 parent dd08f09944c8c97a718548030886514d8ef4b887 author shumon84 1617805187 +0900 committer shumon84 1617805187 +0900 README.md を追加  コミットの仕組み  shumon.fujita 

Slide 357

Slide 357 text

357 commit オブジェクトの構造はこんな感じ。   他のオブジェクトと同様に、これの SHA-1 ハッシュが commit ハッシュになる。   $ cat .git/objects/56/4d5425c6eff4fab2be1cec9562003b6b64eea0 | zlib d commit 232tree 184135bd0b06f80372a29a35c32ba2e8a5609dc6 parent dd08f09944c8c97a718548030886514d8ef4b887 author shumon84 1617805187 +0900 committer shumon84 1617805187 +0900 README.md を追加  コミットの仕組み  shumon.fujita 

Slide 358

Slide 358 text

358 commit オブジェクトの構造はこんな感じ。   他のオブジェクトと同様に、これの SHA-1 ハッシュが commit ハッシュになる。   $ cat .git/objects/56/4d5425c6eff4fab2be1cec9562003b6b64eea0 | zlib d commit 232tree 184135bd0b06f80372a29a35c32ba2e8a5609dc6 parent dd08f09944c8c97a718548030886514d8ef4b887 author shumon84 1617805187 +0900 committer shumon84 1617805187 +0900 README.md を追加  コミットの仕組み  shumon.fujita 

Slide 359

Slide 359 text

359 commit オブジェクトの構造はこんな感じ。   他のオブジェクトと同様に、これの SHA-1 ハッシュが commit ハッシュになる。   $ cat .git/objects/56/4d5425c6eff4fab2be1cec9562003b6b64eea0 | zlib d commit 232tree 184135bd0b06f80372a29a35c32ba2e8a5609dc6 parent dd08f09944c8c97a718548030886514d8ef4b887 author shumon84 1617805187 +0900 committer shumon84 1617805187 +0900 README.md を追加  コミットの仕組み  shumon.fujita 

Slide 360

Slide 360 text

360 commit オブジェクトに含まれている情報は↓の通り。   - リポジトリのルートディレクトリの tree ハッシュ   - 親 commit ハッシュ  - committer と author のタイムスタンプ・名前・メアド   - コミットメッセージ      コミットの仕組み  shumon.fujita 

Slide 361

Slide 361 text

361 commit オブジェクトに含まれている情報は↓の通り。   - リポジトリのルートディレクトリの tree ハッシュ   - 親 commit ハッシュ  - committer と author のタイムスタンプ・名前・メアド   - コミットメッセージ  このうち、どれか 1 つでも変わると、(SHA-1 が衝突しない限り)別の commit ハッシュになる。       コミットの仕組み  shumon.fujita 

Slide 362

Slide 362 text

362 commit オブジェクトに含まれている情報は↓の通り。   - リポジトリのルートディレクトリの tree ハッシュ   - 親 commit ハッシュ  - committer と author のタイムスタンプ・名前・メアド   - コミットメッセージ  このうち、どれか 1 つでも変わると、(SHA-1 が衝突しない限り)別の commit ハッシュになる。     ちなみに、commit ハッシュがどれくらい衝突しないのかというと、   「1000 人で 1 日 10 回、40 京年間 commit し続けても、衝突する可能性は 50 %」   と言われている。    コミットの仕組み  shumon.fujita 

Slide 363

Slide 363 text

363 commit オブジェクトに含まれている情報は↓の通り。   - リポジトリのルートディレクトリの tree ハッシュ   - 親 commit ハッシュ  - committer と author のタイムスタンプ・名前・メアド   - コミットメッセージ  このうち、どれか 1 つでも変わると、(SHA-1 が衝突しない限り)別の commit ハッシュになる。     ちなみに、commit ハッシュがどれくらい衝突しないのかというと、   「1000 人で 1 日 10 回、40 京年間 commit し続けても、衝突する可能性は 50 %」   と言われている。    コミットの仕組み  shumon.fujita  親 commit のハッシュを  持っていることが超重要 

Slide 364

Slide 364 text

364 親 commit ハッシュを commit オブジェクトの一部に含めることで、改ざんされていないことが保証できる。                 コミットの仕組み  shumon.fujita 

Slide 365

Slide 365 text

365 親 commit ハッシュを commit オブジェクトの一部に含めることで、改ざんされていないことが保証できる。                 コミットの仕組み  コミット1  コミット2  コミット3  コミット4  shumon.fujita 

Slide 366

Slide 366 text

366 親 commit ハッシュを commit オブジェクトの一部に含めることで、改ざんされていないことが保証できる。                 コミットの仕組み  コミット1  コミット2  コミット3  コミット4  このコミットを  改ざんしたい！  shumon.fujita 

Slide 367

Slide 367 text

367 親 commit ハッシュを commit オブジェクトの一部に含めることで、改ざんされていないことが保証できる。                 コミットの仕組み  コミット1  コミット2  コミット3  コミット4  このコミットを  改ざんしたい！  親コミットのハッシュが変わるので  parent を書き換える必要がある  shumon.fujita 

Slide 368

Slide 368 text

368 親 commit ハッシュを commit オブジェクトの一部に含めることで、改ざんされていないことが保証できる。                 コミットの仕組み  コミット1  コミット2  コミット3  コミット4  このコミットを  改ざんしたい！  親コミットのハッシュが変わるので  parent を書き換える必要がある  親コミットのハッシュが変わるので  以下略  shumon.fujita 

Slide 369

Slide 369 text

369 親 commit ハッシュを commit オブジェクトの一部に含めることで、改ざんされていないことが保証できる。                 コミットの仕組み  コミット1  コミット2  コミット3  コミット4  このコミットを  改ざんしたい！  親コミットのハッシュが変わるので  parent を書き換える必要がある  親コミットのハッシュが変わるので  以下略  結局元のコミット4とは  別物になってしまう  → 改ざん不可能  shumon.fujita 

Slide 370

Slide 370 text

370 親 commit ハッシュを commit オブジェクトの一部に含めることで、改ざんされていないことが保証できる。             過去の commit を改ざんするには、それ以降全ての commit を改ざんする必要があり、最新の commit も別物に。       コミットの仕組み  コミット1  コミット2  コミット3  コミット4  このコミットを  改ざんしたい！  親コミットのハッシュが変わるので  parent を書き換える必要がある  親コミットのハッシュが変わるので  以下略  結局元のコミット4とは  別物になってしまう  → 改ざん不可能  shumon.fujita 

Slide 371

Slide 371 text

371 親 commit ハッシュを commit オブジェクトの一部に含めることで、改ざんされていないことが保証できる。             過去の commit を改ざんするには、それ以降全ての commit を改ざんする必要があり、最新の commit も別物に。   → Git はブロックチェーン！！   コミットの仕組み  コミット1  コミット2  コミット3  コミット4  このコミットを  改ざんしたい！  親コミットのハッシュが変わるので  parent を書き換える必要がある  親コミットのハッシュが変わるので  以下略  結局元のコミット4とは  別物になってしまう  → 改ざん不可能  shumon.fujita 

Slide 372

Slide 372 text

372 blob オブジェクトは add 時に、tree オブジェクトは commit 時に生成する。     commit すると内部的に実行している処理は大まかには次の通り。 (本当はもうちょっと色々やってるけど割愛)  1. index から tree オブジェクトを生成   2. commit オブジェクトを生成   3. HEAD を新しい commit ハッシュに書き換え     それぞれ細かく見ていく。  コミットの仕組み  shumon.fujita 

Slide 373

Slide 373 text

373 commit オブジェクトを作ったら、Git は最後に HEAD を書き換える。       コミットの仕組み  shumon.fujita 

Slide 374

Slide 374 text

374 commit オブジェクトを作ったら、Git は最後に HEAD を書き換える。   → HEAD とは？      コミットの仕組み  shumon.fujita 

Slide 375

Slide 375 text

375 commit オブジェクトを作ったら、Git は最後に HEAD を書き換える。   → HEAD とは？    HEAD の話をする前に、refs の話をする必要がある。(HEAD は refs の一種)     コミットの仕組み  shumon.fujita 

Slide 376

Slide 376 text

376 commit オブジェクトを作ったら、Git は最後に HEAD を書き換える。   → HEAD とは？    HEAD の話をする前に、refs の話をする必要がある。(HEAD は refs の一種)   refs は特定の commit を指すポインタのようなもの。commit ハッシュのエイリアスとも言える。     コミットの仕組み  shumon.fujita 

Slide 377

Slide 377 text

377 commit オブジェクトを作ったら、Git は最後に HEAD を書き換える。   → HEAD とは？    HEAD の話をする前に、refs の話をする必要がある。(HEAD は refs の一種)   refs は特定の commit を指すポインタのようなもの。commit ハッシュのエイリアスとも言える。   具体的には↓などが refs にあたる。   - tag  - branch  - HEAD  コミットの仕組み  shumon.fujita 

Slide 378

Slide 378 text

378 まずは refs の中でも、最も単純な light weight tag を見ていく。   refs について  shumon.fujita 

Slide 379

Slide 379 text

379 まずは refs の中でも、最も単純な light weight tag を見ていく。   light weight tag は本当にただ特定の commit を指しているだけ。   refs について  shumon.fujita 

Slide 380

Slide 380 text

380 まずは refs の中でも、最も単純な light weight tag を見ていく。   light weight tag は本当にただ特定の commit を指しているだけ。     $ git tag light-weight # オプションなしでタグを作ると light weight tag になる refs について  shumon.fujita 

Slide 381

Slide 381 text

381 まずは refs の中でも、最も単純な light weight tag を見ていく。   light weight tag は本当にただ特定の commit を指しているだけ。     $ git tag light-weight # オプションなしでタグを作ると light weight tag になる $ git log -n 1 --oneline 7c4c08d (HEAD -> master, tag: light-weight) Merge branch 'develop' refs について  shumon.fujita 

Slide 382

Slide 382 text

382 まずは refs の中でも、最も単純な light weight tag を見ていく。   light weight tag は本当にただ特定の commit を指しているだけ。   タグを作ると .git/refs/tags/ 以下に保存される。   $ git tag light-weight # オプションなしでタグを作ると light weight tag になる $ git log -n 1 --oneline 7c4c08d (HEAD -> master, tag: light-weight) Merge branch 'develop' refs について  shumon.fujita 

Slide 383

Slide 383 text

383 まずは refs の中でも、最も単純な light weight tag を見ていく。   light weight tag は本当にただ特定の commit を指しているだけ。   タグを作ると .git/refs/tags/ 以下に保存される。   $ git tag light-weight # オプションなしでタグを作ると light weight tag になる $ git log -n 1 --oneline 7c4c08d (HEAD -> master, tag: light-weight) Merge branch 'develop' $ cat .git/refs/tags/light-weight 7c4c08d68be5a53406af4582a961a460b0db83cd refs について  shumon.fujita 

Slide 384

Slide 384 text

384 次に annotated tag の挙動を見ていく。     refs について  shumon.fujita 

Slide 385

Slide 385 text

385 次に annotated tag の挙動を見ていく。   annotated tag とはコメントが付けられるタグのこと。   -a オプションで作ることができる。   refs について  shumon.fujita 

Slide 386

Slide 386 text

386 次に annotated tag の挙動を見ていく。   annotated tag とはコメントが付けられるタグのこと。   -a オプションで作ることができる。 $ git tag -a annotated -m "メッセージ" $ git log -n 1 --oneline 7c4c08d (HEAD -> master, tag: annotated) Merge branch 'develop'   refs について  shumon.fujita 

Slide 387

Slide 387 text

387 次に annotated tag の挙動を見ていく。   annotated tag とはコメントが付けられるタグのこと。   -a オプションで作ることができる。 $ git tag -a annotated -m "メッセージ" $ git log -n 1 --oneline 7c4c08d (HEAD -> master, tag: annotated) Merge branch 'develop' $ cat .git/refs/tags/annotated e0114d0446b25c2c653fa5dd28c678602033c48b   refs について  shumon.fujita 

Slide 388

Slide 388 text

388 次に annotated tag の挙動を見ていく。   annotated tag とはコメントが付けられるタグのこと。   -a オプションで作ることができる。 $ git tag -a annotated -m "メッセージ" $ git log -n 1 --oneline 7c4c08d (HEAD -> master, tag: annotated) Merge branch 'develop' $ cat .git/refs/tags/annotated e0114d0446b25c2c653fa5dd28c678602033c48b light weight tag と違って、直接 commit ハッシュが書かれているわけではない。     refs について  shumon.fujita 

Slide 389

Slide 389 text

389 次に annotated tag の挙動を見ていく。   annotated tag とはコメントが付けられるタグのこと。   -a オプションで作ることができる。 $ git tag -a annotated -m "メッセージ" $ git log -n 1 --oneline 7c4c08d (HEAD -> master, tag: annotated) Merge branch 'develop' $ cat .git/refs/tags/annotated e0114d0446b25c2c653fa5dd28c678602033c48b light weight tag と違って、直接 commit ハッシュが書かれているわけではない。   → じゃあ何なの？  refs について  shumon.fujita 

Slide 390

Slide 390 text

390 blob ハッシュってなに？→ Git に管理されているオブジェクトの 1 種(の key)のこと。   Git には様々なデータを、「オブジェクト」と呼ばれる概念で表現している。   オブジェクトには以下の 4 種類がある。   - commit オブジェクト  - コミットの情報が入っているオブジェクト   - tree オブジェクト  - ディレクトリの情報が入っているオブジェクト   - blob オブジェクト  - ファイルの情報が入っているオブジェクト   - tag オブジェクト  - annotated tag の情報が入っているオブジェクト     ただしGit で扱うデータが全てオブジェクトなわけではない。例えば branch はオブジェクトで管理していない。   コミットの仕組み  shumon.fujita 

Slide 391

Slide 391 text

391 オブジェクトなので、例によって cat-file で覗いてみる。   もちろん実体は .git/objects/ 以下に zlib で圧縮して保存されている。     refs について  shumon.fujita 

Slide 392

Slide 392 text

392 オブジェクトなので、例によって cat-file で覗いてみる。   もちろん実体は .git/objects/ 以下に zlib で圧縮して保存されている。   $ git cat-file -p e0114d0446b25c2c653fa5dd28c678602033c48b object 7c4c08d68be5a53406af4582a961a460b0db83cd type commit tag annotated tagger shumon84 1618330965 +0900 メッセージ   refs について  shumon.fujita 

Slide 393

Slide 393 text

393 オブジェクトなので、例によって cat-file で覗いてみる。   もちろん実体は .git/objects/ 以下に zlib で圧縮して保存されている。   $ git cat-file -p e0114d0446b25c2c653fa5dd28c678602033c48b object 7c4c08d68be5a53406af4582a961a460b0db83cd type commit tag annotated tagger shumon84 1618330965 +0900 メッセージ   refs について  shumon.fujita  object の欄に、tag が指している  commit のハッシュが書かれている 

Slide 394

Slide 394 text

394 オブジェクトなので、例によって cat-file で覗いてみる。   もちろん実体は .git/objects/ 以下に zlib で圧縮して保存されている。   $ git cat-file -p e0114d0446b25c2c653fa5dd28c678602033c48b object 7c4c08d68be5a53406af4582a961a460b0db83cd type commit tag annotated tagger shumon84 1618330965 +0900 メッセージ commit オブジェクトにちょっと似てる。   refs について  shumon.fujita  object の欄に、tag が指している  commit のハッシュが書かれている 

Slide 395

Slide 395 text

395 次に branch の解説。    refs について  shumon.fujita 

Slide 396

Slide 396 text

396 次に branch の解説。  branch は基本的に light-weight tag とほぼ変わらない。   refs について  shumon.fujita 

Slide 397

Slide 397 text

397 次に branch の解説。  branch は基本的に light-weight tag とほぼ変わらない。   $ cat .git/refs/heads/master 7c4c08d68be5a53406af4582a961a460b0db83cd    refs について  shumon.fujita 

Slide 398

Slide 398 text

398 次に branch の解説。  branch は基本的に light-weight tag とほぼ変わらない。   $ cat .git/refs/heads/master 7c4c08d68be5a53406af4582a961a460b0db83cd  保存場所が .git/refs/heads/ 以下になっているだけで、書かれている内容は同じ。     refs について  shumon.fujita 

Slide 399

Slide 399 text

399 次に branch の解説。  branch は基本的に light-weight tag とほぼ変わらない。   $ cat .git/refs/heads/master 7c4c08d68be5a53406af4582a961a460b0db83cd  保存場所が .git/refs/heads/ 以下になっているだけで、書かれている内容は同じ。   指している commit ハッシュが直接書かれているだけ。     refs について  shumon.fujita 

Slide 400

Slide 400 text

400 次に branch の解説。  branch は基本的に light-weight tag とほぼ変わらない。   $ cat .git/refs/heads/master 7c4c08d68be5a53406af4582a961a460b0db83cd  保存場所が .git/refs/heads/ 以下になっているだけで、書かれている内容は同じ。   指している commit ハッシュが直接書かれているだけ。   → tag との違いは、tag は基本的に書き換えないのに対して、branch はどんどん書き換わっていくところ     refs について  shumon.fujita 

Slide 401

Slide 401 text

401 次に branch の解説。  branch は基本的に light-weight tag とほぼ変わらない。   $ cat .git/refs/heads/master 7c4c08d68be5a53406af4582a961a460b0db83cd  保存場所が .git/refs/heads/ 以下になっているだけで、書かれている内容は同じ。   指している commit ハッシュが直接書かれているだけ。   → tag との違いは、tag は基本的に書き換えないのに対して、branch はどんどん書き換わっていくところ   ちなみに、branch 名がそのままファイルパスになるため、「feature/hoge」という branch を作ると、   feature/ というディレクトリが作られてしまうため、それ以降「feature」という branch は作れなくなる。   refs について  shumon.fujita 

Slide 402

Slide 402 text

402 話を戻して、HEAD について。     refs について  shumon.fujita 

Slide 403

Slide 403 text

403 話を戻して、HEAD について。HEAD は現在の commit を指す refs。     refs について  shumon.fujita 

Slide 404

Slide 404 text

404 話を戻して、HEAD について。HEAD は現在の commit を指す refs。   checkout したときは HEAD が書き換わっている。     refs について  shumon.fujita 

Slide 405

Slide 405 text

405 話を戻して、HEAD について。HEAD は現在の commit を指す refs。   checkout したときは HEAD が書き換わっている。   .git/HEAD に保存されている。   refs について  shumon.fujita 

Slide 406

Slide 406 text

406 話を戻して、HEAD について。HEAD は現在の commit を指す refs。   checkout したときは HEAD が書き換わっている。   .git/HEAD に保存されている。   $ cat .git/HEAD ref: refs/heads/master   refs について  shumon.fujita 

Slide 407

Slide 407 text

407 話を戻して、HEAD について。HEAD は現在の commit を指す refs。   checkout したときは HEAD が書き換わっている。   .git/HEAD に保存されている。   $ cat .git/HEAD ref: refs/heads/master branch 名で checkout すると、commit ハッシュではなく、branch の場所が書き込まれる。   refs について  shumon.fujita 

Slide 408

Slide 408 text

408 話を戻して、HEAD について。HEAD は現在の commit を指す refs。   checkout したときは HEAD が書き換わっている。   .git/HEAD に保存されている。   $ cat .git/HEAD ref: refs/heads/master $ cat .git/refs/heads/master 7c4c08d68be5a53406af4582a961a460b0db83cd branch 名で checkout すると、commit ハッシュではなく、branch の場所が書き込まれる。     refs について  shumon.fujita 

Slide 409

Slide 409 text

409 話を戻して、HEAD について。HEAD は現在の commit を指す refs。   checkout したときは HEAD が書き換わっている。   .git/HEAD に保存されている。   $ cat .git/HEAD ref: refs/heads/master $ cat .git/refs/heads/master 7c4c08d68be5a53406af4582a961a460b0db83cd branch 名で checkout すると、commit ハッシュではなく、branch の場所が書き込まれる。   参照を辿って、現在の commit は推移的に解決される。   refs について  shumon.fujita 

Slide 410

Slide 410 text

410 ようやく commit の内部処理の話に戻ります。       コミットの仕組み  shumon.fujita 

Slide 411

Slide 411 text

411 ようやく commit の内部処理の話に戻ります。   commit オブジェクトを作ったら、Git は最後に HEAD を書き換える。       コミットの仕組み  shumon.fujita 

Slide 412

Slide 412 text

412 ようやく commit の内部処理の話に戻ります。   commit オブジェクトを作ったら、Git は最後に HEAD を書き換える。     HEAD が直接 commit ハッシュを参照している場合       HEAD が branch を参照している場合     コミットの仕組み  shumon.fujita 

Slide 413

Slide 413 text

413 ようやく commit の内部処理の話に戻ります。   commit オブジェクトを作ったら、Git は最後に HEAD を書き換える。     HEAD が直接 commit ハッシュを参照している場合   → HEAD の commit ハッシュを書き換える     HEAD が branch を参照している場合     コミットの仕組み  shumon.fujita 

Slide 414

Slide 414 text

414 ようやく commit の内部処理の話に戻ります。   commit オブジェクトを作ったら、Git は最後に HEAD を書き換える。     HEAD が直接 commit ハッシュを参照している場合   → HEAD の commit ハッシュを書き換える     HEAD が branch を参照している場合   → HEAD が参照している branch の commit ハッシュを書き換える   コミットの仕組み  shumon.fujita 

Slide 415

Slide 415 text

415 Git では、1回コミットするまでに次のような処理をしている。     コミットの仕組みまとめ  shumon.fujita 

Slide 416

Slide 416 text

416 Git では、1回コミットするまでに次のような処理をしている。     1. コードを編集する    コミットの仕組みまとめ  shumon.fujita 

Slide 417

Slide 417 text

417 Git では、1回コミットするまでに次のような処理をしている。     1. コードを編集する  2. 編集したコードを add する   - index の更新  - blob オブジェクトの生成      コミットの仕組みまとめ  shumon.fujita 

Slide 418

Slide 418 text

418 Git では、1回コミットするまでに次のような処理をしている。     1. コードを編集する  2. 編集したコードを add する   - index の更新  - blob オブジェクトの生成  3. commit する  - tree オブジェクトの生成  - commit オブジェクトの生成   - HEAD の書き換え      コミットの仕組みまとめ  shumon.fujita 

Slide 419

Slide 419 text

419 Git では、1回コミットするまでに次のような処理をしている。     1. コードを編集する  2. 編集したコードを add する   - index の更新  - blob オブジェクトの生成  3. commit する  - tree オブジェクトの生成  - commit オブジェクトの生成   - HEAD の書き換え    もうちょっと色々やってるけど、大まかには「コミットする」というとこんな感じの処理のことを指す。   コミットの仕組みまとめ  shumon.fujita 

Slide 420

Slide 420 text

checkout, reset の仕組み  420 shumon.fujita 

Slide 421

Slide 421 text

421 すでに講義中に何度も登場している、みんなお馴染み checkout。       checkout, reset の仕組み  shumon.fujita 

Slide 422

Slide 422 text

422 すでに講義中に何度も登場している、みんなお馴染み checkout。   checkout に比べると、複雑で上級者向けのコマンドと思われている reset。       checkout, reset の仕組み  shumon.fujita 

Slide 423

Slide 423 text

423 すでに講義中に何度も登場している、みんなお馴染み checkout。   checkout に比べると、複雑で上級者向けのコマンドと思われている reset。   実は、この 2 つのコマンドは結構似たようなことをしている。       checkout, reset の仕組み  shumon.fujita 

Slide 424

Slide 424 text

424 すでに講義中に何度も登場している、みんなお馴染み checkout。   checkout に比べると、複雑で上級者向けのコマンドと思われている reset。   実は、この 2 つのコマンドは結構似たようなことをしている。     この 2 つは、基本的に↓の 3 つを書き換えるコマンド。   - ワークツリー(作業ディレクトリ)   - index  - HEAD    checkout, reset の仕組み  shumon.fujita 

Slide 425

Slide 425 text

425 すでに講義中に何度も登場している、みんなお馴染み checkout。   checkout に比べると、複雑で上級者向けのコマンドと思われている reset。   実は、この 2 つのコマンドは結構似たようなことをしている。     この 2 つは、基本的に↓の 3 つを書き換えるコマンド。   - ワークツリー(作業ディレクトリ)   - index  - HEAD  それぞれ見ていく。  checkout, reset の仕組み  shumon.fujita 

Slide 426

Slide 426 text

426 まず checkout は、指定した commit にワークツリーも index も HEAD も全部向けるコマンド。         checkout の仕組み  shumon.fujita 

Slide 427

Slide 427 text

427 まず checkout は、指定した commit にワークツリーも index も HEAD も全部向けるコマンド。     1. 指定した commit が参照している tree をワークツリーに展開する。       checkout の仕組み  shumon.fujita 

Slide 428

Slide 428 text

428 まず checkout は、指定した commit にワークツリーも index も HEAD も全部向けるコマンド。     1. 指定した commit が参照している tree をワークツリーに展開する。   2. index をワークツリーと同期する(= tree と同じ状態にする)。       checkout の仕組み  shumon.fujita 

Slide 429

Slide 429 text

429 まず checkout は、指定した commit にワークツリーも index も HEAD も全部向けるコマンド。     1. 指定した commit が参照している tree をワークツリーに展開する。   2. index をワークツリーと同期する(= tree と同じ状態にする)。   3. HEAD を指定した commit に変更する。       checkout の仕組み  shumon.fujita 

Slide 430

Slide 430 text

430 まず checkout は、指定した commit にワークツリーも index も HEAD も全部向けるコマンド。     1. 指定した commit が参照している tree をワークツリーに展開する。   2. index をワークツリーと同期する(= tree と同じ状態にする)。   3. HEAD を指定した commit に変更する。     refs を指定していた場合、HEAD にはその参照が書き込まれる。   checkout の仕組み  shumon.fujita 

Slide 431

Slide 431 text

431 reset は、オプションによって挙動が変わる。             reset の仕組み  shumon.fujita 

Slide 432

Slide 432 text

432 reset は、オプションによって挙動が変わる。   おおまかには soft, mixed, hard の 3 種類のオプションがある。             reset の仕組み  shumon.fujita 

Slide 433

Slide 433 text

433 reset は、オプションによって挙動が変わる。   おおまかには soft, mixed, hard の 3 種類のオプションがある。   指定した commit ハッシュに向けて、それぞれの内容を書き換える。             reset の仕組み  shumon.fujita 

Slide 434

Slide 434 text

434 reset は、オプションによって挙動が変わる。   おおまかには soft, mixed, hard の 3 種類のオプションがある。   指定した commit ハッシュに向けて、それぞれの内容を書き換える。             reset の仕組み  shumon.fujita    HEAD  index  ワークツリー  git reset --soft 書き換える      git reset --mixed 書き換える  書き換える    git reset --hard 書き換える  書き換える  書き換える 

Slide 435

Slide 435 text

435 reset は、オプションによって挙動が変わる。   おおまかには soft, mixed, hard の 3 種類のオプションがある。   指定した commit ハッシュに向けて、それぞれの内容を書き換える。           --hard は全部書き換えるし、checkout と違いはあるの？     reset の仕組み  shumon.fujita    HEAD  index  ワークツリー  git reset --soft 書き換える      git reset --mixed 書き換える  書き換える    git reset --hard 書き換える  書き換える  書き換える 

Slide 436

Slide 436 text

436 reset は、オプションによって挙動が変わる。   おおまかには soft, mixed, hard の 3 種類のオプションがある。   指定した commit ハッシュに向けて、それぞれの内容を書き換える。           --hard は全部書き換えるし、checkout と違いはあるの？   reset と checkout の最も大きな違いは、HEAD が branch を参照していた場合の挙動。     reset の仕組み  shumon.fujita    HEAD  index  ワークツリー  git reset --soft 書き換える      git reset --mixed 書き換える  書き換える    git reset --hard 書き換える  書き換える  書き換える 

Slide 437

Slide 437 text

437 checkout は HEAD が branch を参照していても、書き換えるのは HEAD のみ。                     reset の仕組み  shumon.fujita  first commit  master.txt を追加  README.md に  「master」と追記  develop.txt を追加  master  README.md に  「develop」と追記  develop  HEAD 

Slide 438

Slide 438 text

438 checkout は HEAD が branch を参照していても、書き換えるのは HEAD のみ。                     reset の仕組み  shumon.fujita  first commit  master.txt を追加  README.md に  「master」と追記  develop.txt を追加  master  README.md に  「develop」と追記  develop  HEAD 

Slide 439

Slide 439 text

439 checkout は HEAD が branch を参照していても、書き換えるのは HEAD のみ。           reset は HEAD が branch を参照していた場合、branch の参照先も書き換える。             reset の仕組み  shumon.fujita  first commit  master.txt を追加  README.md に  「master」と追記  develop.txt を追加  master  README.md に  「develop」と追記  develop  HEAD  first commit  master.txt を追加  README.md に  「master」と追記  develop.txt を追加  master  README.md に  「develop」と追記  develop  HEAD 

Slide 440

Slide 440 text

440 checkout は HEAD が branch を参照していても、書き換えるのは HEAD のみ。           reset は HEAD が branch を参照していた場合、branch の参照先も書き換える。             reset の仕組み  shumon.fujita  first commit  master.txt を追加  README.md に  「master」と追記  develop.txt を追加  master  README.md に  「develop」と追記  develop  HEAD  first commit  master.txt を追加  README.md に  「master」と追記  develop.txt を追加  README.md に  「develop」と追記  develop  master  HEAD 

Slide 441

Slide 441 text

441 branch の参照先を変えられる機能を応用すると、reset は色々な使い方ができる。       reset の仕組み  shumon.fujita 

Slide 442

Slide 442 text

442 branch の参照先を変えられる機能を応用すると、reset は色々な使い方ができる。     ① コミットを無かったことにする       reset の仕組み  shumon.fujita 

Slide 443

Slide 443 text

443 branch の参照先を変えられる機能を応用すると、reset は色々な使い方ができる。     ① コミットを無かったことにする   1 つ前の commit ハッシュに branch を向けることで、最新のコミットをなかったことにできる。       reset の仕組み  shumon.fujita 

Slide 444

Slide 444 text

444 branch の参照先を変えられる機能を応用すると、reset は色々な使い方ができる。     ① コミットを無かったことにする   1 つ前の commit ハッシュに branch を向けることで、最新のコミットをなかったことにできる。   ② add の取り消し      reset の仕組み  shumon.fujita 

Slide 445

Slide 445 text

445 branch の参照先を変えられる機能を応用すると、reset は色々な使い方ができる。     ① コミットを無かったことにする   1 つ前の commit ハッシュに branch を向けることで、最新のコミットをなかったことにできる。   ② add の取り消し  git reset --mixed HEAD とすると、index を HEAD の状況に戻せるので、add を取り消すことができる。       reset の仕組み  shumon.fujita 

Slide 446

Slide 446 text

446 branch の参照先を変えられる機能を応用すると、reset は色々な使い方ができる。     ① コミットを無かったことにする   1 つ前の commit ハッシュに branch を向けることで、最新のコミットをなかったことにできる。   ② add の取り消し  git reset --mixed HEAD とすると、index を HEAD の状況に戻せるので、add を取り消すことができる。   git 2.23 で追加された、restore というサブコマンドを使っても同じことができる。 ※experimental      reset の仕組み  shumon.fujita 

Slide 447

Slide 447 text

447 branch の参照先を変えられる機能を応用すると、reset は色々な使い方ができる。     ① コミットを無かったことにする   1 つ前の commit ハッシュに branch を向けることで、最新のコミットをなかったことにできる。   ② add の取り消し  git reset --mixed HEAD とすると、index を HEAD の状況に戻せるので、add を取り消すことができる。   git 2.23 で追加された、restore というサブコマンドを使っても同じことができる。 ※experimental    使い方は無限大。  reset の仕組み  shumon.fujita 

Slide 448

Slide 448 text

Git Challenge に挑戦  448 shumon.fujita 

Slide 449

Slide 449 text

の前に休憩 10分くらい  449 shumon.fujita 

Slide 450

Slide 450 text

450 割愛していた commit 時に「もうちょっと色々やってる」って話を詳しく。   - 各種 Hooks の起動  - .git/hooks/ 以下にスクリプトを置いておくと、対応するイベントが発火したときに実行してくれる。   - どんなイベントを hook できるのかは公式ドキュメント参照  - reflog の更新  - .git/logs/HEAD に HEAD の向き先の移動履歴を書き込む。   - HEAD が branch を参照していた場合、.git/log/refs/ にも移動履歴を書き込む。   - ちなみにこれらの移動履歴は git reflog で確認できる。   - COMMIT_EDITMSG の編集   - コミットメッセージを設定せずに commit すると自動でエディタが起動するが、そのエディタが開いているファイルが COMMIT_EDITMSG  - ここに書き込まれている内容が、コミットメッセージとして commit オブジェクトに取り込まれる。   休憩中の余談 ①  shumon.fujita 

Slide 451

Slide 451 text

451 reset を使っても、本当に commit がなかったことにできるわけではない。   reset はあくまでも、HEAD・index・ワークツリーを書き換えるコマンドのため、当然 commit オブジェクトを   削除したりはできない。    そうすると、どこからも参照されていない commit が出来上がることがある。   → そういうオブジェクトは一定期間経つと、 git gc というコマンドが走って消される。   → ちなみにどこからも参照されていないオブジェクトは git fsck で探せるよ  休憩中の余談 ②  shumon.fujita 

Slide 452

Slide 452 text

452 blobオブジェクトの説明の時に、gitでは基本的にファイルの差分でなくフルバックアップをするという話をした。   サイズの大きなファイルの場合、微修正を加えるたびにバックアップが取られてしまい、非効率。   実は差分のみ記録する仕組みもある。   => Packfile  容量の節約と効率化のために、Gitはときどきオブジェクトの中のいくつかを一つのバイナリファイルにパックする。   git gc コマンドを手動で実行した時、またはリモートサーバーにプッシュした時にもGitはパック処理を行う。   詳しくはこちらを参照    休憩中の余談 ③ 

Slide 453

Slide 453 text

453 休憩中の余談 ④  このあとのgit challengeがうってつけです！   gitの設定値が異なったのが原因かも？  => “git config —system core.longpaths true” で変更可能  他にもwindowsだとサポートされてるパス長に制限があるそう  要議論要議論

Slide 454

Slide 454 text

Git Challenge に挑戦  454 shumon.fujita 