はじめての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 ブランチ名

むずかしいひとー

そろそろまた癒し成分

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

http://gitx.frim.nl/

あえてもっとも古いGitXを使います。

ここまでの説明に対応する機能しかないの

で、すごくわかりやすい。

コマンド運用との相性がいいです。

コマンドが苦手な人には、後でもっと先の機

能があるツールを紹介します。

log, diff, branch

branch -d(削除), checkout

status, diff

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

commit + エディタ

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

改行コードの変更 CRLF→LF

文字コードの変更 SJIS→UTF-8

インデント方針の変更 タブ→スペース

絶対途中でやってはいけないこと

これやると、ファイルのすべての行が書き換わったと認識さ

れます。

本来の変更意図がわからなくなります。

やるなら早い段階で、全ソースのフォーマットを一気に変更

するコミットをしましょう。

絶対途中でやってはいけないこと

<\ｺﾜｸﾅｲｶﾗ/

いよいよGitHubへ

https://github.com/

まだの人はサインアップ

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ですよ

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

GitXのすごい版

clone

remote/fetch/pull/push

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

GitXはgitコマンドに忠実なUIなので、コマン

ドで理解した人が使いやすいです。

このUI自体が「Gitでできること集(簡易版)」

ありがちな操作がひととおりあるので、さら

に勉強するポイントが見えてきます。

まだこれじゃ使いにくい

と思ったら、メインで使

うツールはもっと自分に

合うのを選びましょう。

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

むずかしいひとー

gitのコマンドむずかしいのは～

gitのコマンド体系は「使う人の気持ち」では

なく「内部設計の事情」でできています。

作った人の気持ちになったら理解できるとか

無理ゲー。

なので...

細かい操作方法は忘れてもかまいません。

用語と概念と仕組みの基本を忘れないことが重要です。

理解してしまえば、GUIを使ったほうが効率的です。

コマンドを知ると、GUIの説明テキストがコマンドオプショ

ンの何を指すのか、想像できるようになります。

だからこそ

ただし...

本当に困ったときはググってコマンドをコピペできるように

しときましょう。

GUIの操作手順は技術ブログに書かれにくい。

gitはググれる! ←ここ重要

お疲れ様でした