Git 備忘録

• 時間があるなら Pro Git を読めば OK

• Git は分散型 VCS
  • （SVN とか Perforce はみんなが中央サーバにアクセスする集中型）
  • 各自のマシンにリポジトリのクローンが作られる
• リポジトリとは .git/ があるディレクトリのこと
• 差分の蓄積ではなくスナップショットを保存して歴史を管理
  • あらゆるスナップショットやコミットオブジェクトなどにダイジェスト （SHA-1 ハッシュ） がついてる

• ファイルのとりうる状態
  • Untracked / Unmodified / Modified / Staged
  • (Stash) / Workspace / Stage / Local Repo. / ……… / Remote Repo.

• master ブランチは git init した時のデフォルトのブランチ名
• origin は git clone した時のデフォルトのリモート名
• コミットは、その時の「ルートディレクトリのスナップショット」への参照を持つ
  • コミットは「1 つ前のコミット」（親コミット）への参照を持つ。これにより歴史が辿れる
  • Git のコミットグラフの図では、矢印は 1 つ前のコミットを指している。時間軸の方向ではないので注意
  • マージコミットは複数の親を持つコミット

• ブランチとはコミットを指すポインタ
  • これが Git の優れた設計ポイントと言える
  • ブランチを作るのはポインタを 1 個作る程度のコストでしかない
  • ブランチを切った時点では歴史は分岐していない。コミットして初めて分岐する
• origin/master はリモートブランチ
  • リモートにあるリポジトリ内の master ブランチが、どのコミットを指しているかを意味する
  • git fetch origin master すると origin/master がリモートと同じ状態になる

• git pull とは、git fetch して git merge しろという意味
  • git fetch origin master で origin/master が最新になる
  • git merge origin/master でローカルブランチの master に リモートブランチの origin/master がマージされる

• Pro Git
• こわくない Git
  • リベースのこととか

• A successful Git branching model
• GitHub Flow – Scott Chacon
  • 日本語訳
  • Understanding the GitHub Flow · GitHub Guides

• 巨大なリポジトリを Git で上手く扱う方法 - Atlassian Japan

業務の開発も OSS 開発のように行おうという姿勢

• 空コミット便利！git commit –allow-emptyでgitを使った開発フローを改善 - fukajun - DeepValley -
• git commit –allow-empty を使った WIP PR ワークフロー - Qiita
• github を用いた開発フロー テンプレート
• WIPブランチをPull Requestする運用をためした - 15 min/d
• Yakst - より良いプルリクエストのための10のヒント
• ピクセルグリッドの仕事術 技術編 - コードレビューのフロー | CodeGrid
  • こちらはレビュー待ちを無くすためにすぐ merge して後からレビュー、というやり方

• GIT Commit Good Practice - OpenStack
• 英語コミットコメントに使えるオシャレフレーズ集
• git commit時のコメントを英語で書くための最初の一歩
• Changelogのための英文テンプレート集
• ネイティブと働いて分かった英語コミットメッセージの頻出動詞10つ - Qiita
• Git - 英語のコメントや issue で頻出する略語の意味 (FYI, AFAIK, …) - Qiita
• commit-m: GitHubコミットメッセージの文例が検索できるサービス
• gitにおけるコミットログ/メッセージ例文集100
• Emojiで楽しく綺麗なコミットを手に入れる | MEMOPATCH
  • Atom の絵文字ガイド : atom/CONTRIBUTING.md at master · atom/atom

コミット後・push 前にリモートから差分取得する時にマージコミットができるとログが見づらくなってイヤ、 という時は merge の代わりに rebase をする以下のオプションが使われる：

git pull --rebase origin master

• チームの rebase の理解度が低いとコンフリクト時に事故が起こりやすいので注意
• Pull Request ベースで開発していて Squash Merge する運用ならこの辺はあまり気にしなくてよい

# ブランチを作ってそこに移動
git checkout -b new_branch

# ↑ は以下のコマンドのショートカット
git branch new_branch
git checkout new_branch

# --since は "2 days" みたいに柔軟な指定ができる
git log -S "target_word" --since="1 week"

git log -p {TARGET_FILE}

git branch -d branch_name     # ローカルのを消す
git push origin :branch_name  # リモートのを消す

【補足】

• git push origin master は
  git push origin master:master の略。
• ローカルブランチの master をリモートブランチの master に push するという意味。
• 上記の消すやつは空 branch を push してる感じ

git for-each-ref --format='%(authorname) %09 %(refname)' | grep 'refs/remotes/origin' | sort -k5n -k2M -k3n -k4n

誰かがリモートブランチを削除しても、ローカルでは残っている。 以下のコマンドでそれを整理できる

git remote prune origin

git branch -m <新しいブランチ名>

git branch -vv

# u は upstream
git branch -u origin/hoge

git diff > patch.txt
patch -p1 < patch.txt

• ファイル全体が差分として表示されてしまうのを避ける
• -w オプション (--ignore-all-space) をつける

git diff -w

git diff --word-diff-regex='\\w+|[^[:space:]]'

# {+ +} とかの記号も出さないバージョン
git diff --color-words --word-diff-regex='\\w+|[^[:space:]]'

# 一覧
git tag

# タグを打つ
git tag v1.0.0

# 特定コミットにタグを打つ
git tag v1.0.0 <commit_hash>

# リモートにタグ全部 push
git push origin --tags

# ログ見るとき、%d でタグ情報も表示できるよ
git log --pretty=format:"%C(yellow)%h%C(reset) %C(blue)%ad %C(reset)%C(red)%an%C(reset) - %s %C(green)%d%C(reset)" --graph --date-order -30 --date=iso

• Gitでタグの名前を変更（編集）する方法

git commit --amend -m "Fixed message"

# git add してから --amend すれば追加し忘れたファイルの追加もできる

git reset --soft HEAD^

# ワーキングツリーの内容も書き換え
git reset --hard <commitId>

• ここに書いてある方法でいけた
  • gitで特定のファイルの履歴を消す方法

git reset --hard 56e05fced
git reset --soft HEAD@{1}
git commit -m "Revert to 56e05fced"

• 2009-12 Revert to a commit by a SHA hash in Git? - Stack Overflow
• 2016-09 Gitで特定のコミットへrevertする方法 - 株式会社クイックのWebサービス開発blog

# f は force / d はディレクトリを対象に含める
git clean -fd

# x は gitignore されているファイルも対象にする
# X だと逆に gitignore されているファイルのみ対象にする
# n をつけると dry-run
git clean -fdxn

git cherry-pick A^..B

• すでに add されてるファイルはキャッシュ残ってて .gitignore 効かない
• 再反映する

git rm -r --cached .
git add .
git commit -m "Reapply .gitignore"
git push origin master

• 参考 : .gitignore の設定を反映させる

• オブジェクトの歴史を辿る git rev-list というコマンドがある
  • Git - git-rev-list Documentation
  • gitで削除してしまったファイルの復元 - itochin2の日記（仮）
• 指定したポイントから時系列逆順に commit の歴史を表示してくれる
• 以下のように打てば消えたファイルについても履歴が見れる

git rev-list --pretty HEAD -- 対象のファイルパス
# 最後の commit だけ表示したいなら -n 1 を与えればよい

• .git/info/exclude に書けばよい
  • 2020-12 自分専用の.gitignore(相当)を使おう | 株式会社ソリューションウェア

でかい差分が GitHub 上で見づらいとき

# feature -> master のプルリクの差分を見たいとき
# （トリプルドットを使う）
git diff master...feature

# 僕は周辺行を多く表示するのが好き（コンテキストを理解しやすい）
# （-U<行数> オプションを使う。grep の -C みたいなもの）
git diff master...feature -U30

• 参考
  • Atlassian Japan | さらに優れたプルリクエスト
  • Git - リビジョンの選択

git config --global core.whitespace cr-at-eol

• unpacked object の数とサイズを表示 :

git count-objects -vH

• ディスクの使用容量はまあ du -sh ./ とかで