スポンサードリンク

Git 自分の備忘録

gitとは

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

gitの考え方として、
1.作業ディレクトリ(色々なファイルを作ったり編集する作業場)
2.ステージングエリア(一旦ここにあげる場所)
3.リポジトリ(ローカル、リモート)(さらにここにあげ、プロジェクト全体を保存)
の3段階で管理する。

 

インストール方法

gitはhttps://git-scm.comからダウンロードする。exeを実行する。インストール先をきいてくるが、デフォルトのc:\Program Files\Gitで。

 

初期設定

gitはデータを保存するときに必ず保存した人の名前とEメールを記載することになっているので、まず、その設定をする。

color.uiはメッセージの色分けをしてくれる設定。autoCRLFは自動でgit addかgit commitをしたときに、自動でCRLFに直してくれるおせっかい機能。LinuxはLFなので勝手に直さないようにしておく。ちなみに、htdocsのKWSを初期に運用したときに、Warning: でLFになってるので、CRLFに直しますよとメッセージが出て、1つファイルを直して、上げてみると、CRLFに変更されていた。これはマズイと思い、この設定を見つけた。本当に変換されるらしい。おせっかいだ。

 

次に、c:\xampp\htdocs7というディレクトリを作成し、cd c:\xampp\htdocs7に移動し、git initを使用する。これは、このhtdocs7というディレクトリをgitで使うよという宣言になる。これでhtdocs7でgitが使えるようになる。

ちなみに、このgit initという作業で、htdocs7のディレクトリの中に、.gitというフォルダができる。エクスプローラーでは見えないが、パスで.gitを指定すると開ける。ここにリポジトリの一切合財が保存されるのだろう。なので、インストールしたc:\Program File\gitに保存されているのは、プログラムだけのようだ。

 

操作方法等

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

 

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

 

ステージングエリアからリポジトリに上げるコマンド

とする。するとエディタが立上がってメッセージを入れるゴチャゴチャした画面になる。その一番上にコメントをいれ保存する。操作はvimと同じ。

 

ステージングエリアからリポジトリに上げるときコメントも同時に入れる

-m “メッセージ”をオプションでつける。

 

addとcommitを一気にやる

 

 

削除する方法

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

 

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

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

 

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

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

 

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

 

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

 

 

コミット履歴の確認

commitの状態を確認する

とする。ちゃんとさきほどのcommitが保存されているのがわかる。その内容は、commitした自動で割り当てられたIDらしきもの、投稿者、日時、後はさきほど自分がつけたコメントになる。

 

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

とすると。commitコメントは普通3行だが、1行で表示してくれる。AutherやEmailは表示される。

 

 

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

とすると、1行だけで表示してくれる。その場合は、IDと自分がつけたコメントだけになる。AutherやEmailも表示されない。–pretty=shortより省略されている。

 

特定のディレクトリやファイルのcommit状態を確認する

 

commitの状態を変更された場所まで見たい

とすると、git logのコミット情報に加えて、何がどう変更になったのかを表示してくれる。

 

commitの状態をどこが変更されたではなく、どのファイルが何カ所変わったかで見る

沢山のファイルを扱っている場合に効果的。

 

git logが行数多くてページがまたがる場合

commitの件数が多いときgit logをすると、全部表示できなくて、「:」で一旦止まってしまう。Enterキーを押すと、さらに次が表示されるが、終いには「END」と表示されるだけでどうしていいか分からなくなる。その場合は、「q」のキーを押せばgit logが終了する。要するにLinuxのlessみたいなもんだ。一気に「END」まで行きたいときは、スペースキーを押せばいい。そこから「q」は必要だが。

 

 

今の状態を確認する

gitは3つの状態で管理をしていくので、長く作業をしているとどのファイルをどの場所に置いたかわからなくなるので、そういう時に使う。

 

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)・・戻しなさい。
という次にやることを丁寧に教えてくれる。git status。

何も変更がなければOn branch master nothing to commit , working tree cleanと表示される。

 

戻すときは、git checkout

とする。

 

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

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

modifiedの場合、何処の箇所が変更されたのかを調べるコマンドが、
line 1
+line 2と、変更箇所まで教えてくれる。
これは今さっき変更してステージングに上げてないものにしか使えない。

 

git add index.htmlでステージングにあげ、git statusを見ると、先ほどは、Changes not staged(ステージングされてないよ)だったのが、Changes to be committed(コミットされてないよ)になっている。

 

作業ディレクトリとローカルリポジトリとの差分

 

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

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

 

コミットの内容を示す

git show v1.0など、別名指定することもできる。

 

 

 

ブランチについて

ブランチとは別々のバージョンを並行して開発したい場合に使用する。ちょっとした機能を試したいときに、さっとブランチを作って、そこで作業してうまくいったら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をしたとログに残っている。

 

タグをつける

主なコミットに別名をつけること。よくある使い方は、「バージョン1はこのコミットだよ」という具合です。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は反映されない。まt.gitignoreファイルの適用範囲は、置いたディレクトリ下位のファイルに反映される。

 

 

お作法

コメントの入力お作法

gitでは標準的に

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

 

 

Q&A

直前のcommitを変更する(に含める)

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

 

戻すとき

直前のcommitまで戻したい。

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

 

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

 

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

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

 

comitIDを指定して戻りたい

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

 

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

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

 

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

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を分けるメリットが無い。何でもかんでも変更を一切合切今日一日ご苦労さんで、1commitにしてしまうと、ある特定のファイルだけ戻すことができない。なので、普通commitはコメントで判断できるくらいに細分化して分けることが推奨される。しかし、resetで戻ると時系列で戻ってしまうので、あれ?と思って調べたらcheckoutを使うようだった。

 

 

共有リポジトリ

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

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

 

htdocs7(A)のリポジトリから先ほど作成した共有リポジトリを登録する

名前はよく使われるのがoriginなので、originで登録する。

 

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

で確認できる。

 

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

これで削除できる。

 

masterの内容をoriginに突っ込む

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

 

同じ内容をcloneする。

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

 

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

スポンサーリンク




スポンサーリンク





投稿日:

執筆者: