O slideshow foi denunciado.
Seu SlideShare está sendo baixado. ×

はじめてのGit #gitkyoto

Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Carregando em…3
×

Confira estes a seguir

1 de 175 Anúncio
Anúncio

Mais Conteúdo rRelacionado

Diapositivos para si (20)

Quem viu também gostou (20)

Anúncio

Semelhante a はじめてのGit #gitkyoto (20)

Mais de Hisateru Tanaka (19)

Anúncio

Mais recentes (20)

はじめてのGit #gitkyoto

  1. 1. はじめてのGit たぶん関西でいちばんゆるいGit入門
  2. 2. たなかひさてる @tanakahisateru Pinoco developer js-markdown-extra maintainer PHPTAL contributor Firebug translation contributor Yii framework user ...and more OSS experienced
  3. 3. 何者かという話をわ かりやすいとこで はいこれで今日喋った人が誰だっ たか忘れなくなりました
  4. 4. わたしとGit 僕はそんなGitのすごい人じゃないです。 GitHubで必要な最低限の知識しかありません。 わからないことはすぐググります。 Gitは他人と使ってナンボでしょって思います。
  5. 5. 人にGitを教えるとこうなった 前職では、デザイナー(コーダー)の同僚やクライアントにGit を教えて使ってもらってました。 デザイナーは「これなかったら仕事できない」って中毒にな りました。 クライアントとのやりとりが超スムーズになりました。
  6. 6. 教えなきゃ損だよこれ
  7. 7. このセッションでは ホントの入門からちょっとだけ踏み込んで始めます。 みなさんが職場なり取引先なりで、布教する側の人になるぐ らいの中毒にするのが目標です。(初心者とか関係ないです) 教わらなくてもわかってる人は、教え方のヒントをパクって ください。Gitは他人と使ってナンボです。
  8. 8. バージョン管理って? 実はみなさん、たぶんすでにバージョン管理をやっていると 思いますよ。 日付名をつけてフォルダをバックアップするアレ。
  9. 9. このへんまだやる気ある
  10. 10. 「ちょっと複数案見せてよ」 「えっ...」
  11. 11. 「やっぱり前の前のが良かった」 (やる気なくなってきてる感)
  12. 12. 「やっとフィックス案できた...バタッ」
  13. 13. 「さっそくで悪いんだけど直しが...」 (壁ドンですよね)
  14. 14. 数日後
  15. 15. どの子がどの子かしら...?
  16. 16. 手作業の罠 人間はサボる/焦る/間違える。 フォルダの前後関係に保証がない。 誰が何をした結果なのかわからない。 ハードディスクにほとんど同じ内容のフォルダできて、 すごい早さで容量を圧迫してくる。
  17. 17. そんなあなたも Gitを使うと
  18. 18. こうなります
  19. 19. さらにこうなります
  20. 20. 日付フォルダとのちがい 誰が、いつ、何を変更したのか履歴に残る。 どの変更がどれを元にしたのか、順番を間違えない。 正式な最新版がわかるという大事さ。 変更情報だけを保存 → ハードディスクを圧迫しない。 (なので遠慮なくバックアップできる)
  21. 21. Subversion < Git 初心者には(そして多分将来ずっと)Gitがオススメ。 サーバの準備がまだでも作業を始められる。 Finderで勝手に移動/削除/名前変更をしても壊れない。 変更履歴の参照がとても速い。 プラグインがないので人によって機能の差が出ない。 (これはMercurialに対するメリット)
  22. 22. どうせGitは必要
  23. 23. みんなGitHub もっとあるよ
  24. 24. やってみよう
  25. 25. インストール 最新のXcodeを使っている 人はもう入っています。 ない人はこちら http://git-scm.com/
  26. 26. で、次は...
  27. 27. 待って、こわくないから
  28. 28. これからやろうとしてること 「Gitはコマンドだ」ということを知ってもらいます。 コマンドを打ち込みながら用語をおぼえましょう。 失敗しても大丈夫、目的は操作じゃなくて理解です。 概念を理解してからGUIへ。 そのときはもう、コマンドは忘れてていい。
  29. 29. コワクナイカラ/ <
  30. 30. うごきますか
  31. 31. 自分の名前を設定しよう
  32. 32. 作業者の名前は自己申告です。 Gitは自分で勝手に始めたり別のサーバに引越したりできるので、 誰が作業したかという名前はサーバの認証とは完全に別なのです。
  33. 33. この練習で使う ソースコードを...
  34. 34. パクりますね http://www.initializr.com/
  35. 35. IEとかFaviconとかオフで
  36. 36. ダウンロード&展開
  37. 37. これが初版です
  38. 38. cd[スペース]のあと、ターミナルに フォルダをドロップします。 作業するフォルダを開く
  39. 39. いま開きました
  40. 40. 現在ターミナルで開いているフォルダを「カ レントディレクトリ」と言います。 cd の後にパスを指定すると、カレントディレ クトリを変えることができます。 カレントディレクトリの確認は pwd です。
  41. 41. ホントに合ってる?
  42. 42. このへん大丈夫ですかー
  43. 43. いよいよGitですよー
  44. 44. git init
  45. 45. .git=ローカルリポジトリ
  46. 46. リポジトリ=入れ物 .git が消えると何もなかったことになる。 全部やり直したいときは rm -rf .git (あるいは詳しい人にこっそり聞きましょう)
  47. 47. git status
  48. 48. Untracked files = まだ管理していないファイ ルがこれだけあるということ。 git add を使えと言われていますね。
  49. 49. git add
  50. 50. add = コミット(あとで言います)するリストにファ イル追加するという意味で add です。 この操作をステージと言います。 バージョン管理でもっとも大事な操作、コミット の準備です。 ちょうど、Finderでシフトキーを押しながらファイ ルをポチポチするようなものです。
  51. 51. からの→ git status
  52. 52. git status の結果が Changes to be committed: というリストになりました。 いよいよ次が初めてのコミットです。
  53. 53. git commit -m “...”
  54. 54. 初回コミットおめでとうございます。コミット はバージョン管理でもっとも重要な機能です。 選んだファイルを .git フォルダの中にバックア ップコピーしたイメージです。 各コミットには、作業者の名前、コミットの日 時、メッセージが必ず残ります。
  55. 55. -m なしで git commit としてしまい、なにが 起こったかわからない人は、近くの詳しそう な人に聞いてください。 わかる人はそのまま続け、:wq で終了したら いいと思います。 わからない人はGUIを使うまで待ってね。
  56. 56. git status ...? → git log ...!
  57. 57. git status は nothing to commit (working directory id clean)と言っています。最後のコミ ットからまだ変更がないという意味です。 git log で過去のコミットを参照できます。 コミットに 00e8ac1be367fb350... というIDが付 いていることがわかります。このコミットのユ ニークな管理番号で、わりと重要です。
  58. 58. 心配なら git log --stat
  59. 59. もし .DS_Store でグチグチ言われる人は...
  60. 60. .gitignore というファイルに
  61. 61. .DS_Store と書きます
  62. 62. .gitignore = git + ignore (無視) 無視するファイル名やパスのパターンを書く
  63. 63. ここまでのまとめ git init git status git add <file/folder> git commit -m “message” git log .gitignore
  64. 64. むずかしいひとー
  65. 65. そうですね...
  66. 66. 癒し成分補充しときます
  67. 67. ここから面白く なるよ。 index.htmlに 変更発生。
  68. 68. git status
  69. 69. git diff
  70. 70. git commit -a -m “...”
  71. 71. git commit -a は変更されたファイルをすべて add してからコミットという意味です。 git add でステージしてから git commit する のと同じです。
  72. 72. git log
  73. 73. ログの結果が2つになりました。 「ソースを変更して確認・コミット」を自由 にやってみましょう。
  74. 74. 作業が区切れたらすぐにコミットしましょ う。 差分保存なので容量は食いません。遠慮なく どんどんやりましょう。(※ Photoshopは別) 頻度の目安は、1行のメッセージで意味を表 せる程度の変更セットです。
  75. 75. ここまでのまとめ git status や git diff で状態を確認しつつ... 変更 → コミット → 変更 → コミット → ... ここは難しくないですね。
  76. 76. つぎ、ちょっと難しい話になります。
  77. 77. コワクナイカラ/ <
  78. 78. HTMLの更新をしながら 裏でコツコツCSSを変えたい
  79. 79. ブランチ
  80. 80. git branch css-coding git checkout css-coding
  81. 81. css-coding という名前のブランチを作り、ブ ランチを切り替えました。 慣れている人は git checkout -b css-coding で、作成と切り替えを同時にできます。
  82. 82. git branch (パラメータなし)
  83. 83. ブランチが2つあること、今のブランチが css-codingだということがわかります。 master = 最初からあるメインのブランチ
  84. 84. css-coding ブランチで、 css/main.css を書き換え。
  85. 85. commit → log
  86. 86. H1 HENKOU → CSS PINK という変更の流れ でしたね。これを憶えておいてください。 (人によっては違うかもしれません) ここで、CSSの作業をやめて、HTMLだけ変 更する作業の流れに戻りましょう。
  87. 87. git checkout master
  88. 88. masterブランチでは、最後のコミットがまだ H1 HENKOU のままです。つまり...
  89. 89. もとどおり
  90. 90. 何事もなかった かのように index.html を書き換えて...
  91. 91. commit → log
  92. 92. H1 HENKOU → KIJI MIDASI という流れで コミットがつながりました。 masterブランチでは、CSS関係のコミットが なかったことになっています。
  93. 93. 別フォルダ作業のイメージ master css-coding
  94. 94. branchとは git branch css-coding css-coding
  95. 95. checkoutとは git checkout master master 作業フォルダ
  96. 96. git log --oneline --graph --all
  97. 97. たしかにコミットの履歴が分岐しています。 ブランチは別の人と作業するとき有効です。他のバージョ ン管理ツールとGitが違うのは、タグなんかよりずっとブ ランチのほうが使用頻度高いという点です。 でもちょっと難しいので、互いに同時に触らないよう声 をかけながらひとつのブランチでやってもいいです。 ただし、この「コミットの分岐」という概念は、Gitを理 解して使う上で絶対に忘れてはいけません。
  98. 98. git merge -m “...” css-coding
  99. 99. たったひとつのコマンドで 別のブランチの作業が合体!
  100. 100. mergeとは master css-coding git merge
  101. 101. マージは、相手のブランチから変更ファイル だけを取り出して、自分のファイルを上書き するイメージ。 もしブランチ間で同じファイルを変更してた ら、それらが競合(コンフリクト)した状態に なります。
  102. 102. いまコンフリクトについて説明するのは大変 なので、なるべく起こさないようにしてくだ さい。 Gitでコンフリクトを解消するのは、 Subversionよりずっと簡単なのでご安心を。 もし起こったら経験者に聞きましょう。
  103. 103. 参考: 超わかりやすいブランチの話 http://www.slideshare.net/ kotas/git-15276118
  104. 104. ここまでのまとめ git branch ブランチ名 git checkout ブランチ名 git branch git log --oneline --graph --all git merge ブランチ名
  105. 105. むずかしいひとー
  106. 106. そろそろまた癒し成分
  107. 107. いちいちコマンド打つのは 正直しんどい
  108. 108. http://gitx.frim.nl/
  109. 109. あえてもっとも古いGitXを使います。 ここまでの説明に対応する機能しかないの で、すごくわかりやすい。 コマンド運用との相性がいいです。 コマンドが苦手な人には、後でもっと先の機 能があるツールを紹介します。
  110. 110. log, diff, branch
  111. 111. branch -d(削除), checkout
  112. 112. status, diff
  113. 113. add, checkout --(変更をやめる機能)
  114. 114. commit + エディタ
  115. 115. おまけ: ターミナル好きなら tig
  116. 116. 絶対途中でやってはいけないこと 改行コードの変更 CRLF→LF 文字コードの変更 SJIS→UTF-8 インデント方針の変更 タブ→スペース
  117. 117. 絶対途中でやってはいけないこと これやると、ファイルのすべての行が書き換わったと認識さ れます。 本来の変更意図がわからなくなります。 やるなら早い段階で、全ソースのフォーマットを一気に変更 するコミットをしましょう。
  118. 118. コワクナイカラ/ <
  119. 119. いよいよGitHubへ
  120. 120. https://github.com/
  121. 121. まだの人はサインアップ
  122. 122. Welcome to social coding.
  123. 123. 公開 を登録 公開 認証とSSHの説明は省きます。 ずばり、~/.ssh ありますか? open ~/.ssh id_rsa.pub があればOK、それを使います。 ない人はこれで作ります: ssh-keygen -t rsa -C "your_email@youremail.com" すでに持っている人は隣の人を手伝ってあげましょう。
  124. 124. ここに詳しく出ています: https://help.github.com/articles/ generating-ssh-keys
  125. 125. id_rsa.pub できたら... で、id_rsa.pubの内容をまるごとコピペしましょう。
  126. 126. ここ リポジトリを作ろう
  127. 127. できた
  128. 128. はじめてのpush
  129. 129. ⌘+R
  130. 130. git push origin master はoriginのリモートリ ポジトリにmasterブランチをアップロードす るイメージです。 -u オプションは、以降masterブランチで git push だけしたとき、デフォルトでoriginに pushするようになるという紐付け。
  131. 131. push push
  132. 132. ところでこのEditって?
  133. 133. 編集できちゃう!
  134. 134. メッセージ+コミット
  135. 135. git pull
  136. 136. git pull はリモートのリポジトリからローカル にダウンロードするイメージ。 あ、GitHubのサイトで編集すると、動作確認 できてないソースでコミットを積むことにな るので、普通はダメですよ。
  137. 137. pull pull
  138. 138. pullの注意点 リモートからpullする=ダウンロードしたものを無名ブランチと みなして、マージ→コミットをやっている。 ダウンロードしてマージしないpullをfetchと言う。 pull = fetch + merge とにかく、いきなりローカルぜんぶ上書きではない。 FTPで落としてきたファイルをいきなり上書きして困ったこと... ありますよね。
  139. 139. pushの注意点 リモートの最新より古い状況に積んだコミットをpushするの は禁止されます。 なので、まずローカルにpullしてから、作業→コミット →pushの順序を守りましょう。 他の人が上げたサーバの最新を古いファイルでFTP上書きし て困ったこと...ありますよね。
  140. 140. むずかしいひとー ややこしいので、とりあえずWeb制作の言葉でいうと、サー バへのアップロードとサーバからのダウンロードでOKです。 ただ、突然の上書きで大失敗しない装置が付いてるというこ とだけ理解してください。 Gitでエラーになるというときは、もしそこで失敗が起きなか ったら、もっとひどいことが起こっていた、という可能性を 防いでくれていると思いましょう。
  141. 141. ところでさっき、originに「masterを」push したと言いました。
  142. 142. つまり...GitHubにはまだ css-coding ブランチ がない!!
  143. 143. git push origin css-coding
  144. 144. ブランチもpushできた
  145. 145. pushとpullはブランチごとに個別です。 どれをpush/pullするかを意識しましょう。 個別だからといって容量が倍になるわけではありませ ん。消費するのは差分の量だけです。
  146. 146. これでサーバに全部あるので ローカルの作業ディレクトリを削除しても平気。
  147. 147. GitHubのここから
  148. 148. git clone ...
  149. 149. まあ、clone するのはだいたい他人です。 途中から作業に参加する人は、git init ではな くこの git clone からスタートします。 あとで他の人と共同作業の練習しましょう。
  150. 150. 復元できました
  151. 151. いや∼よかったよかっ...
  152. 152. img おや?
  153. 153. 注: 空フォルダはダメ Gitは空のフォルダを管理できません。あくまでファイルの変更 の管理なので。 空っぽのフォルダを維持したい場合、中に何かダミーのファイ ルを入れてください。 ダミーファイル名は empty, .gitkeep, .gitignore, .htaccess などい ろいろな習慣があります。 あまり心配しなくても実害があることはまれです。
  154. 154. ちなみにmaster以外のリモートブランチを ローカルに連れてくるなら... git branch css-coding origin/css-coding
  155. 155. ここまでのまとめ git remote add リポジトリ名 アドレス git push -u リポジトリ名 ブランチ名 git push (注:ブランチごと) git pull git clone アドレス 空のフォルダは無視される git branch ブランチ名 origin/ブランチ名
  156. 156. 癒し(ry
  157. 157. お待たせしました GUIですよ
  158. 158. http://rowanj.github.com/gitx/
  159. 159. GitXのすごい版
  160. 160. clone
  161. 161. remote/fetch/pull/push
  162. 162. こんなことまで git branch css-... origin/css-...
  163. 163. GitXはgitコマンドに忠実なUIなので、コマン ドで理解した人が使いやすいです。 このUI自体が「Gitでできること集(簡易版)」 ありがちな操作がひととおりあるので、さら に勉強するポイントが見えてきます。
  164. 164. まだこれじゃ使いにくい と思ったら、メインで使 うツールはもっと自分に 合うのを選びましょう。
  165. 165. これでようやく スタートライン
  166. 166. むずかしいひとー
  167. 167. gitのコマンド むずかしいのは∼
  168. 168. gitのコマンド体系は「使う人の気持ち」では なく「内部設計の事情」でできています。 作った人の気持ちになったら理解できるとか 無理ゲー。 なので...
  169. 169. だからこそ 細かい操作方法は忘れてもかまいません。 用語と概念と仕組みの基本を忘れないことが重要です。 理解してしまえば、GUIを使ったほうが効率的です。 コマンドを知ると、GUIの説明テキストがコマンドオプショ ンの何を指すのか、想像できるようになります。
  170. 170. ただし... 本当に困ったときはググってコマンドをコピペできるように しときましょう。 GUIの操作手順は技術ブログに書かれにくい。 gitはググれる! ←ここ重要
  171. 171. お疲れ様でした

×