書きかけですし、未検証です。ご了承ください。

 

gitとは

プログラムソースのバージョン管理システムのこと。

gitの用語で大事なのは、

1. 作業ディレクトリ
2. ステージングエリア
3. リポジトリ

の３つ。

リポジトリがGitのキモで、変更履歴を管理する登録簿みたいなものになる。

 

インストール方法

まずGitというソフトが必要なのでＰＣにインストールする（MacにはGitが最初からインストールされているので不要）

gitはhttps://git-scm.comからダウンロードする。ダウンロードしたらexeを実行する。

インストール先をきいてくるが、基本的にデフォルトのまま次へ次へでＯＫ。

以下すべての操作はWindowsではコマンドプロンプト、Macではターミナルで行う。

 

インストールされているGitのバージョンを確認する

下記コマンドのどちらかで確認できる。Macの場合もちゃんと入っているか確認したい場合はバージョンを確認するといい。

 

初期設定

変更履歴をとるのに「誰が」という情報が必要なので、名前とEメールを記載することになっている。まずその設定をしておく。

上記を順に打っていけばいい。名前とEmailはそれぞれ自分のものを入力する。共同開発をすることもあるので、解りやすいものにした方がいいかも。

color.uiはメッセージの色分けをしてくれる設定。これをtrueでオンにする。

autoCRLFは自動でgit addかgit commitをしたときに、自動でCRLFに直してくれる機能。これをfalseでオフにする。

どっちみち本番サーバはLinuxなので、勝手にLFをCRLFに直されても困る。ちなみに、別件でこれをオフらずにやったことがあり、確かにWarningで「LFになってるので、CRLFに直しますよ」よというメッセージが出た。そのまま進んだら本当にCRLFに変更されていた。

 

設定確認

ちゃんと設定がされているか、もしくは現在の設定を見るコマンド

 

Gitリポジトリを作成する

HTMLでもJavaScriptでもPHPでもいいのだが、実際に開発するときは何かフォルダに入れるはず。

そのフォルダが作業ディレクトリ。その中にリポジトリを設置する形で作成する。その作成コマンド。

作成手順は、コマンドからそのディレクトリに移動し、

 

これを打つことで.gitというフォルダが作成される。このフォルダがリポジトリ。

このリポジトリの中が前述したコードの差分などを管理するための記録簿になっている。

このフォルダの隣にはもちろん開発中のコードがある。

 

ゆえに、

• 作業ディレクトリ　＝　開発コード群を入れているフォルダ
• リポジトリ　＝　開発コード群を入れているフォルダに設置された変更管理簿（.gitフォルダ）
• プログラム　＝　冒頭にインストールしたGitプログラム

が必要となる。ステージングエリアは後述。

 

ステージングする

作業ディレクトリからステージングエリアに上げるコマンド

 

作業ディレクトリにあるファイル名を指定してステージングする

 

作業ディレクトリにあり、変更があったものを全てaddする。カレント以下全て。

 

 

ステージングから戻す

ステージングに上げたファイルを戻す。

 

ステージングした全てのファイルを戻す

 

ステージングしたファイルをファイル名を指定して戻す

 

 

コミットする

ステージングエリアからリポジトリに上げる操作。

基本コマンド

ステージングにある全てのファイルをコミットする。

コミットされる前に、エディタが立上がってメッセージを入れる画面になる。

操作はvimです。vimの説明は必要最低限だけ下記の別記事にまとめてあります。vimを知らないと出られなくなります。

Vimエディタ 簡単な説明

 

コミットメッセージのお作法

gitでは標準的に

となる。コメントメッセージは、他の人がコミットの変更内容を調べる場合や、自分で後から履歴を見直す際に大切な情報となるので、変更内容の解りやすいコメントを心がける。

 

ファイル名を指定

ファイル名を指定するとそのファイルだけコミット対象になる

 

-mオプション

コメントも同時に入れてコミットするオプション。

 

-vオプション

変更箇所を確認しながらcommitするオプション

 

 

現在の作業ディレクトリの状態を確認する

 

基本コマンド

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をするたびにリポジトリに登録されていくが、それを一覧で見ることができる。いつ、誰が、何のファイルを更新したのか、その履歴。

基本コマンド

全てのコミット履歴を表示する。git log中の移動はVimと同じ。

内容は、commit時に自動で割り当てられたＩＤと、投稿者、メールアドレス、日時、コメント３行など。

 

ファイル名を指定する

ファイル名を指定すると、そのファイルだけの履歴を全件表示してくれる。

 

–onelineオプション

commitの状態を１行で確認する

１コミットを１行で表示してくれる。IDとファイル名とコメント１行だけ。投稿者やメールアドレスも表示されない。

 

–pretty=shortオプション

commitの状態を１行コメント＋αで表示する。

git logのコメント１行版のようなもの。メールや投稿者は表示される。

 

-nオプション

最新のコミットn件見たい場合に使う。単にgit logとすると大量のログが表示されてしまうので、通常は-nか–onelineで絞る。

 

 

-pオプション

commitの状態を変更された場所も見たいときに使う。

git logのコミット情報に加えて、ファイルの差分も表示する。緑色で示された箇所が変更された箇所。

 

–statオプション

commitの状態をどこが変更されたではなく、どのファイルが何カ所変わったかを見る。沢山のファイルを扱っている場合に効果的。

 

 

 

 

削除する方法

gitで管理しているディレクトリからファイルやディレクトリを消す場合は、gitで管理をしている以上、勝手に消したら、管理しているgitからすると一体全体どこにいっちゃったんだ？となってしまう。消す場合は、下記コマンドを実行すること。

 

リポジトリ上のファイル（作業ディレクトリ含む）を消したい

git rmだけでは、作業ディレクトリのファイルが消えて、ステージングエリアに上がるだけなので、さらにcommitしてあげないといけない。

 

.gitignoreを忘れてGit管理の対象に入って間違ってコミットしてしまったファイルを、git rmコマンドで、コミットしたファイルをGitの管理から削除できる。

 

先走ってコマンドを使用せずに、deleteキー等で消しちゃった。

その場合は、git statusでdeleted: index.htmlと赤字で表示される。なので、これをgit add / commitすればよい。削除という変更をリポジトリに上げればよい。

 

リポジトリ上のファイルだけを消したい

ローカルにファイルは残してGitの管理だけを外したい。

 

リポジトリ上のディレクトリを消したい

ファイルごとGit管理から削除、ディレクトリも一緒に削除

 

 

戻すときは、git checkout

とする。

 

変更されたファイルの差分表示

作業ディレクトリとステージングエリアとの差分

diffとはdifferenceの略。git addやgit commitする前に、本当に変更に間違えがないかを念のために確認するときに使う。

作業ディレクトリがクリーンな状態では何も表示されない。

ファイルに修正を加えた状態でgit diffをすると変更を示してくれる。差分は緑で表示。

さらにgit add .をして、git diffをしても何も表示されない。これはステージングに上げているから。

ステージングと最新コミットとの差分は下のgit diff HEADを使う。

 

ステージングとコミットとの差分

HEADをつけるとステージングとコミットとの差分になる。

 

 

ステージングエリアとローカルリポジトリとの差分

ステージングにあるファイルの変更箇所を見たい場合は、とする。作業フォルダ・ステージングどちらにあるかでコマンドが違う。

 

 

 

ブランチについて

ブランチとは別々のバージョンを並行して開発したい場合に使用する。ちょっとした機能を試したいときに、さっとブランチを作って、そこで作業してうまくいったらmasterにどんどん取り込んでいくように開発を進めればよい。

ブランチの一覧を見る

何もない状態なら、* masterと表示される。これは最初に作られるブランチで、米印 * が今自分がそこにいるということを示す。

ブランチを作る

この状態でgit branch（一覧を見る）をすると、hoge *masterの両方が表示され、変わらず*がmasterについていることがわかる。

ブランチを移動する

これでhogeに移動でき、git branchで見ると、hogeに * がついていることがわかる。ここでファイルを作成してcommitしてもmasterには影響を及ぼさない。ためしにmyscript.jsをhogeで作成して、git add . とgit commit – m “myscript added”を行いコミットして、git checkout masterに戻ったら、作業ディレクトリにはmyscriptは存在しなかった。そして、git checkout hogeに戻ると、myscriptがあった。完全に別になるのだ。

ブランチをマージする。

今回はhogeで作ったものをmasterに組み入れるマージ。その場合は、上記コマンドをmasterに移動してから入力する。するとmasterにも同じファイルができる。

ブランチを削除する

これでhogeブランチを削除できる。その後git branchで確認しても、残っていない。

ブランチを作ってそのブランチにチェックアウトする。

 

マージで衝突（コンフリクト）が起きた場合

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だよ。

これは上記のように変更して。git add . / git commit -m “conflict fixed”などとすればよい。その後、git logで見てみると、Mergeをしたとログに残っている。

 

タグをつける

主なコミットに別名をつけること。よくある使い方は、「バージョン１はこのコミットだよ」という具合です。git showやgit resetでもこのタグ名を指定することができる。

直前のコミットにタグをつける

これでgit logで見ても、commit 02c4d0651442**** (HEAD -> Master , tag: v1.0)となっている。

コミットを指定してタグをつける

のように、ID名十分な桁数を後ろにつけること。

 

タグの一覧を見る

これでv1.0表示される。

 

タグの削除方法

-dオプションを使うこと。

 

 

エイリアスをつける

エイリアスとは、gitの色々な命令に短縮名をつけるもの。タグはcommitIDにつける別名。たとえば、git checkout とか結構打つの面倒だけど、それを短く登録する。

 

checkoutをcoで登録する

これでcoでcheckoutが使える。

エイリアス使用例

エイリアスなどの設定を一覧表示する。

 

注意事項

gitで管理している場合は、rmやmvで削除や移動をしてはいけない。一体全体どこにいっちゃったんだ？ということになる。削除や移動をする場合は、下記のようにする。

 

管理対象外とする

error.logのようにサイズが大きくなったり、そもそもバージョン管理する必要がないファイルはgitの管理下から外す方法がある。同じフォルダ内に、.gitignoreというファイルを作り、その中にログ系のファイルなら、*.logと入力する。logというフォルダなら、/log/とする。windowsでドットから始まるファイルを作るには、.gitignore.のように前後にドットをつけるとうまくいく。この設定を行えば、git statusで見ても、バージョン管理にはerror.logは反映されない。まｔ.gitignoreファイルの適用範囲は、置いたディレクトリ下位のファイルに反映される。

 

macで自動生成されるファイルや、パスワードが記載されているファイルは対象外にする。

 

#と書くと#から始まる行はコメント

指定したファイルを書くとそのファイルが除外 index.html

ルートディレクトリを指定　/root.html

ディレクトリ以下を全て除外 dir/

 

 

 

Q&A

直前のcommitを変更する（に含める）

commitしたけど、やっぱりもう一度編集して上げたいとき、commitがどんどん増えていくので、直前のcommitに含めてしまおうというときに使う。

 

戻すとき

直前のcommitまで戻したい。

この場合は、commitが戻るだけ。作業ディレクトリまでは戻らない。つまり元ファイルは戻らない。

 

直前のcommitまで作業ディレクトリ（元ファイル）ごと戻りたい。

 

直前より前のcommitまで戻りたい。

More?と聞かれるので、^で答えること。これで直前の１つ前まで戻れる。–hardは必要に応じて。

 

comitIDを指定して戻りたい

05c769aは実際は戻りたい箇所のcommitID。最低７ケタ。–hardは作業ディレクトリごと戻す。

 

前回取り消されたところに戻りたい

今回例ではgit reset –hard 05c769aで一番最初のcommitに戻ったが、やっぱりその上のcommitだった。と言う場合、最初のcommitに戻ってしまうのは、初期に戻ってしまうということだから、後の祭りになる。しかし、ORIG_HEADには前回取り消されたHEADの情報が１個だけ入っている。ここに戻れる。

 

特定のファイルだけ前の状態に戻したい

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を使うようだった。

 

 

共有リポジトリ

フォルダを共有リポジトリとして登録する

共有リポジトリにしたいフォルダまでcdして、上記コマンドを使う。共有リポジトリのディレクトリ名は、ourweb.gitなどと、.gitにするのがお作法。

 

リモートリポジトリに登録する

git pushでリモートリポジトリにあげる場合、リモートリポジトリに登録する必要がある。git remote addでローカルリポジトリをリモートリポジトリに登録できる。名前はよく使われるのがoriginなので、originで登録する。

 

リモートのoriginがどこにあるのか確認する

のどちらかで確認できる。

 

共有リポジトリを削除する

これで削除できる。

 

masterの内容をoriginに突っ込む

これでourweb.gitの中に意味不明なファイルが出来ている。

 

同じ内容をcloneする。

userbをデスクトップに作ったので、そこから../でourweb.gitディレクトリを指定。myweb2という中身で保存する。（userbを作る作業は実際は不要。デスクトップからgit clone ourweb.git myweb2でＯＫ。

 

USERBから共有リポジトリourweb.gitにプッシュする

myweb2にあるindex.htmlを編集し、git add . / git commit -m “line 3 added”とし、

とする。ここで重要なのは、リモートの情報も引き継がれるので、git push origin masterが使える。

 

またhtdocs7側でmyweb2で行って変更をpullで引く

 

共有時のトラブルについて

今回、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して下さいよとなる。