はじめに
Gitを使用する際に、よく見るサイトや、Git運用、コマンドなどをまとめました。
Git - Book
公式サイト。公式こそ正義。サルでもわかるGit入門
とてもわかりやすい入門サイト。
Git運用について
- みんな好き勝手に、ブランチ名決めるとわかりづらい。基本的なブランチ名を決めよう
- Gitコマンドは、色々あってわかりづらい。運用手順と使用するコマンドを決めよう
というもの。代表的なのは、以下の3つ。
GitLab の公式ドキュメントがとてもわかりやすいので、こっちみた方がいいかもしれないです。
Git-flowとは
Gitのプラグインを指します。また、そのプラグインを使って実現するGitのブランチモデル(運用手順みたいなもの)も総称してGit-flowと呼ぶこともあります。
ブランチ数や、運用手順がやや複雑ですが、これ以降に出てくるブランチ名や、運用の原点となっています。
GitHub-flow
Git-flowだと運用が煩雑なので、GitHub-flowはシンプルになりました。
GitHub-Flowだと master ブランチと feature ブランチで構成されます。
- 本番用の
masterブランチから、用途に合わせた名前のブランチ(ここではfeatureと呼称。 Git-flowでいう、feature/hotfixブランチが近い)を作成。 - 作成した
featureブランチで作業を行い、作業が終わったらリモートブランチへpushする。 - GitHubの機能である
Pull Requestを使って、レビューが完了したらmasterブランチへmergeする。 - マージ後の
masterは、すぐに本番へデプロイする。
GitHubの機能(Pull Request/Issues/継続的インテグレーションツール連携)の利用を前提とした運用手順です。
GitLab-flow
ユーザに通知なく、リリースできないタイプのアプリだと、GitHub-flowだと面倒です。
GitLab-flowでは、リリースに関するブランチが追加されました。
-
productionブランチを置くパターン-
masterとは別に、本番リリースする用のproductionを作成するもの。 -
masterは完成品という点では変わらず、productionはリリース時間を調整するもの。
-
-
production/pre-productionブランチを置くパターン -
stable/releaseブランチを置くパターン- 細かい版管理をするパターン。最新版
releaseと、安定版stable - 最新版
releaseと、安定版stableは両方とも本番。版が違うだけ。
- 細かい版管理をするパターン。最新版
GitHubクローンであるGitlabの機能(Merge Request/Issues/Gitlab CI・CD連携)などを前提としています。
よく使うGitコマンド
GitHub-flowっぽい運用を想定して、使用するGitコマンドをまとめました。
一般的な操作
ブランチの作成など
# ローカルリポジトリを作成
git init
# リモートリポジトリをローカルへコピー
git clone REPOSITORY_PATH
# 新規ブランチの作成
git checkout -b BRANCH_NAME
インデックスにファイルを追加
# 作業ツリーにある新規作成/更新/削除されたファイルをインデックスに登録
git add --A
# -p : 変更差分を確認しつつ、インデックス登録できる
# 状態を確認
git status
コミットとリモートリポジトリへのプッシュ
# コミットメッセージをつけてコミット
git commit -m 'MESSAGE'
# リモートリポジトリへ指定したブランチをpush
git push origin BRANCH_NAME
# リモートリポジトリへ現在のブランチをpush
git push origin HEAD
# --force-with-lease : リモートリポジトリのブランチを上書きしてpush、正確な動きはリンクを参照
ブランチの削除
# マージ済みのブランチ削除
git branch -d BRANCH_NAME
# マージされていないブランチの削除
git branch -D BRANCH_NAME
最新masterの変更取り込み操作
mergeによる最新masterの取り込み
すでにレビュー中で、他の開発者に影響が出るブランチは、mergeを使用して、最新のmasterを取り込みます。
# masterブランチへ移動
git checkout master
# masterブランチを最新の状態にする
git pull origin master
# 最新masterの変更を取り込みたいブランチへ戻る
git checkout BRANCH_NAME
# masterを使用して現在のブランチをmerge
git merge master
rebaseによる最新masterの取り込み
レビュー前の、featureブランチなど他の開発者に影響が出ないブランチは、rebaseを使うことが多いです。
# masterブランチへ移動
git checkout master
# masterブランチを最新の状態にする
git pull origin master
# 最新masterの変更を取り込みたいブランチへ戻る
git checkout BRANCH_NAME
# masterを使用して現在のブランチをrebase
git rebase master
rebase時にコンフリクトなどが起こる場合
# コンフリクトが発生してマージできなかったファイルを確認
git status
# コンフリクトが発生しているファイルを修正(手動)
# コンフリクト修正後、修正を反映するためにadd
git add FILE_PATH
# コンフリクトが修正した後に、rebaseを再開
git rebase --continue
# rebaseキャンセル
git rebase --abort
リモートリポジトリに rebase した結果を反映させる時
# リモートリポジトリにすでにpushしたブランチがあり、それを上書きする時
git push origin BRANCH_NAME --force-with-lease
誤操作の修正に使用するコマンド
ファイルを直前のコミット状態に戻したい時
# 全てのファイルをHEADの状態に戻す
git checkout HEAD .
直前のコミットを削除したい時
# 直前のコミットを削除(git reset --mixed HEAD^と同じ)
git reset HEAD^
# --soft : 作業ツリー(作業ディレクトリ)はそのまま、インデックス(ステージングエリア)もそのまま
# --mixed: 作業ツリー(作業ディレクトリ)はそのまま、インデックス(ステージングエリア)は削除
# --hard : 作業ツリー(作業ディレクトリ)、インデックス(ステージングエリア)共に削除
全てコミットは削除されるが、消え方が微妙に違う。HEADに関しては下記の記事を参照。
コミットメッセージを修正したい時
# コミット履歴を確認
git log
# 直前のコミットメッセージを修正
git commit --amend
# メッセージ修正は vi と同じ要領
# コミット履歴を確認
git log
レビュー/レビュー終了後の操作
リモートブランチのローカルコピー
# リモートリポジトリとリモート追跡ブランチの同期
# -p オプションでリモートリポジトリで削除されたブランチをリモート追跡ブランチからも削除
git fetch -p
# リモート追跡ブランチからローカルブランチを作成
git checkout -b BRANCH_NAME origin/BRANCH_NAME
マージした不要なローカルブランチの削除
# masterブランチへ移動
git checkout master
# masterブランチに対してマージ済みのブランチを表示
git branch --merged
# 不要なブランチの一括削除 grep および xargsを使って git branch -dを連続実行
git branch --merged | grep -v '*' | xargs -I % git branch -d %
最後に
あんまり使いませんが、git rebase -i などを使ってコミット履歴操作など追加するかもしれないです。
GitHub-flowっぽい運用であれば、ここにあるコマンドで十分だと思います。