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

IXI Git研修  (23新卒)  1

講師について  2

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

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

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

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

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

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

というわけで  11

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

Git 基礎  13 shumon.fujita 

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

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

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

/ 卒論(1).pdf / 卒論_最新.pdf / 卒論_修正版.pdf / 卒論_最終稿.pdf / 卒論_提出用.pdf   → どれが最新？  17 shumon.fujita 

/ 卒論(1).pdf / 卒論_最新.pdf / 卒論_修正版.pdf / 卒論_最終稿.pdf / 卒論_提出用.pdf   → どれが最新？ 1 つ前版？     18 shumon.fujita 

/ 卒論(1).pdf / 卒論_最新.pdf / 卒論_修正版.pdf / 卒論_最終稿.pdf / 卒論_提出用.pdf   → どれが最新？ 1 つ前版？ 5 つ前版？       19 shumon.fujita 

/ 卒論(1).pdf / 卒論_最新.pdf / 卒論_修正版.pdf / 卒論_最終稿.pdf / 卒論_提出用.pdf   → どれが最新？ 1 つ前版？ 5 つ前版？   卒論_20210118.pdf / 卒論_20210120.pdf / 卒論20210201.pdf       20 shumon.fujita 

/ 卒論(1).pdf / 卒論_最新.pdf / 卒論_修正版.pdf / 卒論_最終稿.pdf / 卒論_提出用.pdf   → どれが最新？ 1 つ前版？ 5 つ前版？   卒論_20210118.pdf / 卒論_20210120.pdf / 卒論20210201.pdf   → 新しいバージョン保存するたに容量が 2 倍 3 倍になっていく......       21 shumon.fujita 

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

/ 卒論(1).pdf / 卒論_最新.pdf / 卒論_修正版.pdf / 卒論_最終稿.pdf / 卒論_提出用.pdf   → どれが最新？ 1 つ前版？ 5 つ前版？   卒論_20210118.pdf / 卒論_20210120.pdf / 卒論20210201.pdf   → 新しいバージョン保存するたに容量が 2 倍 3 倍になっていく......     1 人で書いている卒論ならこれでもなんとかなるけど、100 人で数年かけて開発するソフトウェアならヤバイ   Git を始めとする VC を使えこんな問題とおさら！     23 shumon.fujita 

/ 卒論(1).pdf / 卒論_最新.pdf / 卒論_修正版.pdf / 卒論_最終稿.pdf / 卒論_提出用.pdf   → どれが最新？ 1 つ前版？ 5 つ前版？   卒論_20210118.pdf / 卒論_20210120.pdf / 卒論20210201.pdf   → 新しいバージョン保存するたに容量が 2 倍 3 倍になっていく......     1 人で書いている卒論ならこれでもなんとかなるけど、100 人で数年かけて開発するソフトウェアならヤバイ   Git を始めとする VC を使えこんな問題とおさら！   簡単に履歴を辿れて、容量も抑えつつ、おまけに改ざんにも強い神ツール！   24 shumon.fujita 

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

Git 単に時系列順にバージョンを管理するだけでなく、別々時間軸バージョンを管理できる。     26 shumon.fujita 

Git 単に時系列順にバージョンを管理するだけでなく、別々時間軸バージョンを管理できる。   さらにそれらを統合することができる。   27 shumon.fujita 

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

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

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

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 

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

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

  $ git branch * master   34 shumon.fujita  master デフォルトで  作られる branch 

ちなみに Git 2.28 以降なら git config --global init.defaultBranch で init 時に作られる branch を変更できる。   $ git branch * master   35 shumon.fujita  master デフォルトで  作られる branch 

ちなみに Git 2.28 以降なら git config --global init.defaultBranch で init 時に作られる branch を変更できる。   $ git branch * master $ git branch develop   36 shumon.fujita  master デフォルトで  作られる 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 

ちなみに 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 が作られている 

ちなみに 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 が作られている 

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

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

git branch develop * master $ git checkout develop   42 shumon.fujita 

git branch develop * master $ git checkout develop $ git branch * develop master   43 shumon.fujita 

git branch develop * master $ git checkout develop $ git branch * develop master   44 shumon.fujita  * が現在 branch を  表している 

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

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

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

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

--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 first commit から、それぞれ branch に 2 コミットずつ積まれている。 49 shumon.fujita 

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

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

  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 

  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 

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

<theirs> とする。    $ git branch develop * master   55 shumon.fujita 

<theirs> とする。    $ git branch develop * master $ git merge develop   56 shumon.fujita 

<theirs> とする。    $ 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 

<theirs> とする。    $ 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.   58 shumon.fujita 

<theirs> とする。  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 

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

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

と theirs で同じ箇所を変更していた場合、どちら変更を残すべきか自動的に判定できない。   → これがコンフリクト        62 shumon.fujita 

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

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

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

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

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

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

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

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

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

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

  自動で検出していることもあって、あまり適切でないことが多い。     コンフリクト解消基本、それぞれ branch がそファイルに対して、どような修正を施したか、   意図や内容をきちんと確認してから手を付けること。  ついついコンフリクト行だけを眺めて、手癖でコンフリクト解消したくなるけど、先に確認するコストと、   不適切な merge になってしまった場合後始末コストを比べたら、絶対先に確認するべき。  → そもそもコンフリクトしている時点でプチ事故なで、めんどくさがらず慎重に     そ上で、具体的にどう merge すれ、両方 branch 修正を上手に取り込めるかを考えていく。     73 shumon.fujita 

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

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

merge-base <branch1> <branch2> で分岐した commit を調べられる。   $ git merge-base master develop 45e2f9c8827024f53ca982c70676614f781205d7       76 shumon.fujita 

merge-base <branch1> <branch2> で分岐した 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 

merge-base <branch1> <branch2> で分岐した 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 ハッシュが分かる 

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

  $ git diff 45e2f9c8827024f53ca982c70676614f781205d7 develop README.md   80 shumon.fujita 

  $ 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   81 shumon.fujita 

  $ 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 

  $ 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 diff --git a/README.md b/README.md index e965047..1ffbd88 100644 --- a/README.md +++ b/README.md @@ -1 +1,2 @@ -Hello +Hello master  83 shumon.fujita 

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

master : Hello → Hello master に変更   - develop : Hello → Hello develop に変更     今回 ours が master なで、Hello master にすることにしたとする。         85 shumon.fujita 

master : Hello → Hello master に変更   - develop : Hello → Hello develop に変更     今回 ours が master なで、Hello master にすることにしたとする。   $ emacs README.md # README.md を修正する       86 shumon.fujita 

master : Hello → Hello master に変更   - develop : Hello → Hello develop に変更     今回 ours が master なで、Hello master にすることにしたとする。   $ emacs README.md # README.md を修正する $ cat README.md Hello master       87 shumon.fujita 

master : Hello → Hello master に変更   - develop : Hello → Hello develop に変更     今回 ours が master なで、Hello master にすることにしたとする。   $ emacs README.md # README.md を修正する $ cat README.md Hello master $ git merge --continue       88 shumon.fujita 

master : Hello → Hello master に変更   - develop : Hello → Hello develop に変更     今回 ours が master なで、Hello master にすることにしたとする。   $ emacs README.md # README.md を修正する $ cat README.md Hello master $ git merge --continue   これで無事コンフリクトを解消して merge できた。     89 shumon.fujita 

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

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

1 番。     Git に fast-forward merge という絶対にコンフリクトが起きない merge がある。           92 shumon.fujita 

1 番。     Git に fast-forward merge という絶対にコンフリクトが起きない merge がある。   fast-forward merge と、 merge-base が ours ときに起こる merge こと。           93 shumon.fujita 

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 

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 

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 

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

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

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

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

• ブランチ分岐元を変更する           developブランチを、最新 masterから分岐したことにする。        

• ブランチ分岐元を変更する           developブランチを、最新 masterから分岐したことにする。   こうすると、masterにマージする際に fast-forward merge できる。    

• ブランチ分岐元を変更する           developブランチを、最新 masterから分岐したことにする。   こうすると、masterにマージする際に fast-forward merge できる。   pushしてからだとややこしいことになる可能性もあるで、やるならpush前ブランチ方が良いかも    

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

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

他ブランチに追従するとき           例え developブランチで作業している間にmasterが進んでコンフリクトしたとする   ここでdevelopをmasterにrebaseすると……こうなる   106 first commit  second commit  work 1  develop  master  work 1  develop 

他ブランチに追従するとき           例え developブランチで作業している間にmasterが進んでコンフリクトしたとする   ここでdevelopをmasterにrebaseすると……こうなる   こうなれ無事マージできる   107 first commit  second commit  work 1  develop  work 1  develop  merged  master 

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 

レビュー待ちブランチから新しくブランチを切って作業したとき               branch1 既にmasterにマージ済みであるにも関わらず、コミット一覧に work1が現れる     109 first commit  work1  branch1 merged  work2  branch1  master  branch2  branch2 から master へ   commits    • work1  • work2 

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

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

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

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

• コミット履歴修正（-iオプション）   ◦ コミット並替え  ◦ いくつかコミットを一つに合体   ◦ コミットメッセージを変更  ◦ 過去コミットに戻って修正  

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

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

複数コミットを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 <commit> = use commit 9 # r, reword <commit> = use commit, but edit the commit message 10 # e, edit <commit> = use commit, but stop for amending 11 # s, squash <commit> = use commit, but meld into previous commit 12 # f, fixup <commit> = like "squash", but discard this commit's log message 13 # x, exec <command> = run command (the rest of the line) using shell 14 # b, break = stop here (continue rebase later with 'git rebase --continue') 15 # d, drop <commit> = remove commit 16 # l, label <label> = label current HEAD with a name 17 # t, reset <label> = reset HEAD to a label

複数コミットを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 <commit> = use commit 9 # r, reword <commit> = use commit, but edit the commit message 10 # e, edit <commit> = use commit, but stop for amending 11 # s, squash <commit> = use commit, but meld into previous commit 12 # f, fixup <commit> = like "squash", but discard this commit's log message 13 # x, exec <command> = run command (the rest of the line) using shell 14 # b, break = stop here (continue rebase later with 'git rebase --continue') 15 # d, drop <commit> = remove commit 16 # l, label <label> = label current HEAD with a name 17 # t, reset <label> = reset HEAD to a label

複数コミットを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 <commit> = use commit 9 # r, reword <commit> = use commit, but edit the commit message 10 # e, edit <commit> = use commit, but stop for amending 11 # s, squash <commit> = use commit, but meld into previous commit 12 # f, fixup <commit> = like "squash", but discard this commit's log message 13 # x, exec <command> = run command (the rest of the line) using shell 14 # b, break = stop here (continue rebase later with 'git rebase --continue') 15 # d, drop <commit> = remove commit 16 # l, label <label> = label current HEAD with a name 17 # t, reset <label> = reset HEAD to a label 3rd, 4th が 2st に吸収される

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

などで履歴改変をすると通常 push を受け付けない。   　→ そこで強制プッシュ            Git 基礎  123

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

bisectについて            Git 基礎  125

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

bisectについて  バグが混入したコミットを二分探索で効率的に特定するためコマンド              
        Git 基礎  127 $ git bisect start <bad-commit> <good-commit> #チェックアウトした時点でテスト実行、もしくは動作確認 $ 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

bisectについて  バグが混入したコミットを二分探索で効率的に特定するためコマンド              
チェック自動化させることも可         Git 基礎  128 $ git bisect start <bad-commit> <good-commit> #チェックアウトした時点でテスト実行、もしくは動作確認 $ 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 <bad-commit> <good-commit> $ git bisect run <テストスクリプトのファイル名 >

submoduleについて            Git 基礎  129

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

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

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

              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 <file>..." to unstage) new file: .gitmodules new file: DbConnector $ git submodule status # 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 <file>..." to unstage) new file: .gitmodules new file: DbConnector $ git submodule status # submoduleのどのコミットハッシュを参照しているか確認できる個人的にパッケージングできるならそ方が好み

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

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

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

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

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

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

を開発するため    もともと inux メーリスに投稿されたパッチを、気合いで適用しながら開発していた     141 shumon.fujita 

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

を開発するため    もともと inux メーリスに投稿されたパッチを、気合いで適用しながら開発していた   → 2002 年、「Bit eeper」という有料 VC を無料で使わせてもらえることになった   → 2005 年、なんやかんやあって、あくまで厚意で無料で使えていただけ Bit eeper を有料化されてしまった     143 shumon.fujita 

を開発するため    もともと inux メーリスに投稿されたパッチを、気合いで適用しながら開発していた   → 2002 年、「Bit eeper」という有料 VC を無料で使わせてもらえることになった   → 2005 年、なんやかんやあって、あくまで厚意で無料で使えていただけ Bit eeper を有料化されてしまった   → 他 VC を探す必要がある     144 shumon.fujita 

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

を開発するため    もともと inux メーリスに投稿されたパッチを、気合いで適用しながら開発していた   → 2002 年、「Bit eeper」という有料 VC を無料で使わせてもらえることになった   → 2005 年、なんやかんやあって、あくまで厚意で無料で使えていただけ Bit eeper を有料化されてしまった   → 他 VC を探す必要がある   → 他 VC inux ぐらいデカいプロジェクトを扱うに遅すぎるし、開発者が大勢いる状態に対応できない   → リーナス・トーバルズ「自作するぞ」     146 shumon.fujita 

を開発するため    もともと inux メーリスに投稿されたパッチを、気合いで適用しながら開発していた   → 2002 年、「Bit eeper」という有料 VC を無料で使わせてもらえることになった   → 2005 年、なんやかんやあって、あくまで厚意で無料で使えていただけ Bit eeper を有料化されてしまった   → 他 VC を探す必要がある   → 他 VC inux ぐらいデカいプロジェクトを扱うに遅すぎるし、開発者が大勢いる状態に対応できない   → リーナス・トーバルズ「自作するぞ」   詳しく Git 公式ドキュメントにある Git略史を読んでみて   147 shumon.fujita 

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

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

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

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

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

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

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

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

ystem)に大きく分けて集中型と分散型 2つがある。   分散型 VC 「リポジトリ全履歴を含めた完全なコピーをローカルに持つ」という意味。      156 shumon.fujita 

ystem)に大きく分けて集中型と分散型 2つがある。   分散型 VC 「リポジトリ全履歴を含めた完全なコピーをローカルに持つ」という意味。    例え集中型 ubversion 、リポジトリ完全にサーバが管理してる。     157 shumon.fujita 

ystem)に大きく分けて集中型と分散型 2つがある。   分散型 VC 「リポジトリ全履歴を含めた完全なコピーをローカルに持つ」という意味。    例え集中型 ubversion 、リポジトリ完全にサーバが管理してる。   自分が触りたいファイルだけをローカルにコピーし、修正後サーバにpushする。     158 shumon.fujita 

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

ystem)に大きく分けて集中型と分散型 2つがある。   分散型 VC 「リポジトリ全履歴を含めた完全なコピーをローカルに持つ」という意味。    例え集中型 ubversion 、リポジトリ完全にサーバが管理してる。   自分が触りたいファイルだけをローカルにコピーし、修正後サーバにpushする。   そ間他人自分が使ってるファイルを編集することできない。   → 大人数で開発すると開発度が落ちる     160 shumon.fujita 

ystem)に大きく分けて集中型と分散型 2つがある。   分散型 VC 「リポジトリ全履歴を含めた完全なコピーをローカルに持つ」という意味。    例え集中型 ubversion 、リポジトリ完全にサーバが管理してる。   自分が触りたいファイルだけをローカルにコピーし、修正後サーバにpushする。   そ間他人自分が使ってるファイルを編集することできない。   → 大人数で開発すると開発度が落ちる   → でも分散型 Git 誰がどんな修正をしていても無視して進めることができる   161 shumon.fujita 

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

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

か分からない。   → 複雑なコンフリクト仕方をすると、解消に失敗してバグが混入するかも。       164 shumon.fujita 

か分からない。   → 複雑なコンフリクト仕方をすると、解消に失敗してバグが混入するかも。   → ど branch にど機能が実装されているか分からないで、最新版がどれなか分からない。     165 shumon.fujita 

か分からない。   → 複雑なコンフリクト仕方をすると、解消に失敗してバグが混入するかも。   → ど branch にど機能が実装されているか分からないで、最新版がどれなか分からない。   → そういった問題を防ぐため、branch運用に、いくつか方法論がある。   166 shumon.fujita 

Git Flow  167 shumon.fujita 

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

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

  → 集中型と分散型良いとこ取りができる。       170 shumon.fujita  https://nvie.com/posts/a-successful-git-branching-model/

  → 集中型と分散型良いとこ取りができる。     大体チーム、Git Flow をちょっとアレンジして使ってるんじゃないかな。     171 shumon.fujita  https://nvie.com/posts/a-successful-git-branching-model/

  → 集中型と分散型良いとこ取りができる。     大体チーム、Git Flow をちょっとアレンジして使ってるんじゃないかな。   Git Flow という名前を知らなくても、慣習として Git Flow と同じようなことを   している人も多いと思う。  172 shumon.fujita  https://nvie.com/posts/a-successful-git-branching-model/

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

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

ab なり BitBucket なりなんでもいい。ちなみに弊社で基本的にGitHub。   とにかくそリモートリポジトリを開発者同士で口裏を合わせて常に正とみなす。     175 shumon.fujita 

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

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

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

ab なり BitBucket なりなんでもいい。ちなみに弊社で基本的にGitHub。   とにかくそリモートリポジトリを開発者同士で口裏を合わせて常に正とみなす。     そんな当たり前すぎて、逆にリモートリポジトリが複数ある状態なんて、よく分からない人もいるかも。   でも Git で、複数リモートリポジトリを持つことができる。   - GitHub ができる前から Git 使ってる自前 Git 鯖と GitHub を両方使ってたりする。   - fork したリポジトリを、fork 元リポジトリに追従したいときも使ったりする。   179 shumon.fujita 

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

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

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

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

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

branch 。     feature 複数人で develop を開発するときに使う。       185 shumon.fujita  https://nvie.com/posts/a-successful-git-branching-model/

branch 。     feature 複数人で develop を開発するときに使う。   1機能ごとに develop から branch を切る。機能開発が終われ develop に merge する。       186 shumon.fujita  https://nvie.com/posts/a-successful-git-branching-model/

branch 。     feature 複数人で develop を開発するときに使う。   1機能ごとに develop から branch を切る。機能開発が終われ develop に merge する。   「1 機能 = 1 feature」ルール守ろう。複数機能にまたがる feature デメリットが多い。       187 shumon.fujita  https://nvie.com/posts/a-successful-git-branching-model/

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/

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/

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/

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/

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/

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

するため準備をする branch 。   チームによって、staging という名前で呼んでるかも。           194 shumon.fujita 

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

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

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

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

するため準備をする branch 。   チームによって、staging という名前で呼んでるかも。     具体的にどんな「準備」をするか、プロジェクトによってまちまち   - 新規実装を凍結し、bugfix みに使う   - version 表記やタイムスタンプを更新する   - Apple や Google 審査ために使う     いずれにしても、release master へ commit する( = ユーザ手に渡る)まで、最終段階にあたるで、   release で新機能を追加するご法度。   199 shumon.fujita 

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

    develop 以外で、唯一 master から切られる branch 。     201 shumon.fujita  https://nvie.com/posts/a-successful-git-branching-model/

    develop 以外で、唯一 master から切られる branch 。   修正が完了したら master と develop (or release)に merge する。     202 shumon.fujita  https://nvie.com/posts/a-successful-git-branching-model/

    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/

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

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

Git Flowをそままでなく、   ちょっとアレンジして使っていると思う。         206 https://nvie.com/posts/a-successful-git-branching-model/

Git Flowをそままでなく、   ちょっとアレンジして使っていると思う。     他にもGitHub Flowとか、トランクベース開発など手法もある。         207 https://nvie.com/posts/a-successful-git-branching-model/

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

GitHub について  209 shumon.fujita 

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

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

GitHub を使っているで、GitHub 機能について話します。     GitHub Git をチームで使うにあたって便利な機能がいっい入っている         212 shumon.fujita 

GitHub を使っているで、GitHub 機能について話します。     GitHub Git をチームで使うにあたって便利な機能がいっい入っている   基本的な機能リポジトリトップページタブでまとめられている。         213 shumon.fujita 

GitHub を使っているで、GitHub 機能について話します。     GitHub Git をチームで使うにあたって便利な機能がいっい入っている   基本的な機能リポジトリトップページタブでまとめられている。   でも意外と全部タブ開いたことない人もいるんじゃないかな。         214 shumon.fujita 

GitHub を使っているで、GitHub 機能について話します。     GitHub Git をチームで使うにあたって便利な機能がいっい入っている   基本的な機能リポジトリトップページタブでまとめられている。   でも意外と全部タブ開いたことない人もいるんじゃないかな。       まず Issues 機能から解説していく。     215 shumon.fujita 

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

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

  ここに実タスクを並べて、後述 rojectsで管理するチームもあれ、    218 shumon.fujita 

  ここに実タスクを並べて、後述 rojectsで管理するチームもあれ、  「テストが遅いから改善したい」とか「あ負債をどうやって解消しよう」とか   相談事を書いて議論土台にするチームもある。    219 shumon.fujita 

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

  ここに実タスクを並べて、後述 rojectsで管理するチームもあれ、  「テストが遅いから改善したい」とか「あ負債をどうやって解消しよう」とか   相談事を書いて議論土台にするチームもある。  ラベルをつけて、種類別に整理しやすくしたり、  マイルストーンをつけて、いつまでに対応するべきなかを明確化したり、    221 shumon.fujita 

  ここに実タスクを並べて、後述 rojectsで管理するチームもあれ、  「テストが遅いから改善したい」とか「あ負債をどうやって解消しよう」とか   相談事を書いて議論土台にするチームもある。  ラベルをつけて、種類別に整理しやすくしたり、  マイルストーンをつけて、いつまでに対応するべきなかを明確化したり、  特定 issueに誰かをassignして対応を任せたり。    222 shumon.fujita 

  ここに実タスクを並べて、後述 rojectsで管理するチームもあれ、  「テストが遅いから改善したい」とか「あ負債をどうやって解消しよう」とか   相談事を書いて議論土台にするチームもある。  ラベルをつけて、種類別に整理しやすくしたり、  マイルストーンをつけて、いつまでに対応するべきなかを明確化したり、  特定 issueに誰かをassignして対応を任せたり。  まあいっいできる。  223 shumon.fujita 

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

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

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

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

や、fork 元リポジトリに、「私がやった作業を取り込んでくれ」とお願いを出せる機能。   → 元々 fork 元リポジトリにお願いする機能なで “ erge equest” でなく “ ull equest”    お願いされた側取り込む前に差分をよく吟味し、大丈夫そうなら merge して差分を取り込む。   ダメそうならダメなポイントを指摘してあげる。     228 shumon.fujita 

や、fork 元リポジトリに、「私がやった作業を取り込んでくれ」とお願いを出せる機能。   → 元々 fork 元リポジトリにお願いする機能なで “ erge equest” でなく “ ull equest”    お願いされた側取り込む前に差分をよく吟味し、大丈夫そうなら merge して差分を取り込む。   ダメそうならダメなポイントを指摘してあげる。   ↑いわゆるコードレビュー  229 shumon.fujita 

を出す側注意点  230 shumon.fujita 

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

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

- レビューに時間がかかると merge まで時間も当然伸る   233 shumon.fujita 

- レビューに時間がかかると merge まで時間も当然伸る   - 別がどんどん先に merge されていく     234 shumon.fujita 

- レビューに時間がかかると merge まで時間も当然伸る   - 別がどんどん先に merge されていく   - そ結果コンフリクトする  235 shumon.fujita 

- レビューに時間がかかると merge まで時間も当然伸る   - 別がどんどん先に merge されていく   - そ結果コンフリクトする  - さらにコンフリクト解消に失敗してバグるかも     236 shumon.fujita 

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

- レビューに時間がかかると merge まで時間も当然伸る   - 別がどんどん先に merge されていく   - そ結果コンフリクトする  - さらにコンフリクト解消に失敗してバグるかも   - 巨大にならざるをえないとき、途中でレビューしてもらう   - Git Flow で少し話をした、feature から feature を切るテク     238 shumon.fujita 

- レビューに時間がかかると merge まで時間も当然伸る   - 別がどんどん先に merge されていく   - そ結果コンフリクトする  - さらにコンフリクト解消に失敗してバグるかも   - 巨大にならざるをえないとき、途中でレビューしてもらう   - Git Flow で少し話をした、feature から feature を切るテク   - 最初 feature に WI をタイトルに付けたり、draft として出したりすると ◦   239 shumon.fujita 

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

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

- レビューに時間がかかると merge まで時間も当然伸る   - 別がどんどん先に merge されていく   - そ結果コンフリクトする  - さらにコンフリクト解消に失敗してバグるかも   - 巨大にならざるをえないとき、途中でレビューしてもらう   - Git Flow で少し話をした、feature から feature を切るテク   - 最初 feature に WI をタイトルに付けたり、draft として出したりすると ◦   - コミットログできるだけ綺麗にしておこう   - こまめにコミットし、できれ最後に git rebase -i で体裁を整えよう  - 厳しめだと fast-forward merge できないだけでもダメって言われたりする     242 shumon.fujita 

- レビューに時間がかかると merge まで時間も当然伸る   - 別がどんどん先に merge されていく   - そ結果コンフリクトする  - さらにコンフリクト解消に失敗してバグるかも   - 巨大にならざるをえないとき、途中でレビューしてもらう   - Git Flow で少し話をした、feature から feature を切るテク   - 最初 feature に WI をタイトルに付けたり、draft として出したりすると ◦   - コミットログできるだけ綺麗にしておこう   - こまめにコミットし、できれ最後に git rebase -i で体裁を整えよう  - 厳しめだと fast-forward merge できないだけでもダメって言われたりする   - こ辺賛否あるで所属チームに合わせると良さそう   243 shumon.fujita 

を見る側注意点  244 shumon.fujita 

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

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

  - コードフォーマッタを使うと、細かいスペース差分とかが生まれなくて便利   247 shumon.fujita 

  - コードフォーマッタを使うと、細かいスペース差分とかが生まれなくて便利   - 人間が見るべきポイントにしっかり集中する   248 shumon.fujita 

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

  - コードフォーマッタを使うと、細かいスペース差分とかが生まれなくて便利   - 人間が見るべきポイントにしっかり集中する   - 仕様穴、セキュリティ/法的にヤバそうなところ   - 負債になりそうなところ、設計的にまずいところ、計算量・レイテンシ的に厳しいところ   250 shumon.fujita 

  - コードフォーマッタを使うと、細かいスペース差分とかが生まれなくて便利   - 人間が見るべきポイントにしっかり集中する   - 仕様穴、セキュリティ/法的にヤバそうなところ   - 負債になりそうなところ、設計的にまずいところ、計算量・レイテンシ的に厳しいところ   - 意外と実装中に気づかなかった問題点が見つかることも多いで、自分もレビューしておくと吉   251 shumon.fujita 

  - コードフォーマッタを使うと、細かいスペース差分とかが生まれなくて便利   - 人間が見るべきポイントにしっかり集中する   - 仕様穴、セキュリティ/法的にヤバそうなところ   - 負債になりそうなところ、設計的にまずいところ、計算量・レイテンシ的に厳しいところ   - 意外と実装中に気づかなかった問題点が見つかることも多いで、自分もレビューしておくと吉   - なかなか人間目でバグ見つかりません！高品質なコード高品質なテストから   252 shumon.fujita 

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

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

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

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

  - コードフォーマッタを使うと、細かいスペース差分とかが生まれなくて便利   - 人間が見るべきポイントにしっかり集中する   - 仕様穴、セキュリティ/法的にヤバそうなところ   - 負債になりそうなところ、設計的にまずいところ、計算量・レイテンシ的に厳しいところ   - 意外と実装中に気づかなかった問題点が見つかることも多いで、自分もレビューしておくと吉   - なかなか人間目でバグ見つかりません！高品質なコード高品質なテストから   - 実装者ことを思いやる  - 「こコード良くない」ような抽象的な言い方やめて、どこがどういう理由で良くないか書く   - 合わせて、どういう方法なら良いかも書けると議論もしやすい   - 定量的な指標もあったりするでそういうも活用すると良いかも   - テキストで指摘、結構キツく感じてしまいがちなで、普段 1.5倍やさしい言葉使いをしよう   257 shumon.fujita 

  - コードフォーマッタを使うと、細かいスペース差分とかが生まれなくて便利   - 人間が見るべきポイントにしっかり集中する   - 仕様穴、セキュリティ/法的にヤバそうなところ   - 負債になりそうなところ、設計的にまずいところ、計算量・レイテンシ的に厳しいところ   - 意外と実装中に気づかなかった問題点が見つかることも多いで、自分もレビューしておくと吉   - なかなか人間目でバグ見つかりません！高品質なコード高品質なテストから   - 実装者ことを思いやる  - 「こコード良くない」ような抽象的な言い方やめて、どこがどういう理由で良くないか書く   - 合わせて、どういう方法なら良いかも書けると議論もしやすい   - 定量的な指標もあったりするでそういうも活用すると良いかも   - テキストで指摘、結構キツく感じてしまいがちなで、普段 1.5倍やさしい言葉使いをしよう   - H (謙虚・尊敬・信頼) 原則   258 shumon.fujita 

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

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

+ パブリックリポジトリで無料で使える点がメリット。   また、汎用的な部分 GitHub で公開されている Action を利用することができることもありがたい。       261 shumon.fujita 

+ パブリックリポジトリで無料で使える点がメリット。   また、汎用的な部分 GitHub で公開されている Action を利用することができることもありがたい。     hook したいイベントとワークフローを書いた yaml を .github/workflows/ に配置すると、勝手に走ってくれる。     262 shumon.fujita 

+ パブリックリポジトリで無料で使える点がメリット。   また、汎用的な部分 GitHub で公開されている Action を利用することができることもありがたい。     hook したいイベントとワークフローを書いた yaml を .github/workflows/ に配置すると、勝手に走ってくれる。   → 具体的な書き方公式ドキュメントを読んでください。    263 shumon.fujita 

+ パブリックリポジトリで無料で使える点がメリット。   また、汎用的な部分 GitHub で公開されている Action を利用することができることもありがたい。     hook したいイベントとワークフローを書いた yaml を .github/workflows/ に配置すると、勝手に走ってくれる。   → 具体的な書き方公式ドキュメントを読んでください。    264 shumon.fujita 

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

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

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

やを付箋ようにタブを移動   させて進捗状況を可視化できる。     機能も少ないため、実際にあまり使っている部署ないかも（？）       268 shumon.fujita 

やを付箋ようにタブを移動   させて進捗状況を可視化できる。     機能も少ないため、実際にあまり使っている部署ないかも（？）   ZenHubという有料拡張ツールつかうとかなり便利になる。     269 shumon.fujita 

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

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

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

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

olicy  - ecurity Advisories  - Dependabot    ecurity olicy 脆弱性報告手順を arkdown で書いておく。         274 shumon.fujita 

olicy  - ecurity Advisories  - Dependabot    ecurity olicy 脆弱性報告手順を arkdown で書いておく。   ecurity Advisories 非公開 issue ようなもで、脆弱性が対策されるまで秘匿した状態で議論し、   対応パッチがリリースされると、そ議論を公開できる。       275 shumon.fujita 

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

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

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

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

  自分リポジトリでこタブを使うことあんまりない。       280 shumon.fujita 

  自分リポジトリでこタブを使うことあんまりない。     新しいライブラリやツール導入を検討しているとき、それが GitHub でホストされているならこタブを見ると、   どれくらいメンテされているかが一目瞭然なで、ぜ使ってみて。   281 shumon.fujita 

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

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

ecrets 登録、デフォルトブランチ変更、マージに関するルール設定など色々できる。     おそらく開発中に最もよく使う Branch protection rules。      284 shumon.fujita 

ecrets 登録、デフォルトブランチ変更、マージに関するルール設定など色々できる。     おそらく開発中に最もよく使う Branch protection rules。  指定した正規表現にマッチした branch に対して、を経ない直接 push や force push を禁止したり...etc       285 shumon.fujita 

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

ecrets 登録、デフォルトブランチ変更、マージに関するルール設定など色々できる。     おそらく開発中に最もよく使う Branch protection rules。  指定した正規表現にマッチした branch に対して、を経ない直接 push や force push を禁止したり...etc   master(main) と develop に、大体なんらかルールが設定されていると思う。     private → public 変更、オーナー権限委譲、リポジトリ削除など危険な操作もあるで注意。  287 shumon.fujita 

Git 内部構   288 shumon.fujita 

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

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

- commit って親 commit と差分を保存してるんでしょ  - branch って分かれた枝ことでしょ  - reset って commit をなかったことにするコマンドでしょ    ↑ 全部間違い    291 shumon.fujita 

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

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

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

コミット仕組み  295 shumon.fujita 

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

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

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

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

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

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

に登録している」     具体的に index どこにあるかというと、.git/index に保存されている。     302 コミット仕組み  shumon.fujita 

に登録している」     具体的に 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 

に登録している」     具体的に 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 

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

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

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

e2022389da0c18f0c8a0e2f9b27d58d197f41b32 0 README.md     308 コミット仕組み  shumon.fujita  ファイル種類  +  パーミッション 

e2022389da0c18f0c8a0e2f9b27d58d197f41b32 0 README.md     309 コミット仕組み  shumon.fujita  ファイル種類  +  パーミッション  blob ハッシュ(後述)  

e2022389da0c18f0c8a0e2f9b27d58d197f41b32 0 README.md     310 コミット仕組み  shumon.fujita  ファイル種類  +  パーミッション  blob ハッシュ(後述)   コンフリクトフラグ  (0ならコンフリクトなし) 

e2022389da0c18f0c8a0e2f9b27d58d197f41b32 0 README.md     311 コミット仕組み  shumon.fujita  ファイル種類  +  パーミッション  blob ハッシュ(後述)   コンフリクトフラグ  (0ならコンフリクトなし)  ファイル名 

e2022389da0c18f0c8a0e2f9b27d58d197f41b32 0 README.md   ファイル名と一緒に何やら色んな情報が出てくる。     312 コミット仕組み  shumon.fujita  ファイル種類  +  パーミッション  blob ハッシュ(後述)   コンフリクトフラグ  (0ならコンフリクトなし)  ファイル名 

e2022389da0c18f0c8a0e2f9b27d58d197f41b32 0 README.md   ファイル名と一緒に何やら色んな情報が出てくる。     ちなみに index 、ここに表示されていない情報も持っている。   313 コミット仕組み  shumon.fujita  ファイル種類  +  パーミッション  blob ハッシュ(後述)   コンフリクトフラグ  (0ならコンフリクトなし)  ファイル名 

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

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

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

Git に様々なデータを、「オブジェクト」と呼れる概念で表現している。     コミット仕組み  shumon.fujita 

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

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

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

324 オブジェクト実体 .git/objects 中に zlib で圧縮して保存されている。      

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

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

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

EAD E.md blob (e2022389da0c18f0c8a0e2f9b27d58d197f41b32) 中身を確認してみる。   $ cat README.md #
21 卒 Git 研修用リポジトリ $ cat .git/objects/e2/022389da0c18f0c8a0e2f9b27d58d197f41b32 | zlib d blob 38# 21 卒 Git 研修用リポジトリ 328 コミット仕組み 

21 卒 Git 研修用リポジトリ $ cat .git/objects/e2/022389da0c18f0c8a0e2f9b27d58d197f41b32 | zlib d blob 38# 21 卒 Git 研修用リポジトリファイル先頭に、オブジェクト種類とファイルサイズを付けたもを、zlib で圧縮している事が分かる。   329 コミット仕組み 

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

21 卒 Git 研修用リポジトリ $ cat .git/objects/e2/022389da0c18f0c8a0e2f9b27d58d197f41b32 | zlib d blob 38# 21 卒 Git 研修用リポジトリファイル先頭に、オブジェクト種類とファイルサイズを付けたもを、zlib で圧縮している事が分かる。   blobオブジェクトファイル差分でなくファイル中身そもを記録している事も分かる。   ちなみに、圧縮前状態 HA-1 が、こ blob を指す key になっている。   $ cat .git/objects/e2/022389da0c18f0c8a0e2f9b27d58d197f41b32 | zlib d | shasum e2022389da0c18f0c8a0e2f9b27d58d197f41b32 - 331 コミット仕組み 

21 卒 Git 研修用リポジトリ $ cat .git/objects/e2/022389da0c18f0c8a0e2f9b27d58d197f41b32 | zlib d blob 38# 21 卒 Git 研修用リポジトリファイル先頭に、オブジェクト種類とファイルサイズを付けたもを、zlib で圧縮している事が分かる。   blobオブジェクトファイル差分でなくファイル中身そもを記録している事も分かる。   ちなみに、圧縮前状態 HA-1 が、こ blob を指す key になっている。   $ cat .git/objects/e2/022389da0c18f0c8a0e2f9b27d58d197f41b32 | zlib d | shasum e2022389da0c18f0c8a0e2f9b27d58d197f41b32 - 332 コミット仕組み 

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

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

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

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

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

100644 e2022389da0c18f0c8a0e2f9b27d58d197f41b32 0 README.md $ echo hoge > hoge.txt   コミット仕組み  shumon.fujita 

100644 e2022389da0c18f0c8a0e2f9b27d58d197f41b32 0 README.md $ echo hoge > hoge.txt $ git add hoge.txt   コミット仕組み  shumon.fujita 

100644 e2022389da0c18f0c8a0e2f9b27d58d197f41b32 0 README.md $ echo hoge > hoge.txt $ git add hoge.txt $ git ls-files --stage   コミット仕組み  shumon.fujita 

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 

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 

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

mkdir fuga $ echo fuga > fuga/fuga.txt $ git add fuga/fuga.txt   345 コミット仕組み  shumon.fujita 

mkdir fuga $ echo fuga > fuga/fuga.txt $ git add fuga/fuga.txt $ git ls-files --stage   346 コミット仕組み  shumon.fujita 

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 

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

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 ディレクトリが追加されても tree オブジェクト作らず、blob オブジェクトしか作らない。   349 コミット仕組み  shumon.fujita 

350 blob オブジェクト add 時に、tree オブジェクト commit 時に生成する。    

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

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

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

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 

こんな感じ。   $ 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 

こんな感じ。   $ 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 

こんな感じ。   $ 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 が持っていた情報     コミット仕組み 

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

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

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

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

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

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

blob 及 tree オブジェクト   に書き換えられ、それ以外コピーされる。   tree オブジェクトを作ったら、次後述する   commit オブジェクトを作る。     コミット仕組み  https://git-scm.com/book/en/v2/Git-Internals-Git- bjects 

blob 及 tree オブジェクト   に書き換えられ、それ以外コピーされる。   tree オブジェクトを作ったら、次後述する   commit オブジェクトを作る。   commit オブジェクト、リポジトリルートにあたる   tree オブジェクトを参照していて、commit 時リポジトリ   状態を再現できるようになっている。       コミット仕組み  https://git-scm.com/book/en/v2/Git-Internals-Git- bjects 

blob 及 tree オブジェクト   に書き換えられ、それ以外コピーされる。   tree オブジェクトを作ったら、次後述する   commit オブジェクトを作る。   commit オブジェクト、リポジトリルートにあたる   tree オブジェクトを参照していて、commit 時リポジトリ   状態を再現できるようになっている。   => コミットある時点スナップショット         コミット仕組み  https://git-scm.com/book/en/v2/Git-Internals-Git- bjects 

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

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

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

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

ハッシュ   - 親 commit ハッシュ  - committer と author タイムスタンプ・名前・メアド   - コミットメッセージ  こうち、どれか 1 つでも変わると、( HA-1 が衝突しない限り)別 commit ハッシュになる。       コミット仕組み  shumon.fujita 

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

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

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

          コミット仕組み  コミット1  コミット2  コミット3  コミット4  shumon.fujita 

          コミット仕組み  コミット1  コミット2  コミット3  コミット4  こコミットを  改ざんしたい！  shumon.fujita 

          コミット仕組み  コミット1  コミット2  コミット3  コミット4  こコミットを  改ざんしたい！  親コミットハッシュが変わるで  parent を書き換える必要がある  shumon.fujita 

          コミット仕組み  コミット1  コミット2  コミット3  コミット4  こコミットを  改ざんしたい！  親コミットハッシュが変わるで  parent を書き換える必要がある  親コミットハッシュが変わるで  以下略  shumon.fujita 

          コミット仕組み  コミット1  コミット2  コミット3  コミット4  こコミットを  改ざんしたい！  親コミットハッシュが変わるで  parent を書き換える必要がある  親コミットハッシュが変わるで  以下略  結局元コミット4と   別物になってしまう  → 改ざん不可能  shumon.fujita 

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

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

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

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

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

？    HEAD 話をする前に、refs 話をする必要がある。(HEAD refs 一種)     コミット仕組み  shumon.fujita 

？    HEAD 話をする前に、refs 話をする必要がある。(HEAD refs 一種)   refs 特定 commit を指すポインタようなも。commit ハッシュエイリアスとも言える。     コミット仕組み  shumon.fujita 

？    HEAD 話をする前に、refs 話をする必要がある。(HEAD refs 一種)   refs 特定 commit を指すポインタようなも。commit ハッシュエイリアスとも言える。   具体的に ↓などが refs にあたる。   - tag  - branch  - HEAD  コミット仕組み  shumon.fujita 

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

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

weight tag 本当にただ特定 commit を指しているだけ。     $ git tag light-weight # オプションなしでタグを作ると light weight tag になる refs について  shumon.fujita 

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 

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 

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 

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

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

こと。   -a オプションで作ることができる。 $ git tag -a annotated -m "メッセージ" $ git log -n 1 --oneline 7c4c08d (HEAD -> master, tag: annotated) Merge branch 'develop'   refs について  shumon.fujita 

こと。   -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 

こと。   -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 

こと。   -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 

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

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

で圧縮して保存されている。   $ git cat-file -p e0114d0446b25c2c653fa5dd28c678602033c48b object 7c4c08d68be5a53406af4582a961a460b0db83cd type commit tag annotated tagger shumon84 <[email protected]> 1618330965 +0900 メッセージ   refs について  shumon.fujita 

で圧縮して保存されている。   $ git cat-file -p e0114d0446b25c2c653fa5dd28c678602033c48b object 7c4c08d68be5a53406af4582a961a460b0db83cd type commit tag annotated tagger shumon84 <[email protected]> 1618330965 +0900 メッセージ   refs について  shumon.fujita  object 欄に、tag が指している  commit ハッシュが書かれている 

で圧縮して保存されている。   $ git cat-file -p e0114d0446b25c2c653fa5dd28c678602033c48b object 7c4c08d68be5a53406af4582a961a460b0db83cd type commit tag annotated tagger shumon84 <[email protected]> 1618330965 +0900 メッセージ commit オブジェクトにちょっと似てる。   refs について  shumon.fujita  object 欄に、tag が指している  commit ハッシュが書かれている 

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

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

$ cat .git/refs/heads/master 7c4c08d68be5a53406af4582a961a460b0db83cd    refs について  shumon.fujita 

$ cat .git/refs/heads/master 7c4c08d68be5a53406af4582a961a460b0db83cd  保存場所が .git/refs/heads/ 以下になっているだけで、書かれている内容同じ。     refs について  shumon.fujita 

$ cat .git/refs/heads/master 7c4c08d68be5a53406af4582a961a460b0db83cd  保存場所が .git/refs/heads/ 以下になっているだけで、書かれている内容同じ。   指している commit ハッシュが直接書かれているだけ。     refs について  shumon.fujita 

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

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

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

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

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

HEAD が書き換わっている。   .git/HEAD に保存されている。   refs について  shumon.fujita 

HEAD が書き換わっている。   .git/HEAD に保存されている。   $ cat .git/HEAD ref: refs/heads/master   refs について  shumon.fujita 

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

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

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

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

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

を書き換える。     HEAD が直接 commit ハッシュを参照している場合       HEAD が branch を参照している場合     コミット仕組み  shumon.fujita 

を書き換える。     HEAD が直接 commit ハッシュを参照している場合   → HEAD commit ハッシュを書き換える     HEAD が branch を参照している場合     コミット仕組み  shumon.fujita 

を書き換える。     HEAD が直接 commit ハッシュを参照している場合   → HEAD commit ハッシュを書き換える     HEAD が branch を参照している場合   → HEAD が参照している branch commit ハッシュを書き換える   コミット仕組み  shumon.fujita 

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

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

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

編集したコードを add する   - index 更新  - blob オブジェクト生成  3. commit する  - tree オブジェクト生成  - commit オブジェクト生成   - HEAD 書き換え      コミット仕組みまとめ  shumon.fujita 

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

checkout, reset 仕組み  440 shumon.fujita 

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

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

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

、こ 2 つコマンド結構似たようなことをしている。     こ 2 つ、基本的に↓ 3 つを書き換えるコマンド。   - ワークツリー(作業ディレクトリ)   - index  - HEAD    checkout, reset 仕組み  shumon.fujita 

、こ 2 つコマンド結構似たようなことをしている。     こ 2 つ、基本的に↓ 3 つを書き換えるコマンド。   - ワークツリー(作業ディレクトリ)   - index  - HEAD  それぞれ見ていく。  checkout, reset 仕組み  shumon.fujita 

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

    1. 指定した commit が参照している tree をワークツリーに展開する。       checkout 仕組み  shumon.fujita 

    1. 指定した commit が参照している tree をワークツリーに展開する。   2. index をワークツリーと同期する(= tree と同じ状態にする)。       checkout 仕組み  shumon.fujita 

    1. 指定した commit が参照している tree をワークツリーに展開する。   2. index をワークツリーと同期する(= tree と同じ状態にする)。   3. HEAD を指定した commit に変更する。       checkout 仕組み  shumon.fujita 

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

451 reset 、オプションによって挙動が変わる。             reset

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

オプションがある。   指定した commit ハッシュに向けて、それぞれ内容を書き換える。             reset 仕組み  shumon.fujita 

オプションがある。   指定した commit ハッシュに向けて、それぞれ内容を書き換える。             reset 仕組み  shumon.fujita    HEAD  index  ワークツリー  git reset --soft <commit ハッシュ> 書き換える      git reset --mixed <commit ハッシュ> 書き換える  書き換える    git reset --hard <commit ハッシュ> 書き換える  書き換える  書き換える 

オプションがある。   指定した commit ハッシュに向けて、それぞれ内容を書き換える。           --hard 全部書き換えるし、checkout と違いある？     reset 仕組み  shumon.fujita    HEAD  index  ワークツリー  git reset --soft <commit ハッシュ> 書き換える      git reset --mixed <commit ハッシュ> 書き換える  書き換える    git reset --hard <commit ハッシュ> 書き換える  書き換える  書き換える 

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

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 

                reset 仕組み  shumon.fujita  first commit  master.txt を追加  EAD E.md に  「master」と追記  develop.txt を追加  master  EAD E.md に  「develop」と追記  develop  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 

      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 

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

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

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

つ前 commit ハッシュに branch を向けることで、最新コミットをなかったことにできる。   ② add 取り消し      reset 仕組み  shumon.fujita 

つ前 commit ハッシュに branch を向けることで、最新コミットをなかったことにできる。   ② add 取り消し  git reset --mixed HEAD とすると、index を HEAD 状況に戻せるで、add を取り消すことができる。       reset 仕組み  shumon.fujita 

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

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

Git Challenge に挑戦  468 shumon.fujita 

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

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

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

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

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

Git Challenge に挑戦  475 shumon.fujita 

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

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

Transcript