こわくない 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 = 早送り

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 で作られたコミットは元のコミットと同じ内容だけど別のコミットになります!!

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 に追従するときに使ってます !!　マージはなんか怖いし…

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 の理解の手助けになれたでしょうか？

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/

こわくない Git

こわくない Git

Recommended

More Related Content

What's hot

What's hot(20)

Viewers also liked

Viewers also liked(20)

Recently uploaded

Recently uploaded(12)

こわくない Git