こわくない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    おkおk    コミットを指定すればいいのか
=   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

424,722

Published on

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

Published in: Technology
14 Comments
1.4k Likes
Statistics
Notes
No Downloads
Views
Total Views
424,722
On Slideshare
0
From Embeds
0
Number of Embeds
161
Actions
Shares
0
Downloads
2,202
Comments
14
Likes
1,435
Embeds 0
No embeds

No notes for slide

こわくない 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 おkおk コミットを指定すればいいのか
  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/
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×