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

1. こわくない
Presented by Kota Saito @ksaito

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

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

4. ＼怖くないよ／

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

6. コミットとブランチ

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

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

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

10. コミット A があれば

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

12. A
B
C

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

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

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

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

18. new = master イマココ!!
old

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

20. new! = master イマココ!!
old

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

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

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

24. できる!!

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

26. git branch topic master

27. git branch topic master
master から topic を作る

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

29. new = master イマココ!!
old

30. git branch topic master
してみると……
new = master
old

31. !?
new = master = topic
old

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

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

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

35. new! = topic 伸びた!!
= master
old

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

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

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

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

40. 二種類のマージ

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

42. Fast-Forward
and
Non Fast-Forward

43. Fast-Forward = 早送り

44. ?

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

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

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

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

49. 3 = topic = master
2
1
!?

50. 3 = topic
2
1
= master
←これが

51. 3 = topic = master
2 ここに↑
1 移動しただけ

52. Why?

53. topic = master + 1 + 2 + 3
master

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

55. topic = master + 1 + 2 + 3
master + 1 + 2 + 3 = topic

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

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

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

59. これが Fast-Forward

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

61. ＼ﾄﾞﾔｧ…／

62. Non Fast-Forward

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

64. = master
= topic
枝分かれ!!

65. マージ後の master ≠ topic

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

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

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

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

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

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

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

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

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

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

76. Non Fast-Forward

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

78. ＼ﾄﾞﾔﾔﾔｧ…／

79. ちなみに

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

81. ところが

82. 議論がある

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

84. ＼えっ／

85. Why?

86. 3 = topic = master
2
1
早送りした後の状態から
を消すと…
topic

87. 3 = master
2
1
ん？

88. 3 = master
2
1
あれ？

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

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

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

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

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

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

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

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

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

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

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

100. リベースの功罪

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

102. リベーーーーーース
git rebase

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

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

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

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

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

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

109. 差分を適用してコミット 1
2 = master = topic
1

110. A ← 1 から作られたコミット
2 = master = topic
1

111. A = topic
2 = master
1

112. 2
A = topic
2 = master
1

113. B ← 2 から作られたコミット
A = topic
2 = master
1

114. B = topic
A
2 = master
1

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

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

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

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

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

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

121. Point
rebaseで作られるコミットは
元のコミットとは別物

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

123. git push origin topic

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

125. local origin
2 = topic
push
1

126. local origin
2 = topic 2 = topic
1 1

127. local origin
3 = topic
2 commit 2 = topic
1 1

128. local origin
3 = topic
push
2 2 = topic
1 1

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

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

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

132. local origin
3 = topic
2 2 = topic
1 1

133. local origin
3 = topic 3 = topic
2 2 よし、2番の
後ろに追加
1 1

134. local origin
3 = topic 3 = topic
2 2
1 1

135. push after rebase

136. local origin
2 = topic 2 = topic
1 1
0 0

137. local origin
B = topic 2 = topic
A rebase 1
0 0

138. local origin
B = topic 2 = topic
push
A 1
0 0

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

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

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

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

143. local origin
ダメダメ!!
受け付けないよ!!
B = topic 2 = topic
A 1
0 0

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

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

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

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

148. ＼怖くないよ／

150. M git merge master

151. M

152. M git merge master
M

153. M
M

154. M git merge topic
M
M

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

156. Point
git のマージは
相当かしこい

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

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

159. 確かに一直線でキレイ

160. お気づきだろうか…

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

162. マージの記録は残らない

163. えっ
M M M

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

183. ＼怖くないよ／

184. ＼ズッ友だょ……!!／

185. Have a Nice Git!

186. References
Pro Git book
http://git-scm.com/book/ja/
git merge or rebase, ff or no-ff - Togetter
http://togetter.com/li/407277
A successful Git branching model
http://nvie.com/posts/a-successful-git-
branching-model/