こわくない Git

こわくないPresented by Kota Saito @ksaito

こんな人が対象者一応ブランチ作ってコミットしてるけど実は、マージとかよくわかってない…… エラーが出た時に対処できない…… rebase しちゃダメって何でなの？

Git よくわかんない！怖い!!

＼怖くないよ／

#1 コミットとブランチ#2 二種類のマージ#3 リベースの功罪

コミットとブランチ

そもそも、コミットってなんだっけ……？

コミットに入ってる情報リビジョン (SHA-1 ハッシュ) 例: 23cdd334e6e251336ca7dd34e0f6e3ea08b5d0db Author (コミットを作成した人) 例: オープンソースプロジェクトにパッチを送った人 Committer (コミットを適用した人) 例: 受け取ったパッチを取り込んだ人ファイルのスナップショット (tree) コミットで変更されたファイルを含むツリー（説明は省略） 1つ前のコミットのリビジョン例: 4717e3cf182610e9e82940ac45abb0d422a76d77

コミットに入ってる情報リビジョン (SHA-1 ハッシュ) 例: 23cdd334e6e251336ca7dd34e0f6e3ea08b5d0db Author (コミットを作成した人) 例: オープンソースプロジェクトにパッチを送った人 Committer (コミットを適用した人) これ重要!! 例: 受け取ったパッチを取り込んだ人ファイルのスナップショット (tree) コミットで変更されたファイルを含むツリー（説明は省略） 1つ前のコミットのリビジョン例: 4717e3cf182610e9e82940ac45abb0d422a76d77

コミット A があれば

コミット A があればその前の B をたどれる

最新のコミットたどれる!!最古のコミット

この概念＝コミットグラフ＼テストに出るぞ／

で、ブランチってなんだっけ……？

new 例えば master にコミットが4回されたあとのこんなコミットグラフold

new = master イマココ!!old

new さらに master にもう1回コミットがされると…old

new! = master イマココ!!old

つまり =ブランチは最新コミットの別名!!

ブランチ名の代わりにリビジョンを指定したりgit checkout -b foo master =git checkout -b foo 4717e3cf1826

リビジョンの代わりにブランチ名を指定したり git show 4717e3cf1826 = git show master

できる!!

あれ？枝分かれするブランチの話は？てか、masterってブランチだったのか

git branch topic master

git branch topic mastermaster から topic を作る

例えば master にnew コミットが3回されたあとのこんなコミットグラフold

new = master イマココ!!old

git branch topic master してみると……new = masterold

!?new = master = topicold

つまり = = ブランチを作る＝コミットのさらなる別名を作る

枝分かれしてなくね？スルーですか？

この状態から topic にコミットしてみると……new = master = topicold

new! = topic 伸びた!! = masterold

master にコミットしてみると…new! = topic = masterold

new! = master = topic 枝分かれ!!old

Point初めてコミットした時点で枝分かれになります。

コミットとブランチ・コミットには「1つ前のコミット」が　含まれるので、最古までたどっていける　→ コミットグラフ・ブランチは、そのブランチでの　最新のコミットの別名に過ぎない・枝分かれは、それぞれのブランチで　コミットされて初めて発生する

二種類のマージ

Questiongitのマージには 2種類ある事知ってましたか？

Fast-Forward andNon Fast-Forward

Fast-Forward = 早送り

例えばこんなコミットグラフ = topic= master

topic ブランチに3回コミットした 3 = topic 2 1= master

git merge topic 3 = topic2 1 マージ!!= master

git merge topic 3 = topic2 1 マージ!! グラフはどうなる？= master

3 = topic = master21 !?

3 = topic2 1= master ←これが

3 = topic = master2 ここに↑1 移動しただけ

topic = master + 1 + 2 + 3master

topic = master + 1 + 2 + 3 マージ!!master + 1 + 2 + 3 = ?

topic = master + 1 + 2 + 3master + 1 + 2 + 3 = topic

topic = master + 1 + 2 + 3マージ後の master = topic

中の人「どうせ同じ内容になるならいちいちマージしなくてよくね？」

中の人「マージ後に topic と同じ内容になるなら topic のところまで進めちゃおうぜww」 3 = topic = master 2 1 進める = master

これが Fast-Forward

Fast-Forwardマージのかわりに早送り。

＼ﾄﾞﾔｧ…／

Non Fast-Forward

さっきのコミットグラフから　　　にコミットすると…master = topic= master

= master = topic 枝分かれ!!

マージ後の master ≠ topic

中の人「早送りできない＞＜」

中の人「ちゃんとマージするかー」

git merge topic= master 3 = topic 2 1 マージ!!

〜中の人計算中〜「えーと master の内容と　topic のコミットを比較して…」「衝突してたら教えてあげなきゃ…」

master + 1 + 2 + 3中の人「全部まぜちゃえー」

master + 1 + 2 + 3 = M中の人「マージ結果ができたよ！」

= master 3 = topic 2 M 1 中の人「そぉい!!」

M = master ＜スポッ 3 = topic 2 1

M = master ←マージの結果　作られたコミット 3 = topic 2 1

M = master ←マージの結果　作られたコミットマージコミット 3 = topic 2 1 ＼テストに出るぞ／

Non Fast-Forward

Non Fast-Forward早送りじゃないマージ。

＼ﾄﾞﾔﾔﾔｧ…／

ちなみに

git merge topicFast-Forward Non Fast-Forward早送りできればする、無理なら普通のマージgit merge --no-ff topic Non Fast-Forward常に普通のマージgit merge --ff-only topic Fast-Forward常に早送りする（できなければエラーとする）

ところが

議論がある

常に git merge --no-ff すべきだ！訳: 早送りマージすんな！

＼えっ／

3 = topic = master21 早送りした後の状態からを消すと… topic

3 = master21 ん？

3 = master21 あれ？

= master 直接コミットしたのと変わらない!!

＼　　　の霊圧が消えた…!?／ topic = master

Fast-Forward の弊害①「ブランチをマージした」という事実が歴史（コミットグラフ）に残らない

= master おっと、間違ってマージしちゃった (＞ω･)

= master えーと、マージを元に戻すにはっと…

git revert <commit><commit> (リビジョン) のコミットを取り消すためのコミットを作るgit reset --hard <commit><commit> (リビジョン) 時点の状態まで完全に巻き戻す

= master おｋおｋコミットを指定すればいいのか

= master で、どれが topic のコミットだっけ……

Fast-Forward の弊害② 「ブランチのマージ」を取り消しづらい

Pointマージの種類を意識してマージしましょう！

二種類のマージ・Fast-Forward = 早送り　・コミットグラフ的に結果が同じなら　　同じコミットまで進めてしまうこと　・「マージした」という記録が残らない　・マージを取り消しづらい・Non Fast-Forward = 普通のマージ　・Git ががんばって計算するマージ

リベースの功罪

git 初心者が陥りがちな罠第1位（個人的に）

リベーーーーーースgit rebase

ブランチを master に追従するときに使ってます!!　マージはなんか怖いし… rebase すると、コミットログがキレイになって見やすいよね!! merge よりも rebase の方がマージコミットもなくて楽でしょ?

Questionそもそも rebase がなにをするのか理解していますか？

2 = master1 2 = topic 1 topic この状態から　　　　　で git rebase master すると…

topic 2 2 1 1まず、コミットの変更内容をそれぞれパッチにする

2 = master = topic1 移動 2 = topic 1 次に topic を master と同じコミットに移動させる（元々の topic ブランチでの　変更は含まなくなる）

ここまで来たら、作っておいたパッチを1つずつ順に適用してコミットしていく2 = master = topic1 1 2 （　　と　　は省略）

差分を適用してコミット 12 = master = topic1

A ← 1 から作られたコミット2 = master = topic1

A = topic2 = master1

2 A = topic2 = master1

B ← 2 から作られたコミット A = topic2 = master1

B = topic A2 = master1

重要 2 B 1 ≠ Arebase で作られたコミットは元のコミットと同じ内容だけど別のコミットになります!!

重要 2 B 1 ≠ A 本当？rebase で作られたコミットは元のコミットと同じ内容だけど別のコミットになります!!

コミットに入ってる情報リビジョン (SHA-1 ハッシュ) 例: 23cdd334e6e251336ca7dd34e0f6e3ea08b5d0db Author (コミットを作成した人) 例: オープンソースプロジェクトにパッチを送った人 Committer (コミットを適用した人) 例: 受け取ったパッチを取り込んだ人ファイルのスナップショット (tree) コミットで変更されたファイルを含むツリー（説明は省略） 1つ前のコミットのリビジョン例: 4717e3cf182610e9e82940ac45abb0d422a76d77

2 B 1 A 21つ前のコミットが違う!!

2 B 1 A 21つ前のコミットが変わるとリビジョンも変わります（だから別物になる）

Pointrebaseで作られるコミットは元のコミットとは別物

別物でも、同じ変更がされるから問題ない気が

git push origin topic

git push origin topic topic を origin (サーバー) に同期

local origin2 = topic push1

local origin2 = topic 2 = topic1 1

local origin3 = topic2 commit 2 = topic1 1

local origin3 = topic push2 2 = topic1 1

origin「お、pushがきたぞ？どれどれ、内容を見てみよう」

origin「新しいコミットは1つだけか」 3「さて、こいつの前のコミットは…」

3 2origin「お、2番なら知ってるぞ！」

local origin3 = topic2 2 = topic1 1

local origin3 = topic 3 = topic2 2 よし、2番の後ろに追加1 1

local origin3 = topic 3 = topic2 21 1

push after rebase

local origin2 = topic 2 = topic1 10 0

local originB = topic 2 = topicA rebase 10 0

local originB = topic 2 = topic pushA 10 0

origin「お、pushがきたぞ？どれどれ、内容を見てみよう」

origin「新しいコミットは2つか」 B A「さて、こいつの前のコミットは…」

B A 0origin「あれ？ 0番か…」

B 2 A 1 0 0origin「もう0番には次のコミットがあるし、1とAはリビジョンも違う!!」

local origin ダメダメ!! 受け付けないよ!!B = topic 2 = topicA 10 0

Pointpush されているブランチを rebase すると push できなくなる

Pointよって、共有のブランチではrebase してはいけない !!

push -f ダメ! 絶対!! push -f で強制的に上書き push できますが他の人が pull する時にマージする必要があったりコミットログがおかしな事になるのでやめましょう

ブランチを master に追従するときに使ってます !!　マージはなんか怖いし…

M git merge master

M git merge masterM

M git merge topic M M

M M 　　と　　で衝突する修正を M しない限り、マージ時には一切コンフリクトしません！

Pointgit のマージは相当かしこい

rebase すると、コミットログがキレイになって見やすいよね!!

M M この一連の流れを M もし rebase でやっていると

確かに一直線でキレイ

お気づきだろうか…

ﾋｿﾋｿ…（なあ、もしかして　俺たち忘れられてないか？） M M M

マージの記録は残らない

えっM M M

Pointrebase でコミットグラフは一直線にキレイになるがその陰で失われる情報がある

Point そもそも git で入り組んだグラフになってもそんなに気にすることはない

merge よりも rebase の方がマージコミットもなくて楽でしょ?

ここから git rebase master すると… ←a.txtの1行目を修正a.txtの1行目を修正→ ←a.txtの1行目を修正

コミットがそれぞれパッチになって… 2a.txtの1行目を修正→ 1

1つ目のパッチを適用 a.txtの1行目を修正するパッチ1つ目↓ 1a.txtの1行目を修正→

コンフリクト！ a.txtの1行目を修正するパッチ1つ目↓ 1a.txtの1行目を修正→

コンフリクトを解消 ←a.txtの1行目を修正a.txtの1行目を修正→

2つ目のパッチを適用 a.txtの1行目を修正するパッチ2つ目↓ 2 ←a.txtの1行目を修正a.txtの1行目を修正→

コンフリクト！ a.txtの1行目を修正するパッチ2つ目↓ 2 ←a.txtの1行目を修正a.txtの1行目を修正→

コンフリクトを解消 ←a.txtの1行目を修正 ←a.txtの1行目を修正a.txtの1行目を修正→

Point rebase だとコミットそれぞれについてコンフリクトの解消が必要

ちなみに git merge master だと… ←a.txtの1行目を修正a.txtの1行目を修正→ ←a.txtの1行目を修正

コンフリクトを解消 M ←a.txtの1行目を修正a.txtの1行目を修正→ ←a.txtの1行目を修正

Point merge だとコミットがいくつあろうとコンフリクト解消は1回だけ

Point したがってrebase よりもむしろmerge の方が楽です

リベースの功罪 Good・コミットグラフがキレイになる　→ マージ後のログがキレイになるので　　 master にマージする直前にやるのは　　 OK とする事がある　→ GitHub などのオープンソースプロジェクトに　　プルリクエストを送る場合は　　 rebase してから送るのがマナーとされている

リベースの功罪 Bad・push されたブランチをリベースすると　push できなくなる・「マージした」という事実は失われる・マージに比べるとコンフリクト解消が面倒

すこしは git の理解の手助けになれたでしょうか？

＼ズッ友だょ……!!／

Have a Nice Git!

ReferencesPro Git bookhttp://git-scm.com/book/ja/git merge or rebase, ff or no-ff - Togetterhttp://togetter.com/li/407277A successful Git branching modelhttp://nvie.com/posts/a-successful-git-branching-model/

http://programmerbox.com	52639
http://www.find-job.net	51960
http://kotas.hatenablog.jp	25516
http://morizyun.github.io	21186
http://d.hatena.ne.jp	17366
http://blog.inouetakuya.info	7213
http://nanapi.jp	4716
http://kesin.hatenablog.com	1935
http://mituoh.com	1596
https://twitter.com	1549
http://hiroki.jp	1536
https://bozuman.cybozu.com	1050
http://localhost	609
http://blog.kzfmix.com	500
http://www.kobedenshi.ac.jp	481
http://tech.shuntak.net	453
http://yumulog.hatenablog.com	404
https://ocean.cybozu-dev.com	384
http://bikkuri.me	348
http://blog.livedoor.jp	317
http://256interns.com	304
https://cybozulive.com	256
http://10.226.20.170	233
http://jabropt.hatenablog.com	230
http://www.advertimes.com	230
http://under-siege.jugem.jp	222
http://dstrikes.net	218
http://amewiki.cadc.cyberagent.local	205
http://feedly.com	172
http://find-job.net	166
http://ec2-54-248-240-57.ap-northeast-1.compute.amazonaws.com	137
http://hajipion.com	126
http://inouetakuya.hatenablog.com	116
http://www.pochi.cc	113
http://www.studytech.jp	108
http://webcache.googleusercontent.com	108
http://s.deeeki.com	107
http://cloud.feedly.com	104
http://of.studio23c.com	99
http://dev.fanclub_eternal.com	97
https://bozuman.s.cybozu.com	92
http://notes.shuntak.net	91
http://www.feedspot.com	88
http://tc-redmine.tky.nri-net.com	73
http://sasa1010.hatenablog.com	70
http://on-your-mark-i.blogspot.jp	69
http://www.google.co.jp	51
https://melalu.office-devel	46
http://asklife.info	46
http://labs.asunochikara.com	46

こわくない Git

by Kota Saito

on Nov 21, 2012

Statistics

Views

Actions

147 Embeds 196,743

Accessibility

Categories

Upload Details

Usage Rights

Report content

こわくない Git Presentation Transcript