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.
Upcoming SlideShare
いつやるの?Git入門
いつやるの?Git入門
Loading in …3
×
1 of 186

こわくない Git

1951

Share

Download to read offline

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

Related Books

Free with a 30 day trial from Scribd

See all

Related Audiobooks

Free with a 30 day trial from Scribd

See all

こわくない 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. A B C
  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 master master から topic を作る
  27. 27. 例えば master に new コミットが3回されたあとの こんなコミットグラフ old
  28. 28. new = master イマココ!! old
  29. 29. git branch topic master してみると…… new = master old
  30. 30. !? new = master = topic old
  31. 31. つまり = = ブランチを作る= コミットのさらなる別名を作る
  32. 32. 枝分かれしてなくね? スルーですか?
  33. 33. この状態から topic に コミットしてみると…… new = master = topic old
  34. 34. new! = topic 伸びた!! = master old
  35. 35. master にコミットしてみると… new! = topic = master old
  36. 36. new! = master = topic 枝分かれ!! old
  37. 37. Point 初めてコミットした時点で 枝分かれになります。
  38. 38. コミットとブランチ ・コミットには「1つ前のコミット」が  含まれるので、最古までたどっていける  → コミットグラフ ・ブランチは、そのブランチでの  最新のコミットの別名に過ぎない ・枝分かれは、それぞれのブランチで  コミットされて初めて発生する
  39. 39. 二種類のマージ
  40. 40. Question gitのマージには 2種類ある事 知ってましたか?
  41. 41. Fast-Forward and Non 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 = topic 2 1 マージ!! = master
  47. 47. git merge topic 3 = topic 2 1 マージ!! グラフはどうなる? = master
  48. 48. 3 = topic = master 2 1 !?
  49. 49. 3 = topic 2 1 = master ←これが
  50. 50. 3 = topic = master 2 ここに↑ 1 移動しただけ
  51. 51. Why?
  52. 52. topic = master + 1 + 2 + 3 master
  53. 53. topic = master + 1 + 2 + 3 マージ!! master + 1 + 2 + 3 = ?
  54. 54. topic = master + 1 + 2 + 3 master + 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 topic Fast-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 = master 2 1 早送りした後の状態から      を消すと… topic
  86. 86. 3 = master 2 1 ん?
  87. 87. 3 = master 2 1 あれ?
  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 = master 1 2 = topic 1 topic この状態から     で git rebase master すると…
  105. 105. topic 2 2 1 1 まず、コミットの変更内容を それぞれパッチにする
  106. 106. 2 = master = topic 1 移動 2 = topic 1 次に topic を master と 同じコミットに移動させる (元々の topic ブランチでの  変更は含まなくなる)
  107. 107. ここまで来たら、作っておいた パッチを1つずつ順に適用して コミットしていく 2 = master = topic 1 1 2 (  と  は省略)
  108. 108. 差分を適用してコミット 1 2 = master = topic 1
  109. 109. A ← 1 から作られたコミット 2 = master = topic 1
  110. 110. A = topic 2 = master 1
  111. 111. 2 A = topic 2 = master 1
  112. 112. B ← 2 から作られたコミット A = topic 2 = master 1
  113. 113. B = topic A 2 = master 1
  114. 114. 重要 2 B 1 ≠ A rebase で作られたコミットは 元のコミットと同じ内容だけど 別のコミットになります!!
  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 2 1つ前のコミットが違う!!
  119. 119. 2 B 1 A 2 1つ前のコミットが変わると リビジョンも変わります (だから別物になる)
  120. 120. Point rebaseで作られるコミットは 元のコミットとは別物
  121. 121. 別物でも、同じ変更が されるから問題ない気が
  122. 122. git push origin topic
  123. 123. git push origin topic topic を origin (サーバー) に同期
  124. 124. local origin 2 = topic push 1
  125. 125. local origin 2 = topic 2 = topic 1 1
  126. 126. local origin 3 = topic 2 commit 2 = topic 1 1
  127. 127. local origin 3 = topic push 2 2 = topic 1 1
  128. 128. origin「お、pushがきたぞ? どれどれ、内容を見てみよう」
  129. 129. origin「新しいコミットは1つだけか」 3 「さて、こいつの前のコミットは…」
  130. 130. 3 2 origin「お、2番なら知ってるぞ!」
  131. 131. local origin 3 = topic 2 2 = topic 1 1
  132. 132. local origin 3 = topic 3 = topic 2 2 よし、2番の 後ろに追加 1 1
  133. 133. local origin 3 = topic 3 = topic 2 2 1 1
  134. 134. push after rebase
  135. 135. local origin 2 = topic 2 = topic 1 1 0 0
  136. 136. local origin B = topic 2 = topic A rebase 1 0 0
  137. 137. local origin B = topic 2 = topic push A 1 0 0
  138. 138. origin「お、pushがきたぞ? どれどれ、内容を見てみよう」
  139. 139. origin「新しいコミットは2つか」 B A 「さて、こいつの前のコミットは…」
  140. 140. B A 0 origin「あれ? 0番か…」
  141. 141. B 2 A 1 0 0 origin「もう0番には次のコミットが あるし、1とAはリビジョンも違う!!」
  142. 142. local origin ダメダメ!! 受け付けないよ!! B = topic 2 = topic A 1 0 0
  143. 143. Point push されているブランチを 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 master M
  151. 151. M M
  152. 152. M git merge topic M M
  153. 153. M M   と  で衝突する修正を M しない限り、マージ時には 一切コンフリクトしません!
  154. 154. Point git のマージは 相当かしこい
  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. Point rebase でコミットグラフは 一直線にキレイになるが その陰で失われる情報がある
  163. 163. Point そもそも git で 入り組んだグラフになっても そんなに気にすることはない
  164. 164. merge よりも rebase の方が マージコミット もなくて楽でし ょ?
  165. 165. ここから git rebase master すると… ←a.txtの1行目を修正 a.txtの1行目を修正→ ←a.txtの1行目を修正
  166. 166. コミットがそれぞれパッチになって… 2 a.txtの1行目を修正→ 1
  167. 167. 1つ目のパッチを適用 a.txtの1行目を修正するパッチ1つ目↓ 1 a.txtの1行目を修正→
  168. 168. コンフリクト! a.txtの1行目を修正するパッチ1つ目↓ 1 a.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. 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/

×