Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

はじめてのGit #gitkyoto

4,489 views

Published on

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

Published in: Technology
  • うまくアップロードされてない。トリミングした画像が消えてる。こっちのほうがうまく表示できるっぽいです。

    https://speakerdeck.com/tanakahisateru/hazimetefalsegit-number-gitkyoto
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

はじめてのGit #gitkyoto

  1. 1. はじめてのGitたぶん関西でいちばんゆるいGit入門
  2. 2. たなかひさてる@tanakahisateruPinoco developerjs-markdown-extra maintainerPHPTAL contributorFirebug translation contributorYii 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 (workingdirectory 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 initgit statusgit 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-codinggit 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 branchgit log --oneline --graph --allgit 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 ~/.sshid_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ブランチで gitpush だけしたとき、デフォルトで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 pullgit 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. お疲れ様でした

×