Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
こわくないPresented by Kota Saito @ksaito
こんな人が対象者一応ブラン チ作ってコミットしてるけど実は、マー ジとかよくわかってない…… エラーが出た時に対処できない…… rebase しちゃダ メって何でな の？
Git よくわかんない！ 怖い!!
＼怖くないよ／
#1 コミットとブランチ#2 二種類のマージ#3 リベースの功罪
コミットとブランチ
そもそも、コミットってなんだっけ……？
コミットに入ってる情報 リビジョン (SHA-1 ハッシュ) 例: 23cdd334e6e251336ca7dd34e0f6e3ea08b5d0db Author (コミットを作成した人) 例: オープンソースプロジェクトにパッチを送った人 C...
コミットに入ってる情報 リビジョン (SHA-1 ハッシュ) 例: 23cdd334e6e251336ca7dd34e0f6e3ea08b5d0db Author (コミットを作成した人) 例: オープンソースプロジェクトにパッチを送った人 C...
コミット A があれば
コミット A があればその前の B をたどれる
ABC
最新のコミット たどれる!!最古のコミット
この概念＝コミットグラフ ＼テストに出るぞ／
で、ブランチってなんだっけ……？
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 移動しただけ
Why?
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 ...
これが 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 = ...
Non Fast-Forward
Non Fast-Forward早送りじゃないマージ。
＼ﾄﾞﾔﾔﾔｧ…／
ちなみに
git merge topicFast-Forward Non Fast-Forward早送りできればする、無理なら普通のマージgit merge --no-ff topic ...
ところが
議論がある
常に git merge --no-ff すべきだ！ 訳: 早送りマージすんな！
＼えっ／
Why?
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 初心者が陥りがちな罠 第1位 （個人的に）
リベーーーーーースgit rebase
ブランチ を master に追従するときに使ってま す!!　マージはなんか怖いし… rebase すると、コミットログが キレイになって見やすいよね!! merge よりも rebase の方が マージコミット ...
Questionそもそも rebase が なにをするのか理解していますか？
2 = master1 2 = topic 1 topic この状態から　　　　　...
topic 2 2 1 1まず、コミットの変更内容をそれぞれパッチにする
2 = master = topic1 移動 2 = topic 1 次に topic を ma...
ここまで来たら、作っておいた パッチを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 (コミットを作成した人) 例: オープンソースプロジェクトにパッチを送った人 C...
コミットに入ってる情報 リビジョン (SHA-1 ハッシュ) 例: 23cdd334e6e251336ca7dd34e0f6e3ea08b5d0db Author (コミットを作成した人) 例: オープンソースプロジェクトにパッチを送った人 C...
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 ...
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...
Pointpush されているブランチを rebase すると push できなくなる
Pointよって、共有のブランチではrebase してはいけない !!
push -f ダメ! 絶対!! push -f で強制的に上書き push できますが他の人が pull する時にマージする必要があったりコミットログがおかしな事になるのでやめましょう
ブ ランチを master に追従するときに使ってます !!　マージはなんか怖いし…
＼怖くないよ／
M git merge master
M
M git merge masterM
MM
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 などのオープンソースプロジェクトに　　 ...
リベースの功罪 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...
こわくない Git
こわくない Git
Upcoming SlideShare
Loading in …5
×

こわくない Git

884,504 views

Published on

「マージがなんとなく怖い」「リベースするなって怒られて怖い」「エラーが出て怖い」
Git 入門者にありがちな「Git 怖い」を解消するため、Git のお仕事（コミット、ブランチ、マージ、リベース）について解説します。

Published in: Technology
no profile picture user

  • Login to see the comments

Show More

こわくない Git

  1. 1. こわくないPresented by Kota Saito @ksaito
  2. 2. こんな人が対象者一応ブラン チ作ってコミットしてるけど実は、マー ジとかよくわかってない…… エラーが出た時に対処できない…… rebase しちゃダ メって何でな の？
  3. 3. Git よくわかんない！ 怖い!!
  4. 4. ＼怖くないよ／
  5. 5. #1 コミットとブランチ#2 二種類のマージ#3 リベースの功罪
  6. 6. コミットとブランチ
  7. 7. そもそも、コミットってなんだっけ……？
  8. 8. コミットに入ってる情報 リビジョン (SHA-1 ハッシュ) 例: 23cdd334e6e251336ca7dd34e0f6e3ea08b5d0db Author (コミットを作成した人) 例: オープンソースプロジェクトにパッチを送った人 Committer (コミットを適用した人) 例: 受け取ったパッチを取り込んだ人 ファイルのスナップショット (tree) コミットで変更されたファイルを含むツリー（説明は省略） 1つ前のコミットのリビジョン 例: 4717e3cf182610e9e82940ac45abb0d422a76d77
  9. 9. コミットに入ってる情報 リビジョン (SHA-1 ハッシュ) 例: 23cdd334e6e251336ca7dd34e0f6e3ea08b5d0db Author (コミットを作成した人) 例: オープンソースプロジェクトにパッチを送った人 Committer (コミットを適用した人) これ重要!! 例: 受け取ったパッチを取り込んだ人 ファイルのスナップショット (tree) コミットで変更されたファイルを含むツリー（説明は省略） 1つ前のコミットのリビジョン 例: 4717e3cf182610e9e82940ac45abb0d422a76d77
  10. 10. コミット A があれば
  11. 11. コミット A があればその前の B をたどれる
  12. 12. ABC
  13. 13. 最新のコミット たどれる!!最古のコミット
  14. 14. この概念＝コミットグラフ ＼テストに出るぞ／
  15. 15. で、ブランチってなんだっけ……？
  16. 16. new 例えば master に コミットが4回されたあとの こんなコミットグラフold
  17. 17. new = master イマココ!!old
  18. 18. new さらに master にもう1回 コミットがされると…old
  19. 19. new! = master イマココ!!old
  20. 20. つまり =ブランチは最新コミットの別名!!
  21. 21. ブランチ名の代わりにリビジョンを指定したりgit checkout -b foo master =git checkout -b foo 4717e3cf1826
  22. 22. リビジョンの代わりにブランチ名を指定したり git show 4717e3cf1826 = git show master
  23. 23. できる!!
  24. 24. あれ？ 枝分かれするブランチの話は？てか、masterってブランチだったのか
  25. 25. git branch topic master
  26. 26. git branch topic mastermaster から topic を作る
  27. 27. 例えば master にnew コミットが3回されたあとの こんなコミットグラフold
  28. 28. new = master イマココ!!old
  29. 29. git branch topic master してみると……new = masterold
  30. 30. !?new = master = topicold
  31. 31. つまり = = ブランチを作る＝コミットのさらなる別名を作る
  32. 32. 枝分かれしてなくね？スルーですか？
  33. 33. この状態から topic に コミットしてみると……new = master = topicold
  34. 34. new! = topic 伸びた!! = masterold
  35. 35. master にコミットしてみると…new! = topic = masterold
  36. 36. new! = master = topic 枝分かれ!!old
  37. 37. Point初めてコミットした時点で枝分かれになります。
  38. 38. コミットとブランチ・コミットには「1つ前のコミット」が　含まれるので、最古までたどっていける　→ コミットグラフ・ブランチは、そのブランチでの　最新のコミットの別名に過ぎない・枝分かれは、それぞれのブランチで　コミットされて初めて発生する
  39. 39. 二種類のマージ
  40. 40. Questiongitのマージには 2種類ある事知ってましたか？
  41. 41. Fast-Forward andNon Fast-Forward
  42. 42. Fast-Forward = 早送り
  43. 43. ?
  44. 44. 例えばこんなコミットグラフ = topic= master
  45. 45. topic ブランチに3回コミットした 3 = topic 2 1= master
  46. 46. git merge topic 3 = topic2 1 マージ!!= master
  47. 47. git merge topic 3 = topic2 1 マージ!! グラフはどうなる？= master
  48. 48. 3 = topic = master21 !?
  49. 49. 3 = topic2 1= master ←これが
  50. 50. 3 = topic = master2 ここに↑1 移動しただけ
  51. 51. Why?
  52. 52. topic = master + 1 + 2 + 3master
  53. 53. topic = master + 1 + 2 + 3 マージ!!master + 1 + 2 + 3 = ?
  54. 54. topic = master + 1 + 2 + 3master + 1 + 2 + 3 = topic
  55. 55. topic = master + 1 + 2 + 3マージ後の master = topic
  56. 56. 中の人「どうせ同じ内容になるならいちいちマージしなくてよくね？」
  57. 57. 中の人「マージ後に topic と同じ内容になるなら topic のところまで進めちゃおうぜww」 3 = topic = master 2 1 進める = master
  58. 58. これが Fast-Forward
  59. 59. Fast-Forwardマージのかわりに早送り。
  60. 60. ＼ﾄﾞﾔｧ…／
  61. 61. Non Fast-Forward
  62. 62. さっきのコミットグラフから　　 　にコミットすると…master = topic= master
  63. 63. = master = topic 枝分かれ!!
  64. 64. マージ後の master ≠ topic
  65. 65. 中の人「早送りできない＞＜」
  66. 66. 中の人「ちゃんとマージするかー」
  67. 67. git merge topic= master 3 = topic 2 1 マージ!!
  68. 68. 〜中の人計算中〜「えーと master の内容と　topic のコミットを比較して…」 「衝突してたら教えてあげなきゃ…」
  69. 69. master + 1 + 2 + 3中の人「全部まぜちゃえー」
  70. 70. master + 1 + 2 + 3 = M中の人「マージ結果ができたよ！」
  71. 71. = master 3 = topic 2 M 1 中の人「そぉい!!」
  72. 72. M = master ＜スポッ 3 = topic 2 1
  73. 73. M = master ←マージの結果 　作られたコミット 3 = topic 2 1
  74. 74. M = master ←マージの結果 　作られたコミット マージコミット 3 = topic 2 1 ＼テストに出るぞ／
  75. 75. Non Fast-Forward
  76. 76. Non Fast-Forward早送りじゃないマージ。
  77. 77. ＼ﾄﾞﾔﾔﾔｧ…／
  78. 78. ちなみに
  79. 79. git merge topicFast-Forward Non Fast-Forward早送りできればする、無理なら普通のマージgit merge --no-ff topic Non Fast-Forward常に普通のマージgit merge --ff-only topic Fast-Forward常に早送りする（できなければエラーとする）
  80. 80. ところが
  81. 81. 議論がある
  82. 82. 常に git merge --no-ff すべきだ！ 訳: 早送りマージすんな！
  83. 83. ＼えっ／
  84. 84. Why?
  85. 85. 3 = topic = master21 早送りした後の状態から      を消すと… topic
  86. 86. 3 = master21 ん？
  87. 87. 3 = master21 あれ？
  88. 88. = master 直接コミットしたのと 変わらない!!
  89. 89. ＼　　　 の霊圧が消えた…!?／ topic = master
  90. 90. Fast-Forward の弊害①「ブランチをマージした」という事実が 歴史（コミットグラフ）に残らない
  91. 91. = master おっと、間違って マージしちゃった (＞ω･)
  92. 92. = master えーと、マージを 元に戻すにはっと…
  93. 93. git revert <commit><commit> (リビジョン) のコミットを取り消すためのコミットを作るgit reset --hard <commit><commit> (リビジョン) 時点の状態まで完全に巻き戻す
  94. 94. = master おｋおｋ コミットを指定すればいいのか
  95. 95. = master で、どれが topic の コミットだっけ……
  96. 96. Fast-Forward の弊害② 「ブランチのマージ」を 取り消しづらい
  97. 97. Pointマージの種類を意識してマージしましょう！
  98. 98. 二種類のマージ・Fast-Forward = 早送り　・コミットグラフ的に結果が同じなら　　同じコミットまで進めてしまうこと　・「マージした」という記録が残らない　・マージを取り消しづらい・Non Fast-Forward = 普通のマージ　・Git ががんばって計算するマージ
  99. 99. リベースの功罪
  100. 100. git 初心者が陥りがちな罠 第1位 （個人的に）
  101. 101. リベーーーーーースgit rebase
  102. 102. ブランチ を master に追従するときに使ってま す!!　マージはなんか怖いし… rebase すると、コミットログが キレイになって見やすいよね!! merge よりも rebase の方が マージコミット もなくて楽でし ょ?
  103. 103. Questionそもそも rebase が なにをするのか理解していますか？
  104. 104. 2 = master1 2 = topic 1 topic この状態から　　　　　で git rebase master すると…
  105. 105. topic 2 2 1 1まず、コミットの変更内容をそれぞれパッチにする
  106. 106. 2 = master = topic1 移動 2 = topic 1 次に topic を master と 同じコミットに移動させる （元々の topic ブランチでの 　変更は含まなくなる）
  107. 107. ここまで来たら、作っておいた パッチを1つずつ順に適用して コミットしていく2 = master = topic1 1 2 （　　と　　は省略）
  108. 108. 差分を適用してコミット 12 = master = topic1
  109. 109. A ← 1 から作られたコミット2 = master = topic1
  110. 110. A = topic2 = master1
  111. 111. 2 A = topic2 = master1
  112. 112. B ← 2 から作られたコミット A = topic2 = master1
  113. 113. B = topic A2 = master1
  114. 114. 重要 2 B 1 ≠ Arebase で作られたコミットは元のコミットと同じ内容だけど別のコミットになります!!
  115. 115. 重要 2 B 1 ≠ A 本当？rebase で作られたコミットは元のコミットと同じ内容だけど別のコミットになります!!
  116. 116. コミットに入ってる情報 リビジョン (SHA-1 ハッシュ) 例: 23cdd334e6e251336ca7dd34e0f6e3ea08b5d0db Author (コミットを作成した人) 例: オープンソースプロジェクトにパッチを送った人 Committer (コミットを適用した人) 例: 受け取ったパッチを取り込んだ人 ファイルのスナップショット (tree) コミットで変更されたファイルを含むツリー（説明は省略） 1つ前のコミットのリビジョン 例: 4717e3cf182610e9e82940ac45abb0d422a76d77
  117. 117. コミットに入ってる情報 リビジョン (SHA-1 ハッシュ) 例: 23cdd334e6e251336ca7dd34e0f6e3ea08b5d0db Author (コミットを作成した人) 例: オープンソースプロジェクトにパッチを送った人 Committer (コミットを適用した人) 例: 受け取ったパッチを取り込んだ人 ファイルのスナップショット (tree) コミットで変更されたファイルを含むツリー（説明は省略） 1つ前のコミットのリビジョン 例: 4717e3cf182610e9e82940ac45abb0d422a76d77
  118. 118. 2 B 1 A 21つ前のコミットが違う!!
  119. 119. 2 B 1 A 21つ前のコミットが変わると リビジョンも変わります （だから別物になる）
  120. 120. Pointrebaseで作られるコミットは 元のコミットとは別物
  121. 121. 別物でも、同じ変更がされるから問題ない気が
  122. 122. git push origin topic
  123. 123. git push origin topic topic を origin (サーバー) に同期
  124. 124. local origin2 = topic push1
  125. 125. local origin2 = topic 2 = topic1 1
  126. 126. local origin3 = topic2 commit 2 = topic1 1
  127. 127. local origin3 = topic push2 2 = topic1 1
  128. 128. origin「お、pushがきたぞ？どれどれ、内容を見てみよう」
  129. 129. origin「新しいコミットは1つだけか」 3「さて、こいつの前のコミットは…」
  130. 130. 3 2origin「お、2番なら知ってるぞ！」
  131. 131. local origin3 = topic2 2 = topic1 1
  132. 132. local origin3 = topic 3 = topic2 2 よし、2番の 後ろに追加1 1
  133. 133. local origin3 = topic 3 = topic2 21 1
  134. 134. push after rebase
  135. 135. local origin2 = topic 2 = topic1 10 0
  136. 136. local originB = topic 2 = topicA rebase 10 0
  137. 137. local originB = topic 2 = topic pushA 10 0
  138. 138. origin「お、pushがきたぞ？どれどれ、内容を見てみよう」
  139. 139. origin「新しいコミットは2つか」 B A「さて、こいつの前のコミットは…」
  140. 140. B A 0origin「あれ？ 0番か…」
  141. 141. B 2 A 1 0 0origin「もう0番には次のコミットがあるし、1とAはリビジョンも違う!!」
  142. 142. local origin ダメダメ!! 受け付けないよ!!B = topic 2 = topicA 10 0
  143. 143. Pointpush されているブランチを rebase すると push できなくなる
  144. 144. Pointよって、共有のブランチではrebase してはいけない !!
  145. 145. push -f ダメ! 絶対!! push -f で強制的に上書き push できますが他の人が pull する時にマージする必要があったりコミットログがおかしな事になるのでやめましょう
  146. 146. ブ ランチを master に追従するときに使ってます !!　マージはなんか怖いし…
  147. 147. ＼怖くないよ／
  148. 148. M git merge master
  149. 149. M
  150. 150. M git merge masterM
  151. 151. MM
  152. 152. M git merge topic M M
  153. 153. M M 　　と　　で衝突する修正を M しない限り、マージ時には 一切コンフリクトしません！
  154. 154. Pointgit のマージは相当かしこい
  155. 155. rebase すると、コミットログがキレイになって見やすいよね!!
  156. 156. M M この一連の流れを M もし rebase でやっていると
  157. 157. 確かに一直線でキレイ
  158. 158. お気づきだろうか…
  159. 159. ﾋｿﾋｿ…（なあ、もしかして　俺たち忘れられてないか？） M M M
  160. 160. マージの記録は残らない
  161. 161. えっM M M
  162. 162. Pointrebase でコミットグラフは 一直線にキレイになるがその陰で失われる情報がある
  163. 163. Point そもそも git で入り組んだグラフになってもそんなに気にすることはない
  164. 164. merge よりも rebase の方がマージコミット もなくて楽でし ょ?
  165. 165. ここから git rebase master すると… ←a.txtの1行目を修正a.txtの1行目を修正→ ←a.txtの1行目を修正
  166. 166. コミットがそれぞれパッチになって… 2a.txtの1行目を修正→ 1
  167. 167. 1つ目のパッチを適用 a.txtの1行目を修正するパッチ1つ目↓ 1a.txtの1行目を修正→
  168. 168. コンフリクト！ a.txtの1行目を修正するパッチ1つ目↓ 1a.txtの1行目を修正→
  169. 169. コンフリクトを解消 ←a.txtの1行目を修正a.txtの1行目を修正→
  170. 170. 2つ目のパッチを適用 a.txtの1行目を修正するパッチ2つ目↓ 2 ←a.txtの1行目を修正a.txtの1行目を修正→
  171. 171. コンフリクト！ a.txtの1行目を修正するパッチ2つ目↓ 2 ←a.txtの1行目を修正a.txtの1行目を修正→
  172. 172. コンフリクトを解消 ←a.txtの1行目を修正 ←a.txtの1行目を修正a.txtの1行目を修正→
  173. 173. Point rebase だとコミットそれぞれについてコンフリクトの解消が必要
  174. 174. ちなみに git merge master だと… ←a.txtの1行目を修正a.txtの1行目を修正→ ←a.txtの1行目を修正
  175. 175. コンフリクトを解消 M ←a.txtの1行目を修正a.txtの1行目を修正→ ←a.txtの1行目を修正
  176. 176. Point merge だとコミットがいくつあろうとコンフリクト解消は1回だけ
  177. 177. Point したがってrebase よりもむしろmerge の方が楽です
  178. 178. リベースの功罪 Good・コミットグラフがキレイになる　→ マージ後のログがキレイになるので　　 master にマージする直前にやるのは　　 OK とする事がある　→ GitHub などのオープンソースプロジェクトに　　 プルリクエストを送る場合は　　 rebase してから送るのがマナーとされている
  179. 179. リベースの功罪 Bad・push されたブランチをリベースすると　push できなくなる・「マージした」という事実は失われる・マージに比べるとコンフリクト解消が面倒
  180. 180. すこしは git の 理解の手助けになれたでしょうか？
  181. 181. ＼怖くないよ／
  182. 182. ＼ズッ友だょ……!!／
  183. 183. Have a Nice Git!
  184. 184. 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/

×