Git

Gitをある程度使えるようになったら、更に覚えておくと良いかもしれないコマンドとそのオプション

More than 3 years have passed since last update.

Git歴2年目のなんちゃってエンジニアです。

最近、業務でGitを使う機会が増え、ひと通りのことはできるようになってきたのですが、

さらなるステップアップのためにGitポケットリファレンスを読んで、Gitをある程度使いこなした人が、更に覚えておくと更に捗るかもしれないコマンドとそのオプションを幾つか紹介。

※ 独断と偏見で選んでます。


git config

Git の各種設定を表示、変更する。

以下、興味をもった設定のみ記載。



  • commit.template コミットメッセージのテンプレートをファイルで指定する。


  • core.whitespace git diffなどで不正な空白文字を検出して通知する。


  • push.default 引数なしでgit pushされた際に、どのブランチにプッシュするか指定する。


git commit

インデックスに登録した変更内容をローカルリポジトリに反映する。



  • -a バージョン管理している全変更をコミットする。


  • -c <commit> コミットメッセージを以前のコミットやタグから読み込む


  • --dry-run コミット結果を表示。実行はしない


git add

変更内容をインデックスに登録して、コミット対象にする。



  • -p パッチ形式で確認しながら1つずつインデックスに登録する。


  • -A バージョン管理対象になっていないファイルも含め、すべてをインデックスに登録する。


  • -n addコマンドの実行結果を確認する。


  • -i 変更内容をファイルずつ確認しながら、インデックスに登録する。


git rm

バージョン管理しているファイルを削除して、バージョン管理の対象外とする。



  • --cached ファイルを残したまま、バージョン管理対象からファイルを削除する。


git reset

インデックスに登録したファイルをコミット対象から外す。



  • -p インデックスに登録された変更箇所をバッチ形式で1つずつ選択して、インデックスから取り除く。


  • --hard HEAD^ 直前のコミットの一つ前の状態にソースを戻す。


git revert

コミットした内容を取り消すコミットを実行する。



  • -m parent-number マージコミットを取り消す際にどのブランチをメインラインとして残すかを指定する。


  • --no-edit revert用に自動生成されるコミットメッセージをそのまま採用する場合に指定する。


  • -n(--no-commit) revert内容のコミットを自動で行わない。


git pull

共有リポジトリ(リモートリポジトリ)から変更を取得し、現在のブランチにマージする。



  • --rebase 変更を取得した後、rebaseを行う。


  • --no-ff 必ず、マージコミットを行う。明示的にマージしたコミットを残す際に利用する。


  • --squash リモートブランチの複数のコミットを一つのコミットにまとめてブランチに取り込む。


git fetch

共有リポジトリ上のリモートブランチの変更を取得する。



  • -p 取得後に存在しなかったリモート追跡ブランチを削除する。


  • --dry-run 取得結果を確認する。取得結果の反映はしない。


git push

ローカルブランチへの変更を共有リポジトリへ送信します。



  • -u 新規に作成したリポジトリやブランチをプッシュする際に、ローカルリポジトリのブランチとプッシュ先リポジトリのブランチの対応付けを行う。


  • --mirror リモートリポジトリにローカルリポジトリの内容をそのまま複製したいときに使用する。


git remote

リモートリポジトリを一覧表示、追加、削除、変更をします。



  • -t branch pullコマンドで更新内容を取得するリモートリポジトリを限定できる。


  • remote prune <name> リモート名<name>からリモートリポジトリで削除済のブランチをローカルリポジトリから削除します。


git branch



  • --no-merged カレントブランチにマージされていないブランチを表示する。


  • --merged マージ済みブランチを表示

  • デフォルトでは共有リポジトリのタグやブランチをどのユーザでも消せてしまうので、共有リポジトリにフックを設定することでそれを防ぐことが可能。


git checkout



  • -b ブランチを作成して、切り替える。


  • -t リモート追跡ブランチからブランチ作成をする前に、作成するブランチにアップストリーム設定をする。
    ※ アップストリーム設定とはpushやpull時の指定を省略できる。


  • -p パッチ形式で確認しながら1つずつコミット時点のものに戻す。


git tag



  • -a 注釈付きのタグを作成する。


  • -s 署名付きのタグを作成する。


git archive

配布用のファイルを作成する。


git merge

対象ブランチの変更を現在のブランチに取り込む



  • --no-ff マージコミットを必ず生成する。


  • --log マージコミットのコミットメッセージにマージされるコミット郡の一行目のコミットメッセージを含める。

  • --no-commit マージ後、自動的に行われるコミットを行わない。


  • 競合発生時でファイル単位で解決を行う場合

    git

    git checkout MERGE_HEAD XXXX.txt // マージする方のファイルを優先する。

    git checkout ORIG_HEAD XXXX.txt // マージされる方のファイルを優先する。



    で解決できる。


  • Merge時にFast-forwardマージとコミットマージのどちらを採用すればよいか?

    ウォータフォール的にかっちりとした開発モデルのプロジェクトの場合はどのブランチで作業して、いつマージしたかを分かりやすく把握するためにコミットマージを使用する。開発者が分散していて、自由度の高いOSSプロジェクトの場合は、「履歴を一直線に保って見やすくする」方針を取ることが多い。



git rebase

コミット履歴を変更して、ブランチの分岐元を置き換えることができる。

また、コミットの順番の入れ替え等、コミット履歴を編集できる。


  • --onto <newbase> <upstream> [<branch>] ブランチが「どこのブランチから分岐したか」を修正します。

    実行後は、<upstream>から分岐してからの<branch>のコミット郡が、--onto <newbase> で指定したブランチから分岐したように修正される。



  • rebase | --continue | --skip | --abort

    rebase実行中に、競合が発生した場合、競合を解決してrebaseを続けるか、競合が発生したコミットをスキップしてrebaseを続けるか、rebaseを取りやめて、rebase実行前の状態に戻るか選択する。



    • --continue 競合解決中にリベースを再開したい場合に使用する。



    • --skip 競合解決中にそのコミットをスキップしたいときに使う。スキップしたコミットは適用されない。



    • --abort 競合解決中にリベースを中止し、リベース開始前の状態に戻りたい場合に使用する。




  • --squash 複数のコミットを一つにまとめる。



git log

現在のブランチのコミットメッセージを表示します。



  • --graph コミットの履歴をグラフで表示する。


  • --color 出力を色付けする。


  • --left--right 2つのブランチ間のコミットの差を表示する場合に使用する。


  • --reverse 逆順に表示する。(古いコミットから順に表示する。)


git diff

インデックスに未登録の内容や次のコミットで反映される内容を表示します。



  • --cached 特定のコミットとインデックス間の差分を表示する。


  • -w 行同士を比較するときに、すべての空白文字を無視して比較する。


  • -b 行末の差分を無視して、差分を表示する。


git show

コミットの差分、もしくはファイルの内容を表示する。



  • --oneline コミットメッセージを1行で表示する。


git blame

ファイルの特定の場所がどのコミットで変更されたかを参照できる。



  • -L <start> <end> 表示する行の範囲を指定する。


  • -M 同じファイル内でコピー&ペーストした行を検出し、元となるコミットを表示する。


git reflog

リポジトリの操作履歴を確認できる。


git svn

SubversionのリポジトリをGitで操作する。

Subversionを共有リポジトリに使用していても、ローカルではGitを使用できる。