非エンジニアに捧ぐツアーオブ構成管理
sh-ogawa
仰々しいタイトル付けたけど、
構成管理一周しません!
1. 何で構成管理をしたいのかポイントを抑える
2. Gitの基本を覚えて、軽い気持ちで使えるようになる
本日の目標
1. 構成管理ナニソレオイシイノ?をおいし~~~!と言える
2. Gitとは的なやつが判る
これを聞くと何が判る?
構成管理ツール使ったことある人、
挙手!
こんな経験ない?
・日付ファイルが増えていく
・日付振られてるけど、古いやつが更新されている・・・
・知らぬ間に仕様の記述が変わってるけど、誰がやったか判らない
・最新どこ・・・?
エンジニア界隈あるある
偉い人:(σ⊿ ̄)プログラムと突き合せて最新化して
エンジニア:
(#`皿´)シネクソオオオオオオオ!コンナノエンジニアノシゴトジャネエエエエエエエ!
構成管理をすると、
少なくとも日付ファイルは消えます。
ファイルは1つしかないですが、
データベースが履歴を保持してくれています。
保存されている履歴は好きなタイミングで、
ファイル自体を参照したり、元に戻せます。
なので、
+ ファイルの最新を見失わない
+ いつ誰がどんな変更を加えたのかが判る
+ ファイルが無駄に増えない
なので、
+ ファイルの最新を見失わない
+ いつ誰がどんな変更を加えたのかが判る
+ ファイルが無駄に増えない
というメリットがあります。
昭和のオッサンが日付ファイルを増やして
構成管理に追加してくれることもありますが。。
そういう場合は・・・
はい、若かりし頃にちゃんと数人駆逐しました
@SIer時代
構成管理の種類
+ 中央集権型(VSSから始まり、CVS、SVN)
+ 分散型(Git、Mercurial、Bazaar)
中央集権型
+ 1つのサーバーに全履歴を保存
+ 皆で確実に最新ドキュメント・ソ
ースを共有
構成管理の種類と特徴
分散型
+ 各人のPCで全履歴を保存
+ 中央のハブサーバー経由で皆と
ドキュメント・ソースを共有
SVN(中央)とGit(分散)でイメージを比較
今時点で
中央集権型と分散型、どちらの方が良さそうですか?
時間がないので説明は端折りますが、
分散型の方が便利です。
時間がないので説明は端折りますが、
分散型の方が便利です。
ただ、「便利 = 簡単」という構図にはならいのですが。。
余談ですが、
初めから分散型を使っている人にとっては、
中央集権型を使うのは余裕です。
が、、、
中央集権型から分散型を使うのは、
難しいとされています。
というか実際難しいです(経験者)
※ツールの特性も大なり小なりあると思うけど、
考え方の刷新を求められる
中央集権型
中央のサーバーから
ローカルディレクトリにコピー
してるだけ。
中央から分散を習得するのが難しい理由
分散型
リポジトリの状態はBLOBにし
てGitの内部DBに保持。
これをローカルディレクトリに
展開
詳しいことは後で出てきますが、
中央集権型しか使っていないサブバー脳(今付けた)は、
分散型は黒魔法に見えちゃうから頭がパニくります。
詳しいことは後で出てきますが、
中央集権型しか使っていないサブバー脳(今付けた)は、
分散型は黒魔法に見えちゃうから頭がパニくります。
※自分もそうだったし、周りも皆そんな感じだった
1. ファイルの履歴を保存しておける
2. 履歴はいつでも引き出せる
3.構成管理ツールには、中央集権型と分散型がある
4. 中央から分散に行くのは勉強が必要
5. 分散から中央に行くのは何もしなくて大丈夫
小まとめ(構成管理)
1. ファイルの履歴を保存しておける
2. 履歴はいつでも引き出せる
3.構成管理ツールには、中央集権型と分散型がある
4. 中央から分散に行くのは勉強が必要
5. 分散から中央に行くのは何もしなくて大丈夫
6. 構成管理をちゃんと使えないオジサンは駆逐してイイ
まとめ(構成管理)
What’s git
+ バージョン管理システム
+ 分散型
+ 他人のことなんて気にする必要はないよ
バージョン管理システム
先ほど話した変更履歴を保存して、
いつでも引き出せる便利なモノ。
SVNとかCVSとかVSSの
中央集権型でお馴染み。
中央集権型は旧型
プログラムの開発においては、
スピードが出ない。
※未だに中央集権型を使った開発を
しているところは、世間から取り残され
ている
なぜか・・・
なぜか・・・
中央集権型で
周りと強調しないといけないから
元々遅い!
じゃあ分散型のGitは?
実は新型というわけではない。
が、分散型管理を取り入れていて仕組みとしては画期的、
リードタイムの短縮が求められるソフトウェア業界と相性が良い。
※出た当時はCVSとのフローが違い過ぎて受け入れられなかったので
はないかと。
分散型だと嬉しいこと
+ ローカルリポジトリは好きに使って構わない
(ぶっ壊してもローカルなら気にしなくてOK
)
+ ローカルリポジトリに
他の人の変更を取込まない限り、
他の人の変更には左右されない
Gitだと嬉しいこと
+ ローカルリポジトリは好きに使って構わない
ガンガンぶっ壊してください
+ ローカルリポジトリに
他の人の変更を取込まない限り、
他の人の変更には左右されない
一言でいうと、
邪魔されないで自由にできる
から速くなる
あともう1つGitで重要なこと
ブランチの作成が手軽
+ SVN
→ブランチ作るの大変だから、
リリースバージョン1つに対して1ブランチ
+ Git
→ブランチ作るのが一瞬だから、
機能単位・ISSUE単位にブランチを作る
SVN
中央にあるファイルを別のディ
レクトリにリモートコピーして
るだけ。だから遅い。
SVNとGitのブランチの作り方
Git
リポジトリの状態はBLOBにし
てGitの内部DBに保持。
これを内部DB上にコピーして
いるから速い。
SVN
中央にあるファイルを別のディ
レクトリにリモートコピーして
るだけ。だから遅い。
SVNとGitのブランチの作り方
Git
リポジトリの状態はBLOBにし
てGitの内部DBに保持。
これを内部DB上で分岐、ディ
レクトリに展開しているから速
い。
ブランチ作成が手軽だと何で嬉しい?
+ 別ブランチへのマージをコマンド一発でできる
+ ブランチをリモートリポジトリに上げるだけで、
他の人に影響させずに、レビューや動作確認をして貰える
+ アプリのデプロイ観点からすると、
もっと強力なメリットがあるけど、それはまた今度・・・
Gitに慣れていないうちは、
よく使うコマンドだけ覚えると良い
よく使うコマンドのGit-SVNの比較
※GUIクライアントを使っている前提
Git SVN 概要
commit - ローカルリポジトリに変更を反映
push commit
ローカルリポジトリに反映した変更を
リモートリポジトリに変更を反映
pull
(fetch + merge)
update リモートリポジトリの変更をローカルに反映
fetch - リモートリポジトリから変更をローカルに取得(反映はしない)
merge - fetchで取得したローカルに取得した変更を反映する
branch - ブランチを切る
よく使うコマンドのGit-SVNの比較
※GUIクライアントを使っている前提
Git SVN 概要
commit - ローカルリポジトリに変更を反映
push commit
ローカルリポジトリに反映した変更を
リモートリポジトリに変更を反映
pull
(fetch + merge)
update リモートリポジトリの変更をローカルに反映
fetch - リモートリポジトリから変更をローカルに取得(反映はしない)
merge - fetchで取得したローカルに取得した変更を反映する
branch - ブランチを切る
初心者はpullでハマるので、fetchとmerge
を使った方が良いかも。
(強制はしない)
他にも色々なコマンドがあるけど、
慣れてきたら使えばイイと思います
Gitまとめ
+ 自分専用のローカルリポジトリ
+ ブランチを切るのがデフォルト運用(どの会社でも同じ)
+ 困ったらローカルリポジトリを無かったことにして、
リモートリポジトリからやり直す
+ コンフリクトで困ったら、知っている人を召喚する
Credits
Let’s enjoy the git life!

非エンジニアに捧ぐツアーオブ構成管理