仕事のつらみ説得用資料です Gitの何がいいの、SVNでいいじゃない、という人には見てほしいです

1. SVNからGitへ
乗り換えてほしい話
2021/2/4
takeyamami

2. まず、はじめに
この資料は非エンジニアにGitに
移行したい気持ちを伝えるための資料です
厳密には、正確には、というところは
割愛・省略しますのでご了承ください

3. 早速ですが、
みなさん、バージョン管理ツール使ってますか？

4. CVS？SVN？Git？
それとも、男は黙って共有サーバ管理？
VSSも使ってたんですよ～

5. ちょっと化石みたいなものは置いておいて
SVNとGit何が違うの？
というのを簡単に説明したうえで
実際の業務の例を織り交ぜて
Gitにしてほしいことをアピールします

6. そもそも、バージョン管理ツールってなに？
 誰が、いつ、何をどのように修正したかといった履歴情報とコードを
一緒に管理するツール
 SVNやGitなどが有名
 今やこれなしに複数人での開発は考えられない

7. バージョン管理ツールがないとき
修正中

8.  同時に複数人が同じファイルを修正できない
 他の人の修正内容がわからず、誤って消してしまうかもしれない
 修正内容を元に戻したり、消したファイルを復元することができない
（難しい、大変！！）
バージョン管理ツールがないとき

9. バージョン管理ツールがあるとき
チェックアウト
チェックアウト

10. バージョン管理ツールがあるとき
修正中
修正中

11. バージョン管理ツールがあるとき
コミット
修正中

12.  同時に複数人が修正できる
 他の人の修正内容がすぐわかる（誰が、いつ、何をしたかまで！）
 修正内容を元に戻したり、消したファイルを元に戻すことが簡単
バージョン管理ツールがあるとき

13. じゃあ、バージョン管理ツールって
どうやって履歴情報を管理しているの？

14. SVNとGitの違い
※イメージつきやすいように細かいところは省いてます

15. SNVはコミットやマージ、更新するたびに、
前のリビジョンの状態に対して、差分を計算して
最新のファイル状態を管理している

16. Gitはコミットするときに、修正したファイルの
スナップショットを保持

17. じゃあ、いっぱいコミットしたPJのコードを
別のブランチにマージしようって
なったらどうなるか

18. SVNの場合（本当にあった怖い話）
ブランチB
ブランチA
コミット１
Rev.301
コミット2
Rev.303
コミット3
Rev.305
コミット4
Rev.307
コミット5
Rev.308
コミットa
Rev.302
コミットb
Rev.304
コミットc
Rev.306
コミット0
Rev.300

19. SVNの場合（本当にあった怖い話）
ブランチB
ブランチA
コミット１
Rev.301
コミット2
Rev.303
コミット3
Rev.305
コミット4
Rev.307
コミット5
Rev.308
コミットa
Rev.302
コミットb
Rev.304
コミットc
Rev.306
コミットd
Rev.309
コミット１～５をマージしてコミットしたい！！
コミット0
Rev.300

20. SVNの場合（本当にあった怖い話）
ブランチB
ブランチA
コミット１
Rev.301
コミット2
Rev.303
コミット3
Rev.305
コミット4
Rev.307
コミット5
Rev.308
コミットa
Rev.302
コミットb
Rev.304
コミットc
Rev.306
コミットd
Rev.309
コミット１の修正内容が競合し、マージできず！
conflict
コミット0
Rev.300

21. SVNの場合（本当にあった怖い話）
ブランチB
ブランチA
コミット１
Rev.301
コミット2
Rev.303
コミット3
Rev.305
コミット4
Rev.307
コミット5
Rev.308
コミットa
Rev.302
コミットb
Rev.304
コミットc
Rev.306
コミットd
Rev.309
競合を解消する
OK
コミット0
Rev.300

23. SVNの場合（本当にあった怖い話）
ブランチB
ブランチA
コミット１
Rev.301
コミット2
Rev.303
コミット3
Rev.305
コミット4
Rev.307
コミット5
Rev.308
コミットa
Rev.302
コミットb
Rev.304
コミットc
Rev.306
コミットd
Rev.309
再度マージをする
OK
コミット0
Rev.300

24. SVNの場合（本当にあった怖い話）
ブランチB
ブランチA
コミット１
Rev.301
コミット2
Rev.303
コミット3
Rev.305
コミット4
Rev.307
コミット5
Rev.308
コミットa
Rev.302
コミットb
Rev.304
コミットc
Rev.306
コミットd
Rev.309
コミット2の修正内容が競合し、マージできず！
OK conflict
コミット0
Rev.300

26. お察しの通り
このあと、幾度となくコミットごとの
競合を解消していった

27. SVNの場合（本当にあった怖い話）
ブランチB
ブランチA
コミット１
Rev.301
コミット2
Rev.303
コミット3
Rev.305
コミット4
Rev.307
コミット5
Rev.308
コミットa
Rev.302
コミットb
Rev.304
コミットc
Rev.306
コミットd
Rev.309
すべての競合を解消し、マージ完了後
ああ、やっと、コミット
OK OK OK OK OK
コミット0
Rev.300

28. 差分しか持っていないSVNでは、
複数のリビジョンを選択してマージする場合でも
一つずつ計算してそのコミット時点の
ファイルの状態を作成し、
マージできるかどうかチェックする

29. そのため、一つでも競合が発生すると、
以降のリビジョンのマージはされず
マージ⇒チェック⇒競合発生⇒競合の解消
⇒残りをマージ⇒チェック⇒競合発生⇒・・・
といったことが起きてしまう

30. じゃあ、これがGitだったら、どうなっていたか

31. Gitの場合（仮定の話）
ブランチB
ブランチA
コミット１
親：0
コミット2
親：1
コミット3
親：2
コミット4
親：3
コミット5
親：4
コミットa
親：0
コミットb
親：a
コミットc
親：b
コミット0
親：#
コミットd
親：5とb
ブランチBをマージしてコミットしたい！！（プルリク）

32. Gitの場合（仮定の話）
ブランチB
ブランチA
コミット１
親：0
コミット2
親：1
コミット3
親：2
コミット4
親：3
コミット5
親：4
コミットa
親：0
コミットb
親：a
コミットc
親：b
コミット0
親：#
コミットd
親：5とb
コミット5の修正内容で競合が発生
※コミット1～4の修正内容も堆積したものが競合している
conflict

33. Gitの場合（仮定の話）
ブランチB
ブランチA
コミット１
親：0
コミット2
親：1
コミット3
親：2
コミット4
親：3
コミット5
親：4
コミットa
親：0
コミットb
親：a
コミットc
親：b
コミット0
親：#
コミットd
親：5とb
競合を解消し、コミット
OK

34. Gitでは、コミットした時点の情報だけでなく、
親コミットの修正内容込み込みで
変更履歴を保持している
マージできるかチェックの際に
確認するファイルの状態は
それまでの変更内容がすべて含まっている

35. そのため、マージ作業は1回で済む！！！

36. 競合はもちろん、Gitでも起きてしまう
でも、もう一度言う

37. マージ作業は1回で済む！！！

38. これによって、みんな（主にエンジニア）が
ものすごくハッピーになる

39. この例は競合が５回のパタンだったけど、
もし、競合が10、20回だったら、、、

40. マージしているときに本当に集中したいのは、
競合の解消作業であって、
SVNが必死に時間をかけてチェックしたり、
何度も何度も競合と向き合わないといけない
時間は無駄でしかない

41. さあ、Gitへ