Git研修【MIXI 23新卒技術研修】

Slide 1

Slide 1 text

IXI Git研修  (23新卒)  1

Slide 2

Slide 2 text

講師について  2

Slide 3

Slide 3 text

自己紹介    久田将成 (23)  株式会社ミクシィ（現 IXI） 2022 年度新卒       ● Fanstaでエンジニアしてます   ○ ailsでサーバー書いたり ext.jsでクライアント書いたりFlutterでアプリ書いたりしてます   ○ 得意領域社食です　なんでもきいてください   ● 好きな言語 ustです　もっと使っていきたい   ● 趣味音楽で日本ロックがすきです   3

Slide 4

Slide 4 text

自己紹介    登内雅人 (26)  株式会社ミクシィ（現 IXI） 2020 年度新卒       ● みて事業部（家族アルバムみて）でエンジニアやってます   ○ CV系研究開発したり、 ps整備したり   ○ バックエンド ython, Goとか   ○ #machine-learning で系書籍輪読会やってます（宣伝）   ● 趣味最近格闘技、筋トレ、ランニング、将棋、ポーカーとかにハマってる   4 GitHub Pages: https://github.com/tonouchi510

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

事前アンケートについて  . Git 普段どようなシーンで使いますか？  → 全員使ったことがある  → 業務やチーム開発で使ったことがある人も結構たくさんいる  6

Slide 7

Slide 7 text

. 特に解説してほしいGitコマンドありますか？    ● rebaseが一番多い    ● cherry-pickやstashなど   便利系コマンド    こ辺も少し解説していきます。  事前アンケートについて  8

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

というわけで  11

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

Git 基礎  13 shumon.fujita 

Slide 12

Slide 12 text

Git 基礎  Git バージョン管理システム(VC ) 1 つ。  14 shumon.fujita 

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

Slide 19

Slide 19 text

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

Slide 22

Slide 22 text

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

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

Slide 29

Slide 29 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   31 shumon.fujita 

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

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   37 shumon.fujita  master デフォルトで  作られる 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   38 shumon.fujita  master デフォルトで  作られる branch  develop という新しい  branch が作られている 

Slide 37

Slide 37 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 にいること注意。   39 shumon.fujita  master デフォルトで  作られる branch  develop という新しい  branch が作られている 

Slide 38

Slide 38 text

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

Slide 39

Slide 39 text

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

Slide 40

Slide 40 text

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

Slide 41

Slide 41 text

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

Slide 42

Slide 42 text

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

Slide 43

Slide 43 text

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

Slide 44

Slide 44 text

Git 基礎  master と develop でそれぞれ開発を進める。   46 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 47 shumon.fujita 

Slide 46

Slide 46 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 48 shumon.fujita 

Slide 47

Slide 47 text

Slide 48

Slide 48 text

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

Slide 49

Slide 49 text

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

Slide 50

Slide 50 text

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

Slide 51

Slide 51 text

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

Slide 52

Slide 52 text

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

Slide 53

Slide 53 text

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

Slide 54

Slide 54 text

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

Slide 55

Slide 55 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.   57 shumon.fujita 

Slide 56

Slide 56 text

Slide 57

Slide 57 text

Git 基礎  merge するに、ours に checkout している状態で、 git merge とする。  EAD E.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.   59 shumon.fujita 

Slide 58

Slide 58 text

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

Slide 59

Slide 59 text

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

Slide 60

Slide 60 text

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

Slide 61

Slide 61 text

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

Slide 62

Slide 62 text

Slide 63

Slide 63 text

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

Slide 64

Slide 64 text

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

Slide 65

Slide 65 text

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

Slide 66

Slide 66 text

Slide 67

Slide 67 text

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

Slide 68

Slide 68 text

Git 基礎  コンフリクト中ファイルを開け、ど行がどようにコンフリクトしているか Git が教えてくれるが、   自動で検出していることもあって、あまり適切でないことが多い。     コンフリクト解消基本、それぞれ branch がそファイルに対して、どような修正を施したか、   意図や内容をきちんと確認してから手を付けること。    70 shumon.fujita 

Slide 69

Slide 69 text

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

Slide 70

Slide 70 text

Slide 71

Slide 71 text

Slide 72

Slide 72 text

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

Slide 73

Slide 73 text

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

Slide 74

Slide 74 text

Slide 75

Slide 75 text

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

Slide 76

Slide 76 text

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

Slide 77

Slide 77 text

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

Slide 78

Slide 78 text

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

Slide 79

Slide 79 text

Slide 80

Slide 80 text

Git 基礎  git diff で、merge-base から EAD E.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   82 shumon.fujita 

Slide 81

Slide 81 text

Slide 82

Slide 82 text

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

Slide 83

Slide 83 text

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

Slide 84

Slide 84 text

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

Slide 85

Slide 85 text

Slide 86

Slide 86 text

Slide 87

Slide 87 text

Slide 88

Slide 88 text

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

Slide 89

Slide 89 text

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

Slide 90

Slide 90 text

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

Slide 91

Slide 91 text

Slide 92

Slide 92 text

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

Slide 94

Slide 94 text

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

Slide 95

Slide 95 text

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

Slide 96

Slide 96 text

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

Slide 97

Slide 97 text

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

Slide 98

Slide 98 text

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

Slide 99

Slide 99 text

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

Slide 100

Slide 100 text

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

Slide 101

Slide 101 text

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

Slide 102

Slide 102 text

Git 基礎  104 要望多かったrebaseについて   merge V rebase?  基本的に mergeでよいと思う   ブランチが既にプッシュされていた場合、rebase コミットログを改変するで強制プッシュが必要になる。        

Slide 103

Slide 103 text

Git 基礎  要望多かったrebaseについて   merge V rebase?  rebase 使いどき(1): 他ブランチに追従するとき           例え developブランチで作業している間にmasterが進んでコンフリクトしたとする   ここでdevelopをmasterにrebaseすると……   105 first commit  second commit  work 1  Conflict!  develop  master 

Slide 104

Slide 104 text

Git 基礎  要望多かったrebaseについて   merge V rebase?  rebase 使いどき(1): 他ブランチに追従するとき           例え developブランチで作業している間にmasterが進んでコンフリクトしたとする   ここでdevelopをmasterにrebaseすると……こうなる   106 first commit  second commit  work 1  develop  master  work 1  develop 

Slide 105

Slide 105 text

Git 基礎  要望多かったrebaseについて   merge V rebase?  rebase 使いどき(1): 他ブランチに追従するとき           例え developブランチで作業している間にmasterが進んでコンフリクトしたとする   ここでdevelopをmasterにrebaseすると……こうなる   こうなれ無事マージできる   107 first commit  second commit  work 1  develop  work 1  develop  merged  master 

Slide 106

Slide 106 text

Git 基礎  要望多かったrebaseについて   merge V rebase?  でも、無理にrebaseを使わなくてもdevelopにmasterをマージすれ同じことができる             （後述） commitsにマージコミットが混ざらないがrebase 利点   それでもやっりdevelopで強制プッシュが必要になってしまうで   他人と共有しているブランチで mergeすることが多い   108 first commit  second commit  work 1  merge from master  develop  merged  master 

Slide 107

Slide 107 text

Git 基礎  要望多かったrebaseについて   merge V rebase?  rebase 使いどき(2): レビュー待ちブランチから新しくブランチを切って作業したとき               branch1 既にmasterにマージ済みであるにも関わらず、コミット一覧に work1が現れる     109 first commit  work1  branch1 merged  work2  branch1  master  branch2  branch2 から master へ   commits    ● work1  ● work2 

Slide 108

Slide 108 text

Git 基礎  要望多かったrebaseについて   merge V rebase?  ここでbranch2をmasterにrebaseすると……     110 first commit  work1  branch1 merged  work2  branch1  master  branch2  branch2 から master へ   commits    ● work1  ● work2 

Slide 109

Slide 109 text

Git 基礎  要望多かったrebaseについて   merge V rebase?  ここでbranch2をmasterにrebaseすると……こうなる     111 first commit  work1  branch1 merged  work2  branch1  master  branch2  branch2 から master へ   commits    ● work2 

Slide 110

Slide 110 text

要望多かったrebaseについて   merge V rebase?  ここでbranch2をmasterにrebaseすると……こうなる               Git 基礎  112 first commit  work1  branch1 merged  work2  branch1  master  branch2  branch2 から master へ   commits    ● work2 

Slide 111

Slide 111 text

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

Slide 112

Slide 112 text

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

Slide 113

Slide 113 text

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

Slide 114

Slide 114 text

Git 基礎  要望多かったrebaseについて   rebaseでできることそ２   ● 複数コミットを1つにまとめる例   116 $ git rebase -i HEAD~3

Slide 115

Slide 115 text

Git 基礎  要望多かったrebaseについて   rebaseでできることそ２   ● 複数コミットを1つにまとめる例   117 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 116

Slide 116 text

Git 基礎  要望多かったrebaseについて   rebaseでできることそ２   ● 複数コミットを1つにまとめる例   118 1 pick 2ff810a 2st commit 2 squash 80e4e22 3rd commit 3 squash 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 117

Slide 117 text

Git 基礎  要望多かったrebaseについて   rebaseでできることそ２   ● 複数コミットを1つにまとめる例   119 1 pick 2ff810a 2st commit 2 squash 80e4e22 3rd commit 3 squash 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 3rd, 4th が 2st に吸収される

Slide 118

Slide 118 text

強制プッシュについて  git push 通常、コミットを追加することみを許す。  push 済みブランチに対して rebase などで履歴改変をすると通常 push を受け付けない。             Git 基礎  122

Slide 119

Slide 119 text

強制プッシュについて  git push 通常、コミットを追加することみを許す。  push 済みブランチに対して rebase などで履歴改変をすると通常 push を受け付けない。   　→ そこで強制プッシュ            Git 基礎  123

Slide 120

Slide 120 text

強制プッシュについて  git push 通常、コミットを追加することみを許す。  push 済みブランチに対して rebase などで履歴改変をすると通常 push を受け付けない。   　→ そこで強制プッシュ  強制プッシュコマンド git push -f だが、有無を言わさずローカルをリモートに上書きする為危険。   そため常に以下コマンドを使うがおすすめ。   git push --force-with-lease --force-if-includes           Git 基礎  124

Slide 121

Slide 121 text

bisectについて            Git 基礎  125

Slide 122

Slide 122 text

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

Slide 123

Slide 123 text

bisectについて  バグが混入したコミットを二分探索で効率的に特定するためコマンド                       Git 基礎  127 $ 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 124

Slide 124 text

bisectについて  バグが混入したコミットを二分探索で効率的に特定するためコマンド               チェック自動化させることも可         Git 基礎  128 $ 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 125

Slide 125 text

submoduleについて            Git 基礎  129

Slide 126

Slide 126 text

submoduleについて  あるリポジトリから、別リポジトリを使用する必要がある時に使用             Git 基礎  130

Slide 127

Slide 127 text

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

Slide 128

Slide 128 text

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

Slide 129

Slide 129 text

submoduleについて  あるリポジトリから、別リポジトリを使用する必要がある時に使用   ● サードパーティが開発したモジュール   ● 複数リポジトリから使われる共通モジュール               Git 基礎  133 $ 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 130

Slide 130 text

submoduleについて  あるリポジトリから、別リポジトリを使用する必要がある時に使用   ● サードパーティが開発したモジュール   ● 複数リポジトリから使われる共通モジュール               Git 基礎  134 $ 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 131

Slide 131 text

135 そ他コマンドご紹介  - revert  指定したコミットを打ち消すコミットを作る。   resetで戻すとコミットログが改変されてしまうで、コードを巻き戻す際 revertがおすすめ。   - cherry-pick  指定したコミットと同じ内容コミットを今いるブランチに作る。   トラブルシューティング際に使うことが多い。   - log --graph  コマンドラインでもグラフィカルにコミットログを表示する。 --oneline もおすすめ。       Git 基礎 

Slide 132

Slide 132 text

そ他コマンドご紹介  - stash  現在ワークツリーにある変更を一時的に退避する。   stash list でスタッシュ一覧が見れたり、   stash apply で変更を復元したり、   stash pop で直近 stashを復元しつつそ stashを削除したりできる。   （実質コミットみたいなもなで stash@{n} で参照できたりもする。）   - - (ハイフン)（コマンドじゃないけど……）   とつ前にいたブランチを指す。   git checkout - でとつ前ブランチに戻ったり、   git merge - でとつ前ブランチを現在ブランチにマージしたりする。     136 Git 基礎 

Slide 133

Slide 133 text

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

Slide 134

Slide 134 text

Git によるチーム開発いろ   138 shumon.fujita 

Slide 135

Slide 135 text

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

Slide 136

Slide 136 text

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

Slide 137

Slide 137 text

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

Slide 138

Slide 138 text

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

Slide 139

Slide 139 text

Slide 140

Slide 140 text

Slide 141

Slide 141 text

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

Slide 142

Slide 142 text

Slide 143

Slide 143 text

Slide 144

Slide 144 text

Git 誕生秘話  それから 2 週間すぎたころ  Bit eeper 流れを汲んだ高な VC   Git  が誕生しました  148 shumon.fujita 

Slide 145

Slide 145 text

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

Slide 146

Slide 146 text

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

Slide 147

Slide 147 text

高な merge と checkout  Git merge と checkout 、実かなり高       151 shumon.fujita 

Slide 148

Slide 148 text

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

Slide 149

Slide 149 text

高な merge と checkout  Git merge と checkout 、実かなり高   特に、「履歴遠さ」 merge や checkout 時間に影響を与えない    → 理由後述 Git 内部構を聞くと分かります   153 shumon.fujita 

Slide 150

Slide 150 text

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

Slide 151

Slide 151 text

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

Slide 152

Slide 152 text

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

Slide 153

Slide 153 text

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

Slide 154

Slide 154 text

Slide 155

Slide 155 text

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

Slide 156

Slide 156 text

Slide 157

Slide 157 text

Slide 158

Slide 158 text

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

Slide 159

Slide 159 text

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

Slide 160

Slide 160 text

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

Slide 161

Slide 161 text

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

Slide 162

Slide 162 text

Slide 163

Slide 163 text

Git Flow  167 shumon.fujita 

Slide 164

Slide 164 text

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

Slide 165

Slide 165 text

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

Slide 166

Slide 166 text

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

Slide 167

Slide 167 text

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

Slide 168

Slide 168 text

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

Slide 169

Slide 169 text

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

Slide 170

Slide 170 text

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

Slide 171

Slide 171 text

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

Slide 172

Slide 172 text

Slide 173

Slide 173 text

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

Slide 174

Slide 174 text

Slide 175

Slide 175 text

Slide 176

Slide 176 text

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

Slide 177

Slide 177 text

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

Slide 178

Slide 178 text

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

Slide 179

Slide 179 text

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

Slide 180

Slide 180 text

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

Slide 181

Slide 181 text

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

Slide 182

Slide 182 text

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

Slide 183

Slide 183 text

Slide 184

Slide 184 text

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

Slide 185

Slide 185 text

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

Slide 186

Slide 186 text

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

Slide 187

Slide 187 text

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

Slide 188

Slide 188 text

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

Slide 189

Slide 189 text

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

Slide 190

Slide 190 text

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

Slide 191

Slide 191 text

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

Slide 192

Slide 192 text

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

Slide 193

Slide 193 text

Slide 194

Slide 194 text

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

Slide 195

Slide 195 text

Slide 196

Slide 196 text

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

Slide 197

Slide 197 text

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

Slide 198

Slide 198 text

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

Slide 199

Slide 199 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)   203 shumon.fujita  https://nvie.com/posts/a-successful-git-branching-model/

Slide 200

Slide 200 text

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

Slide 201

Slide 201 text

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

Slide 202

Slide 202 text

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

Slide 203

Slide 203 text

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

Slide 204

Slide 204 text

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

Slide 205

Slide 205 text

GitHub について  209 shumon.fujita 

Slide 206

Slide 206 text

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

Slide 207

Slide 207 text

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

Slide 208

Slide 208 text

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

Slide 209

Slide 209 text

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

Slide 210

Slide 210 text

Slide 211

Slide 211 text

Slide 212

Slide 212 text

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

Slide 213

Slide 213 text

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

Slide 214

Slide 214 text

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

Slide 215

Slide 215 text

Slide 216

Slide 216 text

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

Slide 217

Slide 217 text

Slide 218

Slide 218 text

Slide 219

Slide 219 text

Slide 220

Slide 220 text

ull equest について  GitHub 関連機能で一番重要。         224 shumon.fujita 

Slide 221

Slide 221 text

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

Slide 222

Slide 222 text

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

Slide 223

Slide 223 text

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

Slide 224

Slide 224 text

Slide 225

Slide 225 text

Slide 226

Slide 226 text

を出す側注意点  230 shumon.fujita 

Slide 227

Slide 227 text

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

Slide 228

Slide 228 text

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

Slide 229

Slide 229 text

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

Slide 230

Slide 230 text

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

Slide 231

Slide 231 text

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

Slide 232

Slide 232 text

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

Slide 233

Slide 233 text

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

Slide 234

Slide 234 text

Slide 235

Slide 235 text

Slide 236

Slide 236 text

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

Slide 237

Slide 237 text

Slide 238

Slide 238 text

Slide 239

Slide 239 text

Slide 240

Slide 240 text

を見る側注意点  244 shumon.fujita 

Slide 241

Slide 241 text

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

Slide 242

Slide 242 text

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

Slide 243

Slide 243 text

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

Slide 244

Slide 244 text

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

Slide 245

Slide 245 text

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

Slide 246

Slide 246 text

Slide 247

Slide 247 text

Slide 248

Slide 248 text

Slide 249

Slide 249 text

Slide 250

Slide 250 text

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

Slide 251

Slide 251 text

Slide 252

Slide 252 text

Slide 253

Slide 253 text

Slide 254

Slide 254 text

Slide 255

Slide 255 text

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

Slide 256

Slide 256 text

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

Slide 257

Slide 257 text

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

Slide 258

Slide 258 text

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

Slide 259

Slide 259 text

Slide 260

Slide 260 text

Slide 261

Slide 261 text

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

Slide 262

Slide 262 text

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

Slide 263

Slide 263 text

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

Slide 264

Slide 264 text

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

Slide 265

Slide 265 text

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

Slide 266

Slide 266 text

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

Slide 267

Slide 267 text

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

Slide 268

Slide 268 text

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

Slide 269

Slide 269 text

ecurity について  主に↓ 3 つ機能についてあれこれをするタブ。   - ecurity olicy  - ecurity Advisories  - Dependabot          273 shumon.fujita 

Slide 270

Slide 270 text

ecurity について  主に↓ 3 つ機能についてあれこれをするタブ。   - ecurity olicy  - ecurity Advisories  - Dependabot    ecurity olicy 脆弱性報告手順を arkdown で書いておく。         274 shumon.fujita 

Slide 271

Slide 271 text

Slide 272

Slide 272 text

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

Slide 273

Slide 273 text

Slide 274

Slide 274 text

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

Slide 275

Slide 275 text

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

Slide 276

Slide 276 text

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

Slide 277

Slide 277 text

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

Slide 278

Slide 278 text

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

Slide 279

Slide 279 text

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

Slide 280

Slide 280 text

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

Slide 281

Slide 281 text

Slide 282

Slide 282 text

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

Slide 283

Slide 283 text

Slide 284

Slide 284 text

Git 内部構   288 shumon.fujita 

Slide 285

Slide 285 text

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

Slide 286

Slide 286 text

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

Slide 287

Slide 287 text

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

Slide 288

Slide 288 text

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

Slide 289

Slide 289 text

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

Slide 290

Slide 290 text

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

Slide 291

Slide 291 text

コミット仕組み  295 shumon.fujita 

Slide 292

Slide 292 text

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

Slide 293

Slide 293 text

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

Slide 294

Slide 294 text

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

Slide 295

Slide 295 text

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

Slide 296

Slide 296 text

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

Slide 297

Slide 297 text

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

Slide 298

Slide 298 text

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

Slide 299

Slide 299 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��   303 コミット仕組み  shumon.fujita 

Slide 300

Slide 300 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��   304 コミット仕組み  shumon.fujita 

Slide 301

Slide 301 text

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

Slide 302

Slide 302 text

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

Slide 303

Slide 303 text

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

Slide 304

Slide 304 text

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

Slide 305

Slide 305 text

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

Slide 306

Slide 306 text

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

Slide 307

Slide 307 text

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

Slide 308

Slide 308 text

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

Slide 309

Slide 309 text

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

Slide 310

Slide 310 text

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

Slide 311

Slide 311 text

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

Slide 312

Slide 312 text

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

Slide 313

Slide 313 text

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

Slide 314

Slide 314 text

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

Slide 315

Slide 315 text

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

Slide 316

Slide 316 text

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

Slide 317

Slide 317 text

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

Slide 318

Slide 318 text

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

Slide 319

Slide 319 text

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

Slide 320

Slide 320 text

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

Slide 321

Slide 321 text

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

Slide 322

Slide 322 text

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

Slide 323

Slide 323 text

EAD E.md blob (e2022389da0c18f0c8a0e2f9b27d58d197f41b32) 中身を確認してみる。   327 コミット仕組み 

Slide 324

Slide 324 text

Slide 325

Slide 325 text

Slide 326

Slide 326 text

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

Slide 327

Slide 327 text

Slide 328

Slide 328 text

Slide 329

Slide 329 text

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

Slide 330

Slide 330 text

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

Slide 331

Slide 331 text

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

Slide 332

Slide 332 text

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

Slide 333

Slide 333 text

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

Slide 334

Slide 334 text

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

Slide 335

Slide 335 text

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

Slide 336

Slide 336 text

340 本題に戻って、編集したコードを 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 337

Slide 337 text

341 本題に戻って、編集したコードを 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 338

Slide 338 text

342 本題に戻って、編集したコードを 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 339

Slide 339 text

343 本題に戻って、編集したコードを 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 340

Slide 340 text

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

Slide 341

Slide 341 text

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

Slide 342

Slide 342 text

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

Slide 343

Slide 343 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   347 コミット仕組み  shumon.fujita 

Slide 344

Slide 344 text

Slide 345

Slide 345 text

Slide 346

Slide 346 text

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

Slide 347

Slide 347 text

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

Slide 348

Slide 348 text

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

Slide 349

Slide 349 text

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

Slide 350

Slide 350 text

354 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 351

Slide 351 text

355 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 352

Slide 352 text

356 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 353

Slide 353 text

357 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 354

Slide 354 text

358 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 355

Slide 355 text

359 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 356

Slide 356 text

360 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 357

Slide 357 text

361 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 358

Slide 358 text

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

Slide 359

Slide 359 text

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

Slide 360

Slide 360 text

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

Slide 361

Slide 361 text

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

Slide 362

Slide 362 text

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

Slide 363

Slide 363 text

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

Slide 364

Slide 364 text

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

Slide 365

Slide 365 text

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

Slide 366

Slide 366 text

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

Slide 367

Slide 367 text

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

Slide 368

Slide 368 text

372 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 369

Slide 369 text

373 commit オブジェクト構こんな感じ。   他オブジェクトと同様に、これ HA-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 370

Slide 370 text

374 commit オブジェクト構こんな感じ。   他オブジェクトと同様に、これ HA-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 371

Slide 371 text

375 commit オブジェクト構こんな感じ。   他オブジェクトと同様に、これ HA-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 372

Slide 372 text

376 commit オブジェクト構こんな感じ。   他オブジェクトと同様に、これ HA-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 373

Slide 373 text

377 commit オブジェクト構こんな感じ。   他オブジェクトと同様に、これ HA-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 374

Slide 374 text

378 commit オブジェクト構こんな感じ。   他オブジェクトと同様に、これ HA-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 375

Slide 375 text

379 commit オブジェクト構こんな感じ。   他オブジェクトと同様に、これ HA-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 376

Slide 376 text

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

Slide 377

Slide 377 text

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

Slide 378

Slide 378 text

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

Slide 379

Slide 379 text

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

Slide 380

Slide 380 text

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

Slide 381

Slide 381 text

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

Slide 382

Slide 382 text

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

Slide 383

Slide 383 text

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

Slide 384

Slide 384 text

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

Slide 385

Slide 385 text

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

Slide 386

Slide 386 text

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

Slide 387

Slide 387 text

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

Slide 388

Slide 388 text

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

Slide 389

Slide 389 text

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

Slide 390

Slide 390 text

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

Slide 391

Slide 391 text

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

Slide 392

Slide 392 text

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

Slide 393

Slide 393 text

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

Slide 394

Slide 394 text

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

Slide 395

Slide 395 text

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

Slide 396

Slide 396 text

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

Slide 397

Slide 397 text

401 まず 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 398

Slide 398 text

402 まず 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 399

Slide 399 text

403 まず 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 400

Slide 400 text

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

Slide 401

Slide 401 text

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

Slide 402

Slide 402 text

406 次に 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 403

Slide 403 text

407 次に 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 404

Slide 404 text

408 次に 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 405

Slide 405 text

409 次に 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 406

Slide 406 text

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

Slide 407

Slide 407 text

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

Slide 408

Slide 408 text

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

Slide 409

Slide 409 text

413 オブジェクトなで、例によって 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 410

Slide 410 text

414 オブジェクトなで、例によって 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 411

Slide 411 text

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

Slide 412

Slide 412 text

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

Slide 413

Slide 413 text

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

Slide 414

Slide 414 text

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

Slide 415

Slide 415 text

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

Slide 416

Slide 416 text

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

Slide 417

Slide 417 text

421 次に 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 418

Slide 418 text

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

Slide 419

Slide 419 text

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

Slide 420

Slide 420 text

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

Slide 421

Slide 421 text

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

Slide 422

Slide 422 text

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

Slide 423

Slide 423 text

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

Slide 424

Slide 424 text

428 話を戻して、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 425

Slide 425 text

429 話を戻して、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 426

Slide 426 text

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

Slide 427

Slide 427 text

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

Slide 428

Slide 428 text

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

Slide 429

Slide 429 text

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

Slide 430

Slide 430 text

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

Slide 431

Slide 431 text

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

Slide 432

Slide 432 text

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

Slide 433

Slide 433 text

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

Slide 434

Slide 434 text

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

Slide 435

Slide 435 text

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

Slide 436

Slide 436 text

checkout, reset 仕組み  440 shumon.fujita 

Slide 437

Slide 437 text

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

Slide 438

Slide 438 text

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

Slide 439

Slide 439 text

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

Slide 440

Slide 440 text

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

Slide 441

Slide 441 text

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

Slide 442

Slide 442 text

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

Slide 443

Slide 443 text

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

Slide 444

Slide 444 text

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

Slide 445

Slide 445 text

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

Slide 446

Slide 446 text

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

Slide 447

Slide 447 text

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

Slide 448

Slide 448 text

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

Slide 449

Slide 449 text

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

Slide 450

Slide 450 text

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

Slide 451

Slide 451 text

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

Slide 452

Slide 452 text

456 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 453

Slide 453 text

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

Slide 454

Slide 454 text

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

Slide 455

Slide 455 text

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

Slide 456

Slide 456 text

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

Slide 457

Slide 457 text

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

Slide 458

Slide 458 text

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

Slide 459

Slide 459 text

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

Slide 460

Slide 460 text

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

Slide 461

Slide 461 text

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

Slide 462

Slide 462 text

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

Slide 463

Slide 463 text

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

Slide 464

Slide 464 text

Git Challenge に挑戦  468 shumon.fujita 

Slide 465

Slide 465 text

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

Slide 466

Slide 466 text

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

Slide 467

Slide 467 text

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

Slide 468

Slide 468 text

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

Slide 469

Slide 469 text

473 GitHubで図が書ける話  ermaid      休憩中余談 ④  flowchart TB S(START) --> Q1{Gitが好きですか} -- yes --> G(Gitを使いましょう) Q1 -- no --> Q2{Gitを好きになれますか } -- yes --> G2(それではGitを使いましょう) Q2 -- no --> G3(とりあえずGitを使いましょう)

Slide 470

Slide 470 text

Git Challenge に挑戦  475 shumon.fujita 