git 初心者向けに github-flow の具体的な手順と注意点を記載してみました。
1. master を最新にする
現在masterにいる場合
git pull
現在master以外にいる場合
# いったん古いmaster削除
git branch -d master
# origin最新化
git fetch --prune
# 最新のmasterにスイッチ
git checkout master
# 編集中のコンフリクトがあってスイッチできない場合
## いったん退避
git stash
## スイッチ
git checkout master
## 退避戻す(ここでコンフリクトしたら後述 7 の手順を行う。)
git statsh pop
2. これからやる作業(の完了条件)をイメージして、ブランチを作る
git checkout -b feature/ブランチ名
- これで master をベースに新しいブランチが作られ、そのブランチに切り替わる。
- ブランチの命名:
- 作業開始する際に 「○○の機能を作ろう/直そう」 と決めてつけるもの。
- 集中して作業し終われる分量(数時間、1日、2日とか)のスコープをイメージして名前をつける。
- 大文字小文字、数字、ハイフン(
-
)、アンダースコア(_
) が使える。 - 記号は使わないのが無難。(コマンドラインで使う場合に変な動作を起こしうるので。)
- 作業完了後(Pull Requestのマージ後)に、このブランチは削除される。
-
feature/
から始まっているブランチをリストアップすることで、現在走っている機能改修の全量が判る。
- 大文字小文字、数字、ハイフン(
3. 作業を行う
4. コミットする
4-1. 事前確認
コマンド: git diff
(もしくは diff をみられるツール)
- 修正内容を確認しながらコミットするファイルを選別し、コミットの分類イメージを作る。
- 全行、必ず確認すること。
これをしないと、入れてはいけないソースを入れてしまったり、
最悪、パスワードいれてしまったり等あるもの。
(これらを履歴から消すのは簡単ではない。)
また、全行読まないと、理由も正確に分類できないはず。
4-2. コミットするファイルを選ぶ
今回のコミットに含めるファイルを選択する。
操作はIDE上でやってもよいし、コマンドでやっても良い。
コマンドでやるなら下記:
やりたいこと | コマンド |
---|---|
ファイルをコミット対象に | git add ファイルパス |
ファイル削除をコミット対象に | git rm ファイルパス |
ファイル移動(リネーム)をコミット対象に | git mv 移動前 移動後 |
ファイルをコミット対象から外す | git reset HEAD ファイルパス |
4-3. コミットする
git commit
コミットは必ず理由を書く:
- 理由を書かないと、該当行が別の人によって戻されてしまうかもしれない。
- 理由の単位ごとでコミットを分ける。
- 新規の機能追加なら、例外的に理由は不要(理由深掘っても無意味なので)。
全ての行にコミットが紐ついている:
- 全てのソースの行にはそれが生まれた(もしくは最後に書き換わった)コミットコメントと、
その行を生み出した(もしくは最後に書き換えた)人が、
紐ついていて git blame により簡単に参照できるようになっていると思うと、
コミットコメントのあるべきイメージがつかみやすいのではないか。
5. 前述3~4 を繰り返し、イメージした機能を一区切りさせる。したら、push して Pull Request 出す。
5-1. プッシュ: git push origin feature/ブランチ名
※絶対に -f は使わないこと。push できなくて困ったら相談を。
5-2. ここでもしもコンフリクトしたら(pushが失敗することになる)、後述6の手順で解決してから、再pushする。
5-3. Pull Request を送る。
- Pull Request タイトル: デフォルト(=ブランチ名 or コミットコメント)
- Pull Request 本文: 空欄でも可
※内容はブランチ名やコミットコメントみれば判るので。
※もしも、ブランチ名やコミットコメントにズレがあったり、わかりづらさがあるなら適宜、タイトルや、本文で補足する。
※もしも、別 Pull Request を先にマージすべきなら、この本文で 「#xxx を先に。」 と書く。
※もしも、まだ途中であり、マージ&ブランチ削除を望まないなら、タイトルの頭に [WIP] をつける。
5-4. (任意) マージ後、ローカルPC上のブランチを削除する。(PCの空きが増える。)
リモート: git fetch --prune
ローカル: git branch -d feature/ブランチ名
※未マージのコミットを含むならエラーで教えてくれる。-D で強制できるが慣れないうちは必ず相談。
6. master とのコンフリクトを解決する。
6-1. 未コミットの修正退避: git stash
6-2. master に戻る: git checkout master
6-3. master を最新にする: git pull
6-4. 対象のブランチに戻る: git checkout feature/ブランチ名
6-5. 最新を取り込む: git merge master
※通常はここでコンフリクトすることになる。もしも auto merge (自動解決) されたら、6-8 へ。
6-6. マージエディタでコンフリクトを解決する。
6-7. マージコミットを作る: git commit ※commitコメントは自動で入るので編集せずに保存する。
6-8. 未コミットの修正戻す: git stashしていたなら git stash pop
※ここでコンフリクトしたら後述 7 の手順を行う。
6-9. 再push: git push origin feature/ブランチ名
※stash の手順は、コンフリクトの可能性が全く無いなら省略して良い。
7. stash pop でのコンフリクトを解決する。
7-1. マージエディタでコンフリクトを解決する。
7-2. stash のゴミ削除: git stash drop
※コンフリクトが起こると git stash pop した際に stash が消えないので。
※git stash list で stash の一覧が見れる。
8. マージのポイント
マージで起こりがちな致命的ミス:
- うっかり、他人の修正をなかったコトにする。
- 下のほうにあった(コンフリクトしてない)マージを見落として修正を無かったことにする。
- マージコミットに関係ない修正を含めてしまう。
これらの防ぐための対策:
- マージエディタを使う
- マージの場所を目で探さない。マージエディタの上下(前/次)を使う。
- マージの完了を目で判断しない。マージエディタに判断させる。
- blameを使う
- コンフリクトしたソースは必ず blame で意図(コミットコメント)をチェックする。そして、コミットした人に確認することを遠慮してはいけない。
- stashを使う
- マージ前に stash しておくことで、関係ない修正(次工程の修正等)が混入することを防げる。
9. git の初期設定(メモ)