Post on 28-May-2015
description
はじめてのGitたぶん関西でいちばんゆるいGit入門
たなかひさてる@tanakahisateru
Pinoco developerjs-markdown-extra maintainerPHPTAL contributorFirebug translation contributorYii framework user...and more OSS experienced
何者かという話をわかりやすいとこで
はいこれで今日喋った人が誰だったか忘れなくなりました
僕はそんなGitのすごい人じゃないです。
GitHubで必要な最低限の知識しかありません。
わからないことはすぐググります。
Gitは他人と使ってナンボでしょって思います。
わたしとGit
人にGitを教えるとこうなった
前職では、デザイナー(コーダー)の同僚やクライアントにGit
を教えて使ってもらってました。
デザイナーは「これなかったら仕事できない」って中毒にな
りました。
クライアントとのやりとりが超スムーズになりました。
教えなきゃ損だよこれ
このセッションでは
ホントの入門からちょっとだけ踏み込んで始めます。
みなさんが職場なり取引先なりで、布教する側の人になるぐ
らいの中毒にするのが目標です。(初心者とか関係ないです)
教わらなくてもわかってる人は、教え方のヒントをパクって
ください。Gitは他人と使ってナンボです。
バージョン管理って?
実はみなさん、たぶんすでにバージョン管理をやっていると
思いますよ。
日付名をつけてフォルダをバックアップするアレ。
このへんまだやる気ある
「ちょっと複数案見せてよ」「えっ...」
「やっぱり前の前のが良かった」(やる気なくなってきてる感)
「やっとフィックス案できた...バタッ」
「さっそくで悪いんだけど直しが...」(壁ドンですよね)
数日後
どの子がどの子かしら...?
手作業の罠
人間はサボる/焦る/間違える。
フォルダの前後関係に保証がない。
誰が何をした結果なのかわからない。
ハードディスクにほとんど同じ内容のフォルダできて、
すごい早さで容量を圧迫してくる。
そんなあなたもGitを使うと
こうなります
さらにこうなります
日付フォルダとのちがい
誰が、いつ、何を変更したのか履歴に残る。
どの変更がどれを元にしたのか、順番を間違えない。
正式な最新版がわかるという大事さ。
変更情報だけを保存 → ハードディスクを圧迫しない。
(なので遠慮なくバックアップできる)
Subversion < Git初心者には(そして多分将来ずっと)Gitがオススメ。
サーバの準備がまだでも作業を始められる。
Finderで勝手に移動/削除/名前変更をしても壊れない。
変更履歴の参照がとても速い。
プラグインがないので人によって機能の差が出ない。
(これはMercurialに対するメリット)
どうせGitは必要
みんなGitHub
もっとあるよ
やってみよう
インストール
最新のXcodeを使っている
人はもう入っています。
ない人はこちら
http://git-scm.com/
で、次は...
待って、こわくないから
これからやろうとしてること
「Gitはコマンドだ」ということを知ってもらいます。
コマンドを打ち込みながら用語をおぼえましょう。
失敗しても大丈夫、目的は操作じゃなくて理解です。
概念を理解してからGUIへ。
そのときはもう、コマンドは忘れてていい。
<\ｺﾜｸﾅｲｶﾗ/
うごきますか
自分の名前を設定しよう
作業者の名前は自己申告です。
Gitは自分で勝手に始めたり別のサーバに引越したりできるので、
誰が作業したかという名前はサーバの認証とは完全に別なのです。
この練習で使うソースコードを...
http://www.initializr.com/パクりますね
IEとかFaviconとかオフで
ダウンロード&展開
これが初版です
作業するフォルダを開く
cd[スペース]のあと、ターミナルにフォルダをドロップします。
いま開きました
現在ターミナルで開いているフォルダを「カ
レントディレクトリ」と言います。
cd の後にパスを指定すると、カレントディレ
クトリを変えることができます。
カレントディレクトリの確認は pwd です。
ホントに合ってる?
このへん大丈夫ですかー
いよいよGitですよー
git init
.git=ローカルリポジトリ
リポジトリ=入れ物
.git が消えると何もなかったことになる。
全部やり直したいときは rm -rf .git
(あるいは詳しい人にこっそり聞きましょう)
git status
Untracked files = まだ管理していないファイ
ルがこれだけあるということ。
git add を使えと言われていますね。
git add
add = コミット(あとで言います)するリストにファ
イル追加するという意味で add です。
この操作をステージと言います。
バージョン管理でもっとも大事な操作、コミット
の準備です。
ちょうど、Finderでシフトキーを押しながらファイ
ルをポチポチするようなものです。
からの→ git status
git status の結果が Changes to be committed:
というリストになりました。
いよいよ次が初めてのコミットです。
git commit -m “...”
初回コミットおめでとうございます。コミット
はバージョン管理でもっとも重要な機能です。
選んだファイルを .git フォルダの中にバックア
ップコピーしたイメージです。
各コミットには、作業者の名前、コミットの日
時、メッセージが必ず残ります。
-m なしで git commit としてしまい、なにが
起こったかわからない人は、近くの詳しそう
な人に聞いてください。
わかる人はそのまま続け、:wq で終了したら
いいと思います。
わからない人はGUIを使うまで待ってね。
git status ...?→ git log ...!
git status は nothing to commit (working
directory id clean)と言っています。最後のコミ
ットからまだ変更がないという意味です。
git log で過去のコミットを参照できます。
コミットに 00e8ac1be367fb350... というIDが付
いていることがわかります。このコミットのユ
ニークな管理番号で、わりと重要です。
心配なら git log --stat
もし .DS_Store でグチグチ言われる人は...
.gitignore というファイルに
.DS_Store と書きます
.gitignore = git + ignore (無視)
無視するファイル名やパスのパターンを書く
ここまでのまとめ
git init
git status
git add <file/folder>
git commit -m “message”
git log
.gitignore
むずかしいひとー
そうですね...
癒し成分補充しときます
ここから面白くなるよ。index.htmlに変更発生。
git status
git diff
git commit -a -m “...”
git commit -a は変更されたファイルをすべて
add してからコミットという意味です。
git add でステージしてから git commit する
のと同じです。
git log
ログの結果が2つになりました。
「ソースを変更して確認・コミット」を自由
にやってみましょう。
作業が区切れたらすぐにコミットしましょ
う。
差分保存なので容量は食いません。遠慮なく
どんどんやりましょう。(※ Photoshopは別)
頻度の目安は、1行のメッセージで意味を表
せる程度の変更セットです。
ここまでのまとめ
git status や git diff で状態を確認しつつ...
変更 → コミット → 変更 → コミット → ...
ここは難しくないですね。
つぎ、ちょっと難しい話になります。
<\ｺﾜｸﾅｲｶﾗ/
HTMLの更新をしながら裏でコツコツCSSを変えたい
ブランチ
git branch css-codinggit checkout css-coding
css-coding という名前のブランチを作り、ブ
ランチを切り替えました。
慣れている人は
git checkout -b css-codingで、作成と切り替えを同時にできます。
git branch (パラメータなし)
ブランチが2つあること、今のブランチが
css-codingだということがわかります。
master = 最初からあるメインのブランチ
css-codingブランチで、css/main.cssを書き換え。
commit → log
H1 HENKOU → CSS PINK という変更の流れ
でしたね。これを憶えておいてください。
(人によっては違うかもしれません)
ここで、CSSの作業をやめて、HTMLだけ変
更する作業の流れに戻りましょう。
git checkout master
masterブランチでは、最後のコミットがまだ
H1 HENKOU のままです。つまり...
もとどおり
何事もなかったかのようにindex.htmlを書き換えて...
commit → log
H1 HENKOU → KIJI MIDASI という流れで
コミットがつながりました。
masterブランチでは、CSS関係のコミットが
なかったことになっています。
別フォルダ作業のイメージ
master css-coding
branchとは
git branch css-coding
css-coding
checkoutとは
master
git checkout master
作業フォルダ
git log --oneline --graph --all
たしかにコミットの履歴が分岐しています。
ブランチは別の人と作業するとき有効です。他のバージョ
ン管理ツールとGitが違うのは、タグなんかよりずっとブ
ランチのほうが使用頻度高いという点です。
でもちょっと難しいので、互いに同時に触らないよう声
をかけながらひとつのブランチでやってもいいです。
ただし、この「コミットの分岐」という概念は、Gitを理
解して使う上で絶対に忘れてはいけません。
git merge -m “...” css-coding
たったひとつのコマンドで別のブランチの作業が合体!
mergeとは
master css-coding
git merge
マージは、相手のブランチから変更ファイル
だけを取り出して、自分のファイルを上書き
するイメージ。
もしブランチ間で同じファイルを変更してた
ら、それらが競合(コンフリクト)した状態に
なります。
いまコンフリクトについて説明するのは大変
なので、なるべく起こさないようにしてくだ
さい。
Gitでコンフリクトを解消するのは、
Subversionよりずっと簡単なのでご安心を。
もし起こったら経験者に聞きましょう。
参考: 超わかりやすいブランチの話http://www.slideshare.net/
kotas/git-15276118
ここまでのまとめ
git branch ブランチ名
git checkout ブランチ名
git branch
git log --oneline --graph --all
git merge ブランチ名
むずかしいひとー
そろそろまた癒し成分
いちいちコマンド打つのは正直しんどい
あえてもっとも古いGitXを使います。
ここまでの説明に対応する機能しかないの
で、すごくわかりやすい。
コマンド運用との相性がいいです。
コマンドが苦手な人には、後でもっと先の機
能があるツールを紹介します。
log, diff, branch
branch -d(削除), checkout
status, diff
add, checkout --(変更をやめる機能)
commit + エディタ
おまけ: ターミナル好きなら tig
改行コードの変更 CRLF→LF
文字コードの変更 SJIS→UTF-8
インデント方針の変更 タブ→スペース
絶対途中でやってはいけないこと
これやると、ファイルのすべての行が書き換わったと認識さ
れます。
本来の変更意図がわからなくなります。
やるなら早い段階で、全ソースのフォーマットを一気に変更
するコミットをしましょう。
絶対途中でやってはいけないこと
<\ｺﾜｸﾅｲｶﾗ/
いよいよGitHubへ
まだの人はサインアップ
Welcome to social coding.
公開鍵を登録公開鍵認証とSSHの説明は省きます。
ずばり、~/.ssh ありますか?
open ~/.ssh
id_rsa.pub があればOK、それを使います。
ない人はこれで作ります:
ssh-keygen -t rsa -C "your_email@youremail.com"
すでに持っている人は隣の人を手伝ってあげましょう。
ここに詳しく出ています:
https://help.github.com/articles/generating-ssh-keys
id_rsa.pub できたら...
で、id_rsa.pubの内容をまるごとコピペしましょう。
リポジトリを作ろう
ここ
できた
はじめてのpush
⌘+R
git push origin master はoriginのリモートリ
ポジトリにmasterブランチをアップロードす
るイメージです。
-u オプションは、以降masterブランチで git
push だけしたとき、デフォルトでoriginに
pushするようになるという紐付け。
push
push
ところでこのEditって?
編集できちゃう!
メッセージ+コミット
git pull
git pull はリモートのリポジトリからローカル
にダウンロードするイメージ。
あ、GitHubのサイトで編集すると、動作確認
できてないソースでコミットを積むことにな
るので、普通はダメですよ。
pull
pull
リモートからpullする=ダウンロードしたものを無名ブランチと
みなして、マージ→コミットをやっている。
ダウンロードしてマージしないpullをfetchと言う。
pull = fetch + merge
とにかく、いきなりローカルぜんぶ上書きではない。
FTPで落としてきたファイルをいきなり上書きして困ったこと...
ありますよね。
pullの注意点
リモートの最新より古い状況に積んだコミットをpushするの
は禁止されます。
なので、まずローカルにpullしてから、作業→コミット
→pushの順序を守りましょう。
他の人が上げたサーバの最新を古いファイルでFTP上書きし
て困ったこと...ありますよね。
pushの注意点
ややこしいので、とりあえずWeb制作の言葉でいうと、サー
バへのアップロードとサーバからのダウンロードでOKです。
ただ、突然の上書きで大失敗しない装置が付いてるというこ
とだけ理解してください。
Gitでエラーになるというときは、もしそこで失敗が起きなか
ったら、もっとひどいことが起こっていた、という可能性を
防いでくれていると思いましょう。
むずかしいひとー
ところでさっき、originに「masterを」push
したと言いました。
つまり...GitHubにはまだ css-coding ブランチ
がない!!
git push origin css-coding
ブランチもpushできた
pushとpullはブランチごとに個別です。
どれをpush/pullするかを意識しましょう。
個別だからといって容量が倍になるわけではありませ
ん。消費するのは差分の量だけです。
ローカルの作業ディレクトリを削除しても平気。
これでサーバに全部あるので
GitHubのここから
git clone ...
まあ、clone するのはだいたい他人です。
途中から作業に参加する人は、git init ではな
くこの git clone からスタートします。
あとで他の人と共同作業の練習しましょう。
復元できました
いや～よかったよかっ...
おや?
img
注: 空フォルダはダメGitは空のフォルダを管理できません。あくまでファイルの変更
の管理なので。
空っぽのフォルダを維持したい場合、中に何かダミーのファイ
ルを入れてください。
ダミーファイル名は empty, .gitkeep, .gitignore, .htaccess などい
ろいろな習慣があります。
あまり心配しなくても実害があることはまれです。
ちなみにmaster以外のリモートブランチをローカルに連れてくるなら...
git branch css-coding origin/css-coding
ここまでのまとめgit remote add リポジトリ名 アドレス
git push -u リポジトリ名 ブランチ名
git push (注:ブランチごと)
git pull
git clone アドレス
空のフォルダは無視される
git branch ブランチ名 origin/ブランチ名
癒し(ry
お待たせしましたGUIですよ
GitXのすごい版
clone
remote/fetch/pull/push
こんなことまでgit branch css-... origin/css-...
GitXはgitコマンドに忠実なUIなので、コマン
ドで理解した人が使いやすいです。
このUI自体が「Gitでできること集(簡易版)」
ありがちな操作がひととおりあるので、さら
に勉強するポイントが見えてきます。
まだこれじゃ使いにくい
と思ったら、メインで使
うツールはもっと自分に
合うのを選びましょう。
これでようやくスタートライン
むずかしいひとー
gitのコマンドむずかしいのは～
gitのコマンド体系は「使う人の気持ち」では
なく「内部設計の事情」でできています。
作った人の気持ちになったら理解できるとか
無理ゲー。
なので...
細かい操作方法は忘れてもかまいません。
用語と概念と仕組みの基本を忘れないことが重要です。
理解してしまえば、GUIを使ったほうが効率的です。
コマンドを知ると、GUIの説明テキストがコマンドオプショ
ンの何を指すのか、想像できるようになります。
だからこそ
ただし...
本当に困ったときはググってコマンドをコピペできるように
しときましょう。
GUIの操作手順は技術ブログに書かれにくい。
gitはググれる! ←ここ重要
お疲れ様でした