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

git 初心者向けに github-flow の具体的な手順と注意点を記載してみました。


# 1. master を最新にする

```bash:現在masterにいる場合
git pull
```

```bash:現在master以外にいる場合
# いったん古いmaster削除
git branch -d master
# origin最新化
git fetch --prune
# 最新のmasterにスイッチ
git checkout master

# 編集中のコンフリクトがあってスイッチできない場合
## いったん退避
git stash
## スイッチ
git checkout master
## 退避戻す(ここでコンフリクトしたら後述 7 の手順を行う。)
git statsh pop
```

# 2. これからやる作業（の完了条件）をイメージして、ブランチを作る

```bash
git checkout -b feature/ブランチ名
```

- これで master をベースに新しいブランチが作られ、そのブランチに切り替わる。
- ブランチの命名:
    1. 作業開始する際に 「○○の機能を作ろう/直そう」 と決めてつけるもの。
    1. 集中して作業し終われる分量（数時間、１日、２日とか）のスコープをイメージして名前をつける。
        - 大文字小文字、数字、ハイフン(`-`)、アンダースコア(`_`) が使える。
        - 記号は使わないのが無難。(コマンドラインで使う場合に変な動作を起こしうるので。)
        - 作業完了後（Pull Requestのマージ後）に、このブランチは削除される。
        - `feature/` から始まっているブランチをリストアップすることで、現在走っている機能改修の全量が判る。

# 3. 作業を行う

# 4. コミットする

### 4-1. 事前確認

コマンド: `git diff` (もしくは diff をみられるツール)

- 修正内容を確認しながらコミットするファイルを選別し、コミットの分類イメージを作る。
- 全行、必ず確認すること。
  これをしないと、入れてはいけないソースを入れてしまったり、
  最悪、パスワードいれてしまったり等あるもの。
  （これらを履歴から消すのは簡単ではない。）
  また、全行読まないと、理由も正確に分類できないはず。


### 4-2. コミットするファイルを選ぶ

今回のコミットに含めるファイルを選択する。

操作はIDE上でやってもよいし、コマンドでやっても良い。
コマンドでやるなら下記:

| やりたいこと | コマンド|
|------------|:------------|
| ファイルをコミット対象に | `git add ファイルパス` |
| ファイル削除をコミット対象に | `git rm ファイルパス` |
| ファイル移動(リネーム)をコミット対象に | `git mv 移動前 移動後` |
| ファイルをコミット対象から外す | `git reset HEAD ファイルパス` |

### 4-3. コミットする

```bash
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 の初期設定（メモ）

https://qiita.com/waterada/items/dea4d125cc3509755576