こわくない Git
•
1,958 likes•897,470 views
「マージがなんとなく怖い」「リベースするなって怒られて怖い」「エラーが出て怖い」 Git 入門者にありがちな「Git 怖い」を解消するため、Git のお仕事（コミット、ブランチ、マージ、リベース）について解説します。
More Related Content
What's hot (20)
Viewers also liked (20)
Recently uploaded (9)
![ElasticsearchでSPLADEする [Search Engineering Tech Talk 2025 Winter]](https://cdn.slidesharecdn.com/ss_thumbnails/searchtech-250228102455-ddc5ce09-thumbnail.jpg?width=560&fit=bounds)
こわくない Git
- 1. こわくない Presented by Kota Saito @ksaito
- 2. こんな人が対象者 一応ブラン チ作ってコミットしてるけど 実は、マー ジとかよくわかってない…… エラーが出た時に対処できない…… rebase しちゃダ メって何でな の？
- 3. Git よくわかんない！ 怖い!!
- 4. ＼怖くないよ／
- 5. #1 コミットとブランチ #2 二種類のマージ #3 リベースの功罪
- 6. コミットとブランチ
- 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. 最新のコミット たどれる!! 最古のコミット
- 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. できる!!
- 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. つまり = = ブランチを作る＝ コミットのさらなる別名を作る
- 34. この状態から topic に コミットしてみると…… new = master = topic old
- 35. new! = topic 伸びた!! = master old
- 36. master にコミットしてみると… new! = topic = master old
- 37. new! = master = topic 枝分かれ!! old
- 40. 二種類のマージ
- 42. Fast-Forward and Non 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
- 58. 中の人「マージ後に topic と同じ内容になるなら topic のところまで進めちゃおうぜww」 3 = topic = master 2 1 進める = master
- 59. これが 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
- 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
- 92. = master おっと、間違って マージしちゃった (＞ω･)
- 93. = master えーと、マージを 元に戻すにはっと…
- 94. git revert <commit> <commit> (リビジョン) のコミットを 取り消すためのコミットを作る git reset --hard <commit> <commit> (リビジョン) 時点の状態まで 完全に巻き戻す
- 95. = master おｋおｋ コミットを指定すればいいのか
- 96. = master で、どれが topic の コミットだっけ……
- 97. Fast-Forward の弊害② 「ブランチのマージ」を 取り消しづらい
- 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つ前のコミットが変わると リビジョンも変わります （だから別物になる）
- 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
- 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
- 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 できなくなる
- 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 しない限り、マージ時には 一切コンフリクトしません！
- 158. M M この一連の流れを M もし rebase でやっていると
- 159. 確かに一直線でキレイ
- 160. お気づきだろうか…
- 161. ﾋｿﾋｿ… （なあ、もしかして 俺たち忘れられてないか？） M M M
- 162. マージの記録は残らない
- 163. えっ M M M
- 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/