Gitのゆるめな勉強会 ワークショップ進行スライド

1. はじめてのGit
たぶん関西でいちばんゆるいGit入門

2. たなかひさてる
@tanakahisateru
Pinoco developer
js-markdown-extra maintainer
PHPTAL contributor
Firebug translation contributor
Yii framework user
...and more OSS experienced

3. 何者かという話をわ
かりやすいとこで
はいこれで今日喋った人が誰だっ
たか忘れなくなりました

4. わたしとGit
僕はそんなGitのすごい人じゃないです。
GitHubで必要な最低限の知識しかありません。
わからないことはすぐググります。
Gitは他人と使ってナンボでしょって思います。

5. 人にGitを教えるとこうなった
前職では、デザイナー(コーダー)の同僚やクライアントにGit
を教えて使ってもらってました。
デザイナーは「これなかったら仕事できない」って中毒にな
りました。
クライアントとのやりとりが超スムーズになりました。

6. 教えなきゃ損だよこれ

7. このセッションでは
ホントの入門からちょっとだけ踏み込んで始めます。
みなさんが職場なり取引先なりで、布教する側の人になるぐ
らいの中毒にするのが目標です。(初心者とか関係ないです)
教わらなくてもわかってる人は、教え方のヒントをパクって
ください。Gitは他人と使ってナンボです。

8. バージョン管理って?
実はみなさん、たぶんすでにバージョン管理をやっていると
思いますよ。
日付名をつけてフォルダをバックアップするアレ。

10. このへんまだやる気ある

11. 「ちょっと複数案見せてよ」
「えっ...」

12. 「やっぱり前の前のが良かった」
(やる気なくなってきてる感)

13. 「やっとフィックス案できた...バタッ」

14. 「さっそくで悪いんだけど直しが...」
(壁ドンですよね)

15. 数日後

16. どの子がどの子かしら...?

17. 手作業の罠
人間はサボる/焦る/間違える。
フォルダの前後関係に保証がない。
誰が何をした結果なのかわからない。
ハードディスクにほとんど同じ内容のフォルダできて、
すごい早さで容量を圧迫してくる。

18. そんなあなたも
Gitを使うと

19. こうなります

20. さらにこうなります

21. 日付フォルダとのちがい
誰が、いつ、何を変更したのか履歴に残る。
どの変更がどれを元にしたのか、順番を間違えない。
正式な最新版がわかるという大事さ。
変更情報だけを保存 → ハードディスクを圧迫しない。
(なので遠慮なくバックアップできる)

22. Subversion < Git
初心者には(そして多分将来ずっと)Gitがオススメ。
サーバの準備がまだでも作業を始められる。
Finderで勝手に移動/削除/名前変更をしても壊れない。
変更履歴の参照がとても速い。
プラグインがないので人によって機能の差が出ない。
(これはMercurialに対するメリット)

23. どうせGitは必要

24. みんなGitHub
もっとあるよ

25. やってみよう

26. インストール
最新のXcodeを使っている
人はもう入っています。
ない人はこちら
http://git-scm.com/

27. で、次は...

29. 待って、こわくないから

30. これからやろうとしてること
「Gitはコマンドだ」ということを知ってもらいます。
コマンドを打ち込みながら用語をおぼえましょう。
失敗しても大丈夫、目的は操作じゃなくて理解です。
概念を理解してからGUIへ。
そのときはもう、コマンドは忘れてていい。

31. ｺﾜｸﾅｲｶﾗ/
<

32. うごきますか

33. 自分の名前を設定しよう

34. 作業者の名前は自己申告です。
Gitは自分で勝手に始めたり別のサーバに引越したりできるので、
誰が作業したかという名前はサーバの認証とは完全に別なのです。

35. この練習で使う
ソースコードを...

36. パクりますね
http://www.initializr.com/

37. IEとかFaviconとかオフで

38. ダウンロード&展開

39. これが初版です

41. cd[スペース]のあと、ターミナルに
フォルダをドロップします。
作業するフォルダを開く

42. いま開きました

43. 現在ターミナルで開いているフォルダを「カ
レントディレクトリ」と言います。
cd の後にパスを指定すると、カレントディレ
クトリを変えることができます。
カレントディレクトリの確認は pwd です。

44. ホントに合ってる?

45. このへん大丈夫ですかー

46. いよいよGitですよー

47. git init

48. .git=ローカルリポジトリ

49. リポジトリ=入れ物
.git が消えると何もなかったことになる。
全部やり直したいときは rm -rf .git
(あるいは詳しい人にこっそり聞きましょう)

50. git status

51. Untracked files = まだ管理していないファイ
ルがこれだけあるということ。
git add を使えと言われていますね。

52. git add

53. add = コミット(あとで言います)するリストにファ
イル追加するという意味で add です。
この操作をステージと言います。
バージョン管理でもっとも大事な操作、コミット
の準備です。
ちょうど、Finderでシフトキーを押しながらファイ
ルをポチポチするようなものです。

54. からの→ git status

55. git status の結果が Changes to be committed:
というリストになりました。
いよいよ次が初めてのコミットです。

56. git commit -m “...”

57. 初回コミットおめでとうございます。コミット
はバージョン管理でもっとも重要な機能です。
選んだファイルを .git フォルダの中にバックア
ップコピーしたイメージです。
各コミットには、作業者の名前、コミットの日
時、メッセージが必ず残ります。

58. -m なしで git commit としてしまい、なにが
起こったかわからない人は、近くの詳しそう
な人に聞いてください。
わかる人はそのまま続け、:wq で終了したら
いいと思います。
わからない人はGUIを使うまで待ってね。

59. git status ...?
→ git log ...!

60. git status は nothing to commit (working
directory id clean)と言っています。最後のコミ
ットからまだ変更がないという意味です。
git log で過去のコミットを参照できます。
コミットに 00e8ac1be367fb350... というIDが付
いていることがわかります。このコミットのユ
ニークな管理番号で、わりと重要です。

61. 心配なら git log --stat

62. もし .DS_Store でグチグチ言われる人は...

63. .gitignore というファイルに

64. .DS_Store と書きます

65. .gitignore = git + ignore (無視)
無視するファイル名やパスのパターンを書く

66. ここまでのまとめ
git init
git status
git add <file/folder>
git commit -m “message”
git log
.gitignore

67. むずかしいひとー

68. そうですね...

69. 癒し成分補充しときます

70. ここから面白く
なるよ。
index.htmlに
変更発生。

71. git status

72. git diff

73. git commit -a -m “...”

74. git commit -a は変更されたファイルをすべて
add してからコミットという意味です。
git add でステージしてから git commit する
のと同じです。

75. git log

76. ログの結果が2つになりました。
「ソースを変更して確認・コミット」を自由
にやってみましょう。

77. 作業が区切れたらすぐにコミットしましょ
う。
差分保存なので容量は食いません。遠慮なく
どんどんやりましょう。(※ Photoshopは別)
頻度の目安は、1行のメッセージで意味を表
せる程度の変更セットです。

78. ここまでのまとめ
git status や git diff で状態を確認しつつ...
変更 → コミット → 変更 → コミット → ...
ここは難しくないですね。

79. つぎ、ちょっと難しい話になります。

80. ｺﾜｸﾅｲｶﾗ/
<

81. HTMLの更新をしながら
裏でコツコツCSSを変えたい

82. ブランチ

83. git branch css-coding
git checkout css-coding

84. css-coding という名前のブランチを作り、ブ
ランチを切り替えました。
慣れている人は
git checkout -b css-coding
で、作成と切り替えを同時にできます。

85. git branch (パラメータなし)

86. ブランチが2つあること、今のブランチが
css-codingだということがわかります。
master = 最初からあるメインのブランチ

87. css-coding
ブランチで、
css/main.css
を書き換え。

88. commit → log

89. H1 HENKOU → CSS PINK という変更の流れ
でしたね。これを憶えておいてください。
(人によっては違うかもしれません)
ここで、CSSの作業をやめて、HTMLだけ変
更する作業の流れに戻りましょう。

90. git checkout master

91. masterブランチでは、最後のコミットがまだ
H1 HENKOU のままです。つまり...

92. もとどおり

93. 何事もなかった
かのように
index.html
を書き換えて...

94. commit → log

95. H1 HENKOU → KIJI MIDASI という流れで
コミットがつながりました。
masterブランチでは、CSS関係のコミットが
なかったことになっています。

96. 別フォルダ作業のイメージ
master css-coding

97. branchとは
git branch css-coding
css-coding

98. checkoutとは
git checkout master
master
作業フォルダ

99. git log --oneline --graph --all

100. たしかにコミットの履歴が分岐しています。
ブランチは別の人と作業するとき有効です。他のバージョ
ン管理ツールとGitが違うのは、タグなんかよりずっとブ
ランチのほうが使用頻度高いという点です。
でもちょっと難しいので、互いに同時に触らないよう声
をかけながらひとつのブランチでやってもいいです。
ただし、この「コミットの分岐」という概念は、Gitを理
解して使う上で絶対に忘れてはいけません。

101. git merge -m “...” css-coding

102. たったひとつのコマンドで
別のブランチの作業が合体!

103. mergeとは
master css-coding
git merge

104. マージは、相手のブランチから変更ファイル
だけを取り出して、自分のファイルを上書き
するイメージ。
もしブランチ間で同じファイルを変更してた
ら、それらが競合(コンフリクト)した状態に
なります。

105. いまコンフリクトについて説明するのは大変
なので、なるべく起こさないようにしてくだ
さい。
Gitでコンフリクトを解消するのは、
Subversionよりずっと簡単なのでご安心を。
もし起こったら経験者に聞きましょう。

106. 参考: 超わかりやすいブランチの話
http://www.slideshare.net/
kotas/git-15276118

107. ここまでのまとめ
git branch ブランチ名
git checkout ブランチ名
git branch
git log --oneline --graph --all
git merge ブランチ名

108. むずかしいひとー

109. そろそろまた癒し成分

110. いちいちコマンド打つのは
正直しんどい

111. http://gitx.frim.nl/

112. あえてもっとも古いGitXを使います。
ここまでの説明に対応する機能しかないの
で、すごくわかりやすい。
コマンド運用との相性がいいです。
コマンドが苦手な人には、後でもっと先の機
能があるツールを紹介します。

113. log, diff, branch

114. branch -d(削除), checkout

115. status, diff

116. add, checkout --(変更をやめる機能)

117. commit + エディタ

118. おまけ: ターミナル好きなら tig

119. 絶対途中でやってはいけないこと
改行コードの変更 CRLF→LF
文字コードの変更 SJIS→UTF-8
インデント方針の変更 タブ→スペース

120. 絶対途中でやってはいけないこと
これやると、ファイルのすべての行が書き換わったと認識さ
れます。
本来の変更意図がわからなくなります。
やるなら早い段階で、全ソースのフォーマットを一気に変更
するコミットをしましょう。

121. ｺﾜｸﾅｲｶﾗ/
<

122. いよいよGitHubへ

123. https://github.com/

124. まだの人はサインアップ

125. Welcome to social coding.

126. 公開 を登録
公開 認証とSSHの説明は省きます。
ずばり、~/.ssh ありますか?
open ~/.ssh
id_rsa.pub があればOK、それを使います。
ない人はこれで作ります:
ssh-keygen -t rsa -C "your_email@youremail.com"
すでに持っている人は隣の人を手伝ってあげましょう。

127. ここに詳しく出ています:
https://help.github.com/articles/
generating-ssh-keys

128. id_rsa.pub できたら...
で、id_rsa.pubの内容をまるごとコピペしましょう。

129. ここ
リポジトリを作ろう

130. できた

131. はじめてのpush

132. ⌘+R

133. git push origin master はoriginのリモートリ
ポジトリにmasterブランチをアップロードす
るイメージです。
-u オプションは、以降masterブランチで git
push だけしたとき、デフォルトでoriginに
pushするようになるという紐付け。

134. push
push

135. ところでこのEditって?

136. 編集できちゃう!

137. メッセージ+コミット

138. git pull

139. git pull はリモートのリポジトリからローカル
にダウンロードするイメージ。
あ、GitHubのサイトで編集すると、動作確認
できてないソースでコミットを積むことにな
るので、普通はダメですよ。

140. pull
pull

141. pullの注意点
リモートからpullする=ダウンロードしたものを無名ブランチと
みなして、マージ→コミットをやっている。
ダウンロードしてマージしないpullをfetchと言う。
pull = fetch + merge
とにかく、いきなりローカルぜんぶ上書きではない。
FTPで落としてきたファイルをいきなり上書きして困ったこと...
ありますよね。

142. pushの注意点
リモートの最新より古い状況に積んだコミットをpushするの
は禁止されます。
なので、まずローカルにpullしてから、作業→コミット
→pushの順序を守りましょう。
他の人が上げたサーバの最新を古いファイルでFTP上書きし
て困ったこと...ありますよね。

143. むずかしいひとー
ややこしいので、とりあえずWeb制作の言葉でいうと、サー
バへのアップロードとサーバからのダウンロードでOKです。
ただ、突然の上書きで大失敗しない装置が付いてるというこ
とだけ理解してください。
Gitでエラーになるというときは、もしそこで失敗が起きなか
ったら、もっとひどいことが起こっていた、という可能性を
防いでくれていると思いましょう。

144. ところでさっき、originに「masterを」push
したと言いました。

145. つまり...GitHubにはまだ css-coding ブランチ
がない!!

146. git push origin css-coding

147. ブランチもpushできた

148. pushとpullはブランチごとに個別です。
どれをpush/pullするかを意識しましょう。
個別だからといって容量が倍になるわけではありませ
ん。消費するのは差分の量だけです。

149. これでサーバに全部あるので
ローカルの作業ディレクトリを削除しても平気。

150. GitHubのここから

151. git clone ...

152. まあ、clone するのはだいたい他人です。
途中から作業に参加する人は、git init ではな
くこの git clone からスタートします。
あとで他の人と共同作業の練習しましょう。

153. 復元できました

154. いや∼よかったよかっ...

155. img
おや?

156. 注: 空フォルダはダメ
Gitは空のフォルダを管理できません。あくまでファイルの変更
の管理なので。
空っぽのフォルダを維持したい場合、中に何かダミーのファイ
ルを入れてください。
ダミーファイル名は empty, .gitkeep, .gitignore, .htaccess などい
ろいろな習慣があります。
あまり心配しなくても実害があることはまれです。

157. ちなみにmaster以外のリモートブランチを
ローカルに連れてくるなら...
git branch css-coding origin/css-coding

158. ここまでのまとめ
git remote add リポジトリ名 アドレス
git push -u リポジトリ名 ブランチ名
git push (注:ブランチごと)
git pull
git clone アドレス
空のフォルダは無視される
git branch ブランチ名 origin/ブランチ名

159. 癒し(ry

160. お待たせしました
GUIですよ

161. http://rowanj.github.com/gitx/

162. GitXのすごい版

163. clone

164. remote/fetch/pull/push

165. こんなことまで
git branch css-... origin/css-...

166. GitXはgitコマンドに忠実なUIなので、コマン
ドで理解した人が使いやすいです。
このUI自体が「Gitでできること集(簡易版)」
ありがちな操作がひととおりあるので、さら
に勉強するポイントが見えてきます。

167. まだこれじゃ使いにくい
と思ったら、メインで使
うツールはもっと自分に
合うのを選びましょう。

168. これでようやく
スタートライン

169. むずかしいひとー

170. gitのコマンド
むずかしいのは∼

172. gitのコマンド体系は「使う人の気持ち」では
なく「内部設計の事情」でできています。
作った人の気持ちになったら理解できるとか
無理ゲー。
なので...

173. だからこそ
細かい操作方法は忘れてもかまいません。
用語と概念と仕組みの基本を忘れないことが重要です。
理解してしまえば、GUIを使ったほうが効率的です。
コマンドを知ると、GUIの説明テキストがコマンドオプショ
ンの何を指すのか、想像できるようになります。

174. ただし...
本当に困ったときはググってコマンドをコピペできるように
しときましょう。
GUIの操作手順は技術ブログに書かれにくい。
gitはググれる! ←ここ重要

175. お疲れ様でした