Gitの社内勉強会資料

1. sh-ogawa

2. 今日はカジュアルに緩くいきたいので
目次はありません

3. 質問は思ったときに
以下に書き込んでください
（後で直接聞いていただいてもOKです）
https://www.sli.do
event code：1188

4. 本日の目標

5. Gitに踏み出す勇気を身に着ける
(๑•̀ㅂ•́) ‫و‬✧

6. と、僕のことを覚えてください
（これが最重要事項です）

8. ・ユーザ企業主導のデジタルビジネス案件への適応
・複数バージョンの並行開発で、
マージ作業で疲弊したくない
・ Maven、Gradleなどとの親和性の高さ
(antで疲弊したくない)
・良い技術者を取り込むにはSVNでは不十分
開発効率を楽に上げる必要がある

10. 分散型バージョン管理システムです！

11. What’s 分散型バージョン管理システム？

12. その前にSVNをおさらい

13. SVNリポジトリ
開発者A 開発者B 開発者C

14. SVNは複数の開発者が１つのリポジトリに対して
直接コミットしたりアップデートしたりする。

15. 以下の面で生きづらさを感じる
・自分のミスが他人に影響する
（逆も然り）
・結果、自由にコミットできない
・コミット漏れが起きる
・意味のあるコミット単位にならない
・元に戻すのに一苦労
負の連鎖

16. こんな実話があってだな・・・

17. 有給取って彼女と夢の国で遊んでいた
ある日・・・

18. 突然会社から電話が

19. 用件
「○○君がしたコミットが原因で
コンパイルできなくてなって
皆困ってるから何とかして！」

20. 夢の国からリモートでログインして
現実の作業をカタカタカタ・・・
コミット

21. この間放置された彼女ぶち切れ
(((( ；ﾟДﾟ)))ｶﾞｸｶﾞｸﾌﾞﾙﾌﾞﾙ

22. この後、修羅場・・・

23. そうならない為にも
分散型バージョン管理システムを使おう！

24. Gitのモデルはこんな感じ

25. GITリモート
リポジトリ
開発者A 開発者B 開発者C
GITローカル
リポジトリ

26. リモートリポジトリに変更を反映するためには
ローカルリポジトリに変更を反映しておく
必要がある

28. ・日々の作業の記録は
ローカルリポジトリにコミット
・開発がひと段落したら
ローカルリポジトリにコミット後、
リモートリポジトリに反映

29. SVN的な使い方ならこれだけで十分！

30. だけど、これだけだとGitを使う恩恵は１割くらい
（これだけでもSVNを辞める理由になるけど）

31. Gitの恩恵を最大限に受けるには、
ブランチの運営がカギになる！

32. こんな声が聞こえてきそう

33. ・ブランチ切るのに時間かかる
・マージが大変
・そもそも何処から切ったブランチか忘れた

34. ・ブランチ切るのに時間かかる
・マージが大変
・そもそも何処から切ったブランチか忘れた
→こんなの問題になりません。

35. だって仕組みが違う！

36. SVNはブランチなんて考え方
システム上に存在しませんから！
あくまでも利用者の知恵から
生まれたものですから！

37. Gitははじめからブランチを使うことを
前提としたシステムのため、
効率化されたプロダクトになっています。

38. Gitのコミットはメタ情報です

39. データとしては以下みたいな感じで持ってます
コミット:519df74785bc78f7aa4c0168eeb08a19fa67fca4
親: 7f5d6fbcbf
作者: sh-ogawa <ogawa.shogo@tis.co.jp>
日時: 2016年3月1日 22:19:20
コミットメッセージ：
modify: Catch EmptyFileException

40. 親のブランチがどこかを知っているため、
・戻し先が判らず迷子にならない
・戻し先が判っているからこそ、
システム的にマージがしやすい

41. Gitにおけるブランチはというと・・・

42. GITのブランチの仕組みは以下を参照してください
[3.1 Git のブランチ機能 - ブランチとは]
https://git-scm.com/book/ja/v1/Git-
%E3%81%AE%E3%83%96%E3%83%A9%E3%83%B3%E3%
83%81%E6%A9%9F%E8%83%BD-
%E3%83%96%E3%83%A9%E3%83%B3%E3%83%81%E3%
81%A8%E3%81%AF

43. 超要約すると、
・ブランチはコミットに対して
判りやすいラベル（別名）を付ける
・そこから別分岐にする
・どこから切ったかも覚えといてあげる
・その代りディスク容量使わせろ
SVNと異なり、物理的なファイルができないから高速

44. ついでに言うと、
タグもコミットに別名を付けているだけなので、
一瞬でタグが付きます

46. 管
理
リポジトリ ブランチ・タグ ブランチのマージ
GIT 分
散
型
ローカル
リモート
の２本立て
断面から生成するため、
すぐに終わる
戻し先を知っているため、
楽チン
※運用ルールが複雑だと
当てはまらない
SVN 中
央
集
権
型
リモート
のみ
物理ファイルのコピー
を作るため、
くっそ時間がかかる
親子関係がないため、
エクセル管理台帳などで
ファイルを１つずつマー
ジするため、苦痛

48. エンジニアならコマンド叩け！

49. とは別に言いません

50. GUIツールはこれを使おう

51. SoureTree
https://www.sourcetreeapp.com/
IDEとかエディタと同梱が良い場合は、
IntelliJとかAtomがおススメ

52. ちょっと重たいけど、
GITのデファクトスタンダードなGUIツールです

53. EclipseとかTortoiseGitを使うのは
辞めておいた方が吉

54. 今がどうかは知らないけど、
リポジトリをぶっ壊したとか
よくない話しか聞いたことがない

55. SoureTreeの使い方

57. ・新規 / クローンを作成する
→リモートリポジトリを作成したり、
リモートリポジトリからローカルリポジトリ
を作成する（クローンする）
・コミット
→ローカルリポジトリにコミットする
・破棄
→変更を取り消して、最後のコミットの状態に
戻す。（ファイル指定、一括取り消し）
・スタッシュ
→現在の変更をコミットせずに
一時的な状態として保存しておく
※GITに慣れたら使えば良い

58. ・フェッチ
→リモートリポジトリの変更点を取ってくる
（作業領域に反映はしない）
・プル
→リモートリポジトリの変更点を取って反映する
（フェッチ + マージが走る）
・プッシュ
→ローカルリポジトリにコミットした内容を
リモートリポジトリに反映する
・ブランチ
→指定コミットからブランチを作る
・マージ
→指定のブランチから別のブランチ
（原則親ブランチ）へ変更をマージする

59. ・タグ
→ローカルリポジトリのコミットに対して
タグを付ける
付けたタグはリモートリポジトリへ
プッシュが可能。
・Git Flow
→Gitのブランチ名のつけ方を定義する
（開発ルールでブランチ名のつけ方を決める
から、あまり使わない）
・Explorer
→エクスプローラを表示する
・ターミナル
→MINGW32ターミナルを開く
（Linuxコマンド打てるくらい）

61. ・GitHubがないと使えない
→そんなことはない。
Gitが入ったサーバがあれば良い。
GitHubはあくまでもGUIのサポートツール。
・learningコストがかかる
→ブランチ運営する場合は、確かにかかるが、
SVN的な使い方をすればコストはほぼ不要。
・事例がないから使いづらい
→TISでも事例多数なので、
社内にGit使いは結構います。聞きましょう。
(もちろん僕を頼ってもらっても良いですよ！)

63. git-svnを使う
（gitの標準ツール）

64. 詳しくは以下を参照（簡単に移行できる）
http://dqn.sakusakutto.jp/2012/10/svn-git-
github-migration.html

65. git svn pullは時間がかかると
タイムアウトしてしまうため、
git svn fetchでのんびり移行しよう

66. １人Gitするときは以下のような感じでやると
事故らず安心して貪れます
（用法用量を守ってお使いください）
SVNリポジトリ
git svn
ローカルPC
Gitローカルリポジトリ
git clone
Gitリモートリポジトリ
ここで
貪る！

68. ・ブランチ作るのに疲弊しない
・ブランチ間のマージが容易
・開発者間でモジュールの受け渡しが容易
・ソフトの受け入れが楽
・他の開発者のミスで影響を受けない
（有給中に電話来ない）
・必然的に意味のあるコミット単位になる
・CIするのに向いている

70. ・自由度が高すぎる

71. 詳しくは以下にSVNとの比較をしつつ書いているので
参照していただければと思います。
[Subversionを使用し続けているプロジェクトがGitに
移行することを考えてみた]
http://qiita.com/sh-
ogawa/items/0bac2516d85e3db4dfd8

72. Gitの運用方法を知りたい人は
以下を見ると良いです。
[Git実践入門]
https://www.slideshare.net/syobochim/20160128
-jjug-nightgit
[マスタリングビルド職人]
https://uga.gitbooks.io/mastering-
builder/content/

73. ご静聴ありがとうございました！