【メモ】github-flow の手順（git初心者向け）

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. マージのポイント

マージで起こりがちな致命的ミス:

1. うっかり、他人の修正をなかったコトにする。
2. 下のほうにあった（コンフリクトしてない）マージを見落として修正を無かったことにする。
3. マージコミットに関係ない修正を含めてしまう。

これらの防ぐための対策:

1. マージエディタを使う
   1. マージの場所を目で探さない。マージエディタの上下（前/次）を使う。
   2. マージの完了を目で判断しない。マージエディタに判断させる。
2. blameを使う
   1. コンフリクトしたソースは必ず blame で意図（コミットコメント）をチェックする。そして、コミットした人に確認することを遠慮してはいけない。
3. stashを使う
   1. マージ前に stash しておくことで、関係ない修正（次工程の修正等）が混入することを防げる。

9. git の初期設定（メモ）