Git Life

# overview
- Gitを使った開発の流れを全て時系列で整理してみたよ！
- 基本CLIでSourceTreeは使わないので細々したことをよく忘れるのでメモとして。
    - remote環境に入ってCLIしか使えない環境でGit操作する時とかってSourcetreeしか使えないと詰むので、あらかじめCLIでGitをマスターしたい。
- 随時更新

# Get Staretd!
## issueの作成
### ポリシー
> 最初の一歩を踏み出す前に、最後の一歩を想像しよう！
- とどこかの有名な人が言っていました。
- 「始める前に終わった瞬間のことを考えたか」
- ちゃっちゃとタスクを消化していくために心がけていることです。
- 以降で、issueをベースにタスク管理をしていきますが、その際にコレを大事にしています。


### issueで全てのタスク管理
- 仕事でもプライベートでも、全てのタスクをgitのissueを使って管理しています。
- 色々あるけどIssueにした理由
    1. コードと親和性が高い
    1. そこそこに汎用性が高い
    1. 移ろいゆくブームに惑わされない
    1. 履歴がぜ〜んぶ残る
- 不便だな〜と思うところ
    1. カレンダー表示ができない
    1. サクッと作れない
    1. エンジニア以外に共有できない
    1. 基本PCで作業することになる
- まあ色々ありますけど、僕にはこれが最適でした。


### issue template
- issueでタスクを管理する際、必ず２つの項目を書くようにしています。
- テンプレートが決まっていると描きやすいし、これは仕事でもプライベートでも応用できます。
- 動作確認から先に書く
    - 僕なりにですけど、作業内容ではなく動作確認から先に書くとissueの精度も速度も飛躍的に上がります。
    - 先に作業内容から書いちゃいがちですけど、ゴールである動作確認から書くのは理にかなってますよ。
    - テスト駆動開発だってREDから書きますよね！
    - issueは上から消化されますが、作るのは下からです。

<details>
<summary>issue templateの雛形</summary>

````
# 作業内容
- [ ] ドラフト作成
- [ ] qiitaで公開

# 動作確認
- [ ] section: 概要がある
- [ ] section: issueで全てのタスク管理がある
- [ ] section: issue templateがある
- [ ] section: my issuesがある
- [ ] section: Deadlineがある
- [ ] 記事が公開されている
````
</details>

### my issues
- リポジトリの垣根を超えてissueを管理するために、asigneeを活用しよう。
- issue管理は現在はGithubではなくGitlabを使っていますが、いずれにせよ自分のissueだけを集めたいですよね。
- asigneeを自分にすると自分がアサインされたissueだけが表示されるので便利ですね！
    - 特にチーム開発とかになってくると、issueが乱雑になってくるのでこれは大事なことです。


### Deadline
- GiuhubではなくGitlabを使っている最大の理由は締切の設定。
- issueに締切を設定できるのはGitlabの良いところですね！
    - もしgithubでも労力かけずにできるよ〜ってのがあったら教えてください！（マイルストーンを１年分作るみたいな労力のかかるやつはなしで笑）
- 締切順に表示できるので優先順位を日付でつけられて便利です。



## リポジトリを複製
### Github/Gitlab上の既存リポジトリクローン
```
git clone [SSH]
```

### ローカルリポをRemoteリポと紐付ける
```
git remote add origin [SSH]
```


## 作業用ブランチを作成
```
// #1の部分は対応するissue番号
git checkout -b feature_#1
```

## Commit
<details>
<summary>commitを１つにまとめる</summary>

```
// commitログを出力
// 5は出力したいログの数
git log --oneline -n 5

// 直近２つのcommitを対象にする
git rebase HEAD~2

// viエディタが立ち上がるのでcommitを整理
// 残す?
pick

// １つ前に統合する?
squash

// 保存して終了
esc
:wq

// viエディタでcommitメッセージを編集
インサートモードiで編集

// 保存して終了
esc
:wq
```
</details>



## 最新remoteブランチを取り込み
### remote最新との差分を表示
```
git fetch
git diff --stat origin/main

// 差分があれば取り込む
git rebase develop
```

## Mergr/Pull Request
1. タイトルはissue名と同じに設定

2. discriptionには最低でも対応するissueを記載
```
# Reference
#0
```

3. merge時にリモートブランチを削除するにチェック

4. asigneeはmergeして欲しい人を設定



## レビュー
1. 気になった箇所にコメントを入れる
1. メンションつけてくれないと気づかないのでメンションする

## レビュー対応
1. commit
- こんな感じでレビュー対応のcommitメッセージを作ると履歴が綺麗！
```
git commit -m'[レビュー対応] #0 誤字を修正'
```

## Merge
1. 頑張ったら最後はMergeされる。
1. MRは至上の喜び！



# Hint
## 似たようなcommitを１つにまとめる
- rebaseを使ってcommitを整理しちゃう。
- `css修正`とかいうのが連続してしまうビビりな僕のような人のために。
- rebaseを使えばどれだけ細かくcommitしてても綺麗にできる。

### expected
```diff
// 直近10個のcommitを出力
git log --online -n 10
.
.
.
000000 [Add] #1 CSSを修正
```

### actual
```diff
// 直近10個のcommitを出力
git log --online -n 10
.
.
.
000000 [Add] #1 CSSを修正
000001 [Add] #1 CSSを修正
000002 [Add] #1 CSSを修正
000003 [Add] #1 CSSを修正
000004 [Add] #1 CSSを修正
```

### 作業
```
// 直近10個のcommitを出力
git log --online -n 10

// rebaseで作業スタート
git rebase -i <<対象の１つ前のcommit id>>

// 00000のcommitメッセージで0~3までのcommit内容をまとめる
// pickは対象のcommitメッセージをそのまま使う
// rは対象のcommitメッセージを編集して使う
// sは対象のcommitを1つ前のcommitにcommitメッセージはそのままで統合する
pick 00000
s 00001
s 00002
s 00003

// vimを使って保存

// 確認のためにログを出す
git log --online -n 3
```