- お知らせ -
  • 当wikiのプログラムコードの表示を直してみました(ついでに長い行があると全体が下にぶっ飛ぶのも修正)。不具合があればBBSまでご連絡下さい。

はじめに Edit

gitの個人的によく使いそうなコマンドをまとめてみました。自分用チートシートです。

よく使うコマンドは ../コマンドの省略(alias)設定をする方法にて省略形を作っておくと便利です。

各コマンドの詳細は

git (コマンド名) --help

すると記載があるのでそれ見てもらったら早いと思われます。

前提 Edit

変更したファイルをコミットするときは、

[ローカル]→(addコマンドする)→[インデックスに入る]→(commitコマンド)→[リポジトリに入る]

という状態の推移に注意して下さい。

gitでは「コミットしたいものをaddすると一旦インデックスに入るので、次にインデックスに入れたものをcommitでリポジトリにコミットする」と私は理解をしましたが、本来の用途とは別かもしれないです。

※TODO: 概念の背景を後で調べる
※Subversionように「addでファイルを追加する」というような他のバージョン管理ソフトとは概念がかなり異なっているようです。
※個人的には、インデックスの仕組みはTortoiseSVNや他のTortoiseシリーズのように、コミットする時や何か処理するときに、チェックボックスにチェックを入れたもののみ処理する感覚のように思えます

基本 Edit

git status
どんなファイルが変更、追加されたか、追加されてないファイルがあるかなどを見る。まずはこれ。
git add .
新規追加や変更したファイルをgitに知らせる,ステージングする(インデックスに記録する)
git add -i
対話的にaddする 複数のファイルのうち、あるファイルのある行だけ選んで、diffを確認して、コミットしたい時に便利。(ブランチ切り忘れてた時とか)
git commit
インデックスにあるファイルをコミットする。つまり、事前にaddしないといけない。エディタが立ち上がってコミットログを書くことになる。 -m "hogehoge"オプションでエディタの立ち上げなしでコミットログを指定できる。
git commit -a
編集したファイルをのみコミットする(= "git add -u" + "git commit" なので 新規ファイルがない場合はこれ使えばaddはいらないか)
git commit -v
エディタでコミットログを書くときに、変更点も表示する
git diff
diff形式で変更箇所の確認。微妙に見にくい。--statつけると、一覧形式で表示する(詳細は表示されない)。--color つけると色づけされてみやすい。毎回--colorつけるのが面倒なときは ../表示を色づけする方法。(厳密には、インデックスと現在のファイルを比較するので、git add .した後は見られなくなる。そのときは git diff --cached)
git diff --cached
addしたファイルの変更箇所を見る (厳密にはインデックスにあるファイルとリポジトリの比較)

編集→コミットまで(だけ)の簡易的な流れとしては、
ファイル編集→git statusとgit diffで変更点を確認→(新規ファイルがあるなら git add .)→git commit -a -v でログをエディタで書きつつコミット
という感じでしょうか?

ファイル操作 Edit

警告!gitの管理下に置かれたファイルなどは、エクスプローラーなどのファイラで削除、移動してはなりません!もちろんコマンドラインからの mv, move, delete, rmなどもダメです。そのファイル操作をgitに知らせる必要があるためです。代わりに以下を使います。
→追加や削除はgitに知らせる必要ありとして、「ファイルの移動」「ファイル名の変更」はgitは情報としてもたないようです(Subvesionのようにリネームしたという情報が記録として残る、わけではない!!)。

git mv <filename> <renamed-name>
<filename>のファイル名を<renamed-name>に変更する
ただしこれは実質上、git rmしてgit addしたのと同じです。
(git log --follow でファイル名の変更を検知できます)
git rm <filename>
<filename>を削除する。
git rm --cached <filename>
実際にファイルを消さずにgitのindexからだけ消す。間違って、git addしてしまったファイルに有効。例えば.gitignoreを書く前に不要なものをaddしてしまって、後から.gitignore追加した、しかし、ファイルは消えたら困るよ!って時に使う)

タグ付けとブランチ Edit

適当なブランチの説明と運用例:

  • 複数のバージョンを同時に並行開発する場合(例えばリリースしたのを保守しつつ(バグとりつつ)、新しい新機能搭載のバージョンを開発したい場合)は長期用のブランチを切りましょう
  • ちょっとした機能つけるときやバグフィックするときもとりあえず手軽にブランチ切って作業しましょう。機能ができたら長期用ブランチなどとマージしましょう。マージしたり、つまらない変更など、いらなくなったらブランチは削除してしまいましょう。
  • リリースするときはあとですぐにわかるようにタグを打っときましょう(バージョン番号とかで)。
git tag <tag-name>
現在のコミットに<tag-name>のタグをつける。<tag-name>の後に、引数でコミット番号を指定するとそのコミットにタグをつけることになる。git tagで全タグを表示できる。
タグ情報をpushするときは、git pull --tags を指定しないといけない。
git checkout <branch-name>
現在のコミットを<branch-name>にスイッチする。<branch-name>にmasterを指定するとヘッドにスイッチする。
git checkout -b <new-branch> [<start_point>]
新機能追加とかちょっとしたバグフィックスしたくなったらまずこれで一発でブランチ切って切り替える。 <start_point>を元に(省略可)、新しいブランチ<new-branch>を作成してそのブランチに切り替える。git branch <new-branch> [<start_point>]→git checkout <new-branch>相当を一発で行う。
git branch
ローカルのブランチ一覧を表示。いまどこのブランチにいるかもわかる。git branch -r でリモートのブランチも表示。
git branch <branch-name>
現在のコミットで<branch-name>名のブランチを作成する。git branchで全ブランチを表示できる。-dで<branch-name>のブランチの削除(マージしたもののみ。マージしてないものを削除したい場合は-D)。
git branch -m [<old-branch>] <new-branch>
ブランチ名を<old-branch>から<new-branch>に変更
git merge <branch-name>
<branch-name>をmasterにマージ(統合)しようとする。コンフリクト(衝突)が起きた場合は、表示されるはず。git diffを見るとよい。そのときは、衝突を回避した後は、git commit -aでマージする。
rebaseについて
ブランチの起点を繋ぎかえられるrebaseに関しては長くなりそうだったので別稿にまとめました

ログ、履歴などを見る Edit

gitk等のGUIツールはUTF-8 cygwin gitでもマルチバイトファイル名を利用していると文字化けしてうまく動かない罠…(Ubuntu Linuxだと文字化けしないですね)→文字化け詳細

gitk
GUIで履歴を見られる。便利。git show、git logとかやるよりこっち見た方が早い。--all で関連する履歴以外も全部表示する
git show
最新のコミット履歴を見る。引数指定で任意の履歴を見ることもできる。
git log
ログの詳細を見る。-pで差分表示。--stat --summaryでログメッセージ修正したファイルなどの参照。--graphつけると素敵なASCIIグラフ表示なる。
git ls-tree -r <commit-name>
<commit-name>で指定したコミット番号の登録されているファイル郡を全部(-rで再帰的に)表示する。<commit-name>にmasterだとヘッドに登録されているもの全部。gitkで見た方が早い。

複数人で使う場合 Edit

git clone <URL>
<URL>のリポジトリを複製してローカルに持ってくる。<URL>はローカルのディレクトリ名でもよい。svnのチェックアウト相当。
git pull
cloneで複製したリポジトリを元のリポジトリの更新を反映する。svn の update 相当。
= git fetch; git merge origin/master
= git pull origin master (masterの場合)
なので、更新したくない、ただ単に複製元から変更を取得したいという場合は、git fetchだけでよい。
参考:git pull を使用して更新する
git push
commitした変更を元のリポジトリに反映する

その他 Edit

<filename>を消してから、 git checkout <filename>
コミット前に弄る前のファイルに戻す。(優しいgitの育て方参考)
git reset --hard HEAD
コミット前に全部、弄る前に戻したいってとき。コミットしちゃった後で1つ前のコミットに戻すときは、HEAD^にする。
Gitでコミット前の状態にもどすを参考)
git commit --amend
前のコミットをやめて、上書きコミット。というか、直前のコミットログの修正に使える。詳細
git reset --soft HEAD^
今あるファイルをそのままに、一つ前(HEAD^)のコミット前に戻す。「必要ないファイルいろいろgit addしてcommitしたけど git commit --amend だと簡単に修正できなくね?」なんてとき。--softの代わりに--hardだと、今あるファイルごとコミット前に戻せて便利だけど追加したり変更したファイルも戻ってしまう(はず)なので注意。
git clean --dry-run
untrackedになっているファイル(addでindexに入っていないファイル)を削除するgit clearnで、何が削除されるかを確認する。
git clean -f
untrackedになっているファイルを実際に削除する。--dry-runで確認してからね。ディレクトリは対象にならない。ディレクトリも削除する場合は -d も付加する。

参考リンク Edit

このページに載っていないコマンドは下記サイトにいろいろ載ってますので、合わせて参照下さい。


Show recent 10 comments. Go to the comment page.

  • 他のバージョン管理の要領でインデックスの概念の意識しないで使うとわけわかめになると思ったので、indexの話を記載 -- TOBY 2010-05-15 (Sat) 16:57:18
Name:

Front page   Edit Freeze Diff Backup Upload Copy Rename Reload   New Pages Search Recent changes   Help   RSS of recent changes
Last-modified: 2011-07-04 Mon 12:01:03 JST (1025d)