書きかけですし、未検証です。ご了承ください。
gitとは
プログラムソースのバージョン管理システムのこと。
gitの用語で大事なのは、
- 作業ディレクトリ
- ステージングエリア
- リポジトリ
の３つ。
リポジトリがGitのキモで、変更履歴を管理する登録簿みたいなものになる。
インストール方法
まずGitというソフトが必要なのでＰＣにインストールする（MacにはGitが最初からインストールされているので不要）
gitはhttps://git-scm.comからダウンロードする。ダウンロードしたらexeを実行する。
インストール先をきいてくるが、基本的にデフォルトのまま次へ次へでＯＫ。
以下すべての操作はWindowsではコマンドプロンプト、Macではターミナルで行う。
インストールされているGitのバージョンを確認する
下記コマンドのどちらかで確認できる。Macの場合もちゃんと入っているか確認したい場合はバージョンを確認するといい。
|
1 2 |
git version git --version |
初期設定
変更履歴をとるのに「誰が」という情報が必要なので、名前とEメールを記載することになっている。まずその設定をしておく。
|
1 2 3 4 |
git config --global user.name "hogehoge" git config --global user.email "hogehoge@gmail.com" git config --global color.ui true git config --global core.autoCRLF false |
上記を順に打っていけばいい。名前とEmailはそれぞれ自分のものを入力する。共同開発をすることもあるので、解りやすいものにした方がいいかも。
color.uiはメッセージの色分けをしてくれる設定。これをtrueでオンにする。
autoCRLFは自動でgit addかgit commitをしたときに、自動でCRLFに直してくれる機能。これをfalseでオフにする。
どっちみち本番サーバはLinuxなので、勝手にLFをCRLFに直されても困る。ちなみに、別件でこれをオフらずにやったことがあり、確かにWarningで「LFになってるので、CRLFに直しますよ」よというメッセージが出た。そのまま進んだら本当にCRLFに変更されていた。
設定確認
ちゃんと設定がされているか、もしくは現在の設定を見るコマンド
|
1 |
git config -l |
Gitリポジトリを作成する
HTMLでもJavaScriptでもPHPでもいいのだが、実際に開発するときは何かフォルダに入れるはず。
そのフォルダが作業ディレクトリ。その中にリポジトリを設置する形で作成する。その作成コマンド。
作成手順は、コマンドからそのディレクトリに移動し、
|
1 |
git init |
これを打つことで.gitというフォルダが作成される。このフォルダがリポジトリ。
このリポジトリの中が前述したコードの差分などを管理するための記録簿になっている。
このフォルダの隣にはもちろん開発中のコードがある。
ゆえに、
- 作業ディレクトリ ＝ 開発コード群を入れているフォルダ
- リポジトリ ＝ 開発コード群を入れているフォルダに設置された変更管理簿（.gitフォルダ）
- プログラム ＝ 冒頭にインストールしたGitプログラム
が必要となる。ステージングエリアは後述。
ステージングする
作業ディレクトリからステージングエリアに上げるコマンド
作業ディレクトリにあるファイル名を指定してステージングする
|
1 |
git add index.html |
作業ディレクトリにあり、変更があったものを全てaddする。カレント以下全て。
|
1 |
git add . |
ステージングから戻す
ステージングに上げたファイルを戻す。
ステージングした全てのファイルを戻す
|
1 |
git reset |
ステージングしたファイルをファイル名を指定して戻す
|
1 |
git reset ファイル名 |
コミットする
ステージングエリアからリポジトリに上げる操作。
基本コマンド
|
1 |
git commit |
ステージングにある全てのファイルをコミットする。
コミットされる前に、エディタが立上がってメッセージを入れる画面になる。
操作はvimです。vimの説明は必要最低限だけ下記の別記事にまとめてあります。vimを知らないと出られなくなります。
コミットメッセージのお作法
gitでは標準的に
|
1 2 3 |
1行目： コミットでの変更内容の要約 2行目： 空行 3行目： 変更した理由 |
となる。コメントメッセージは、他の人がコミットの変更内容を調べる場合や、自分で後から履歴を見直す際に大切な情報となるので、変更内容の解りやすいコメントを心がける。
ファイル名を指定
ファイル名を指定するとそのファイルだけコミット対象になる
|
1 |
git commit ファイル名 |
-mオプション
コメントも同時に入れてコミットするオプション。
|
1 |
git commit -m "ライン２を追加" |
-vオプション
変更箇所を確認しながらcommitするオプション
|
1 |
git -v |
現在の作業ディレクトリの状態を確認する
基本コマンド
|
1 |
git status |
gitは３つの状態で管理をしていくので、長く作業をしているとどのファイルをどの場所に置いたかわからなくなるので、そういう時に使う。
用語
On branch master
今いるブランチがマスターだよ
Your branch is ahead of ‘origin/master’ by 4 commits(use “git push” to publish your local comits)
リモートのorigin/masterより先に４つ進んでいるよ。あなたのローカルのコミットを発行するためにgit pushを使ってね。
nothing to commit, working tree clean
コミットするものは何も無いよ、ワーキングツリー（作業ディレクトリ）はキレイだよ
initial commit
まだ何も登録されていない
untracked files
このファイルはステージングエリアに仮登録されいません
modified(changes to be comitted)
ファイルが変更されているよ。コミットすべき変更があるよ
modified: index.htmlとあれば、index.htmlが変更されたよという意味。
Changes not staged for commit とあれば、ステージにもコミットにも来ていないという意味。
(use “git add <file> … ” to update what will be commited)・・アドしてステージにあげるか、
(use “git checkout — <file> … ” to discard changes in working directory)・・戻しなさい。
という次にやることを丁寧に教えてくれる。
コミット履歴の確認
commitをするたびにリポジトリに登録されていくが、それを一覧で見ることができる。いつ、誰が、何のファイルを更新したのか、その履歴。
基本コマンド
|
1 |
git log |
全てのコミット履歴を表示する。git log中の移動はVimと同じ。
内容は、commit時に自動で割り当てられたＩＤと、投稿者、メールアドレス、日時、コメント３行など。
ファイル名を指定する
ファイル名を指定すると、そのファイルだけの履歴を全件表示してくれる。
|
1 |
git log filename |
–onelineオプション
commitの状態を１行で確認する
|
1 |
git log --oneline |
１コミットを１行で表示してくれる。IDとファイル名とコメント１行だけ。投稿者やメールアドレスも表示されない。
–pretty=shortオプション
commitの状態を１行コメント＋αで表示する。
|
1 |
git log --pretty=short |
git logのコメント１行版のようなもの。メールや投稿者は表示される。
-nオプション
最新のコミットn件見たい場合に使う。単にgit logとすると大量のログが表示されてしまうので、通常は-nか–onelineで絞る。
|
1 |
git log -n 3 |
-pオプション
commitの状態を変更された場所も見たいときに使う。
|
1 |
git log -p |
git logのコミット情報に加えて、ファイルの差分も表示する。緑色で示された箇所が変更された箇所。
–statオプション
commitの状態をどこが変更されたではなく、どのファイルが何カ所変わったかを見る。沢山のファイルを扱っている場合に効果的。
|
1 |
git log --stat |
削除する方法
gitで管理しているディレクトリからファイルやディレクトリを消す場合は、gitで管理をしている以上、勝手に消したら、管理しているgitからすると一体全体どこにいっちゃったんだ？となってしまう。消す場合は、下記コマンドを実行すること。
リポジトリ上のファイル（作業ディレクトリ含む）を消したい
|
1 2 |
git rm index.html git commit filename -m "index.html deleted" |
git rmだけでは、作業ディレクトリのファイルが消えて、ステージングエリアに上がるだけなので、さらにcommitしてあげないといけない。
.gitignoreを忘れてGit管理の対象に入って間違ってコミットしてしまったファイルを、git rmコマンドで、コミットしたファイルをGitの管理から削除できる。
先走ってコマンドを使用せずに、deleteキー等で消しちゃった。
|
1 2 |
git add index.html git commit index.html -m "index.html deleted" |
その場合は、git statusでdeleted: index.htmlと赤字で表示される。なので、これをgit add / commitすればよい。削除という変更をリポジトリに上げればよい。
リポジトリ上のファイルだけを消したい
ローカルにファイルは残してGitの管理だけを外したい。
|
1 |
git rm --cache filename |
リポジトリ上のディレクトリを消したい
ファイルごとGit管理から削除、ディレクトリも一緒に削除
|
1 |
git rm -r dirname |
戻すときは、git checkout
|
1 |
git checkout -- index.html |
とする。
変更されたファイルの差分表示
作業ディレクトリとステージングエリアとの差分
|
1 |
git diff |
diffとはdifferenceの略。git addやgit commitする前に、本当に変更に間違えがないかを念のために確認するときに使う。
作業ディレクトリがクリーンな状態では何も表示されない。
ファイルに修正を加えた状態でgit diffをすると変更を示してくれる。差分は緑で表示。
さらにgit add .をして、git diffをしても何も表示されない。これはステージングに上げているから。
ステージングと最新コミットとの差分は下のgit diff HEADを使う。
ステージングとコミットとの差分
HEADをつけるとステージングとコミットとの差分になる。
|
1 |
git diff HEAD |
ステージングエリアとローカルリポジトリとの差分
|
1 |
git diff --cached |
ステージングにあるファイルの変更箇所を見たい場合は、とする。作業フォルダ・ステージングどちらにあるかでコマンドが違う。
ブランチについて
ブランチとは別々のバージョンを並行して開発したい場合に使用する。ちょっとした機能を試したいときに、さっとブランチを作って、そこで作業してうまくいったらmasterにどんどん取り込んでいくように開発を進めればよい。
ブランチの一覧を見る
|
1 |
git branch |
何もない状態なら、* masterと表示される。これは最初に作られるブランチで、米印 * が今自分がそこにいるということを示す。
ブランチを作る
|
1 |
git branch hoge |
この状態でgit branch（一覧を見る）をすると、hoge *masterの両方が表示され、変わらず*がmasterについていることがわかる。
ブランチを移動する
|
1 |
git checkout hoge |
これでhogeに移動でき、git branchで見ると、hogeに * がついていることがわかる。ここでファイルを作成してcommitしてもmasterには影響を及ぼさない。ためしにmyscript.jsをhogeで作成して、git add . とgit commit – m “myscript added”を行いコミットして、git checkout masterに戻ったら、作業ディレクトリにはmyscriptは存在しなかった。そして、git checkout hogeに戻ると、myscriptがあった。完全に別になるのだ。
ブランチをマージする。
|
1 |
git merge hoge |
今回はhogeで作ったものをmasterに組み入れるマージ。その場合は、上記コマンドをmasterに移動してから入力する。するとmasterにも同じファイルができる。
ブランチを削除する
|
1 |
git branch -d hoge |
これでhogeブランチを削除できる。その後git branchで確認しても、残っていない。
ブランチを作ってそのブランチにチェックアウトする。
|
1 |
git checkout -b hogehoge |
マージで衝突（コンフリクト）が起きた場合
hogehogeでindex.htmlを替えて、git add . git commit -m “comment” をして、masterでindex.htmlを替えて、git add . / git commit -m “comment”をした。そして、master側にhogehogeの内容をmergeしようとした場合、Merge conflict in index.html Automatic merge failed; fix conflicts and then commit the result.と表示される。そして、git statusで見ると、both modified: index.html（両方で変更されてるよ）と表示される。
index.htmlを開くと、下記のようになっている。HEADだと1stなのに、hogehogeだとfirstだよ。
|
1 2 3 4 5 6 |
<<<<<<<< HEAD line 1st ======== line first >>>>>>>> hogehoge |
|
1 |
line 1st |
これは上記のように変更して。git add . / git commit -m “conflict fixed”などとすればよい。その後、git logで見てみると、Mergeをしたとログに残っている。
タグをつける
主なコミットに別名をつけること。よくある使い方は、「バージョン１はこのコミットだよ」という具合です。git showやgit resetでもこのタグ名を指定することができる。
直前のコミットにタグをつける
|
1 |
git tag v1.0 |
これでgit logで見ても、commit 02c4d0651442**** (HEAD -> Master , tag: v1.0)となっている。
コミットを指定してタグをつける
|
1 |
git tag v0.9 05c769a73459 |
のように、ID名十分な桁数を後ろにつけること。
タグの一覧を見る
|
1 |
git tag |
これでv1.0表示される。
タグの削除方法
|
1 |
git tag -d v0.9 |
-dオプションを使うこと。
エイリアスをつける
エイリアスとは、gitの色々な命令に短縮名をつけるもの。タグはcommitIDにつける別名。たとえば、git checkout とか結構打つの面倒だけど、それを短く登録する。
checkoutをcoで登録する
|
1 |
git config --global alias.co checkout |
これでcoでcheckoutが使える。
エイリアス使用例
|
1 2 3 4 |
git config --global alias.co checkout git config --global alias.st status git config --global alias.br branch git config --global alias.ci commit |
エイリアスなどの設定を一覧表示する。
|
1 |
git config -l |
注意事項
gitで管理している場合は、rmやmvで削除や移動をしてはいけない。一体全体どこにいっちゃったんだ？ということになる。削除や移動をする場合は、下記のようにする。
|
1 2 |
git rm index.html git rm index.html index2.html |
管理対象外とする
error.logのようにサイズが大きくなったり、そもそもバージョン管理する必要がないファイルはgitの管理下から外す方法がある。同じフォルダ内に、.gitignoreというファイルを作り、その中にログ系のファイルなら、*.logと入力する。logというフォルダなら、/log/とする。windowsでドットから始まるファイルを作るには、.gitignore.のように前後にドットをつけるとうまくいく。この設定を行えば、git statusで見ても、バージョン管理にはerror.logは反映されない。まｔ.gitignoreファイルの適用範囲は、置いたディレクトリ下位のファイルに反映される。
macで自動生成されるファイルや、パスワードが記載されているファイルは対象外にする。
#と書くと#から始まる行はコメント
指定したファイルを書くとそのファイルが除外 index.html
ルートディレクトリを指定 /root.html
ディレクトリ以下を全て除外 dir/
Q&A
直前のcommitを変更する（に含める）
|
1 2 3 |
ファイルを変更して git add . git commit --amend |
commitしたけど、やっぱりもう一度編集して上げたいとき、commitがどんどん増えていくので、直前のcommitに含めてしまおうというときに使う。
戻すとき
直前のcommitまで戻したい。
|
1 |
git reset HEAD |
この場合は、commitが戻るだけ。作業ディレクトリまでは戻らない。つまり元ファイルは戻らない。
直前のcommitまで作業ディレクトリ（元ファイル）ごと戻りたい。
|
1 |
git reset --hard HEAD |
直前より前のcommitまで戻りたい。
|
1 |
git reset --hard HEAD^ |
More?と聞かれるので、^で答えること。これで直前の１つ前まで戻れる。–hardは必要に応じて。
comitIDを指定して戻りたい
|
1 |
git reset --hard 05c769a |
05c769aは実際は戻りたい箇所のcommitID。最低７ケタ。–hardは作業ディレクトリごと戻す。
前回取り消されたところに戻りたい
|
1 |
git reset --hard ORIG_HEAD |
今回例ではgit reset –hard 05c769aで一番最初のcommitに戻ったが、やっぱりその上のcommitだった。と言う場合、最初のcommitに戻ってしまうのは、初期に戻ってしまうということだから、後の祭りになる。しかし、ORIG_HEADには前回取り消されたHEADの情報が１個だけ入っている。ここに戻れる。
特定のファイルだけ前の状態に戻したい
|
1 |
git checkout ad9772b1b readme.txt |
id aaa readme.txt line1 added
id bbb index.html line1 added
id ccc readme.txt line2 added
id ddd index.html line2 added
git reset –hard bbb
これをすると、bbbのindex.htmlがline1の状態に戻るだけでなく、readme.txtもline1の状態に戻ってしまう。これではcommitを分けるメリットが無い。何でもかんでも変更を一切合切今日一日ご苦労さんで、１commitにしてしまうと、ある特定のファイルだけ戻すことができない。なので、普通commitはコメントで判断できるくらいに細分化して分けることが推奨される。しかし、resetで戻ると時系列で戻ってしまうので、あれ？と思って調べたらcheckoutを使うようだった。
共有リポジトリ
フォルダを共有リポジトリとして登録する
|
1 |
git init --bare |
共有リポジトリにしたいフォルダまでcdして、上記コマンドを使う。共有リポジトリのディレクトリ名は、ourweb.gitなどと、.gitにするのがお作法。
リモートリポジトリに登録する
|
1 |
git remote add origin https://github.com/koujiha0365/intro_git |
git pushでリモートリポジトリにあげる場合、リモートリポジトリに登録する必要がある。git remote addでローカルリポジトリをリモートリポジトリに登録できる。名前はよく使われるのがoriginなので、originで登録する。
リモートのoriginがどこにあるのか確認する
|
1 2 |
git config -l git remote -v |
のどちらかで確認できる。
共有リポジトリを削除する
|
1 |
git remote rm origin |
これで削除できる。
masterの内容をoriginに突っ込む
|
1 |
git push origin master |
これでourweb.gitの中に意味不明なファイルが出来ている。
同じ内容をcloneする。
|
1 |
git clone ../ourweb.git myweb2 |
userbをデスクトップに作ったので、そこから../でourweb.gitディレクトリを指定。myweb2という中身で保存する。（userbを作る作業は実際は不要。デスクトップからgit clone ourweb.git myweb2でＯＫ。
USERBから共有リポジトリourweb.gitにプッシュする
myweb2にあるindex.htmlを編集し、git add . / git commit -m “line 3 added”とし、
|
1 |
git push origin master |
とする。ここで重要なのは、リモートの情報も引き継がれるので、git push origin masterが使える。
またhtdocs7側でmyweb2で行って変更をpullで引く
|
1 |
git pull origin master |
共有時のトラブルについて
今回、htdocs7を作って作業していた。そして共有リポジトリをデスクトップにourweb.gitで作成した。そしてhtdocs7からgit push origin masterでプッシュした。さらにデスクトップからgit clone ourweb.git myweb2で、myweb2を複製する。次にhtdocs7で内容を変更し、git commit -amを行い、git push origin masterで共有リポジトリに突っ込んだ。そして、デスクトップのmyweb2で内容を変更し、git commit -amを行い、git push origin masterでこちらも共有リポジトリに突っ込もうとすると、エラーになる。まずアナタは、pullしなさいと。なので、git pull origin masterを行い、いったん引っ張ることにする。そしたら、編集したindex.htmlがマージの衝突（コンフリクト）と同じ状態になるので、同様にファイルを修正して、またgit commit -amを行い、git push origin masterで共有リポジトリに突っ込んで解決する。
要するに、同時にローカルを修正し合ってリポジトリに放り込もうとすると、後で突っ込む方が先にpullして下さいよとなる。
コメント