overview

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

Get Staretd!

issueの作成

ポリシー

最初の一歩を踏み出す前に、最後の一歩を想像しよう！

とどこかの有名な人が言っていました。
「始める前に終わった瞬間のことを考えたか」
ちゃっちゃとタスクを消化していくために心がけていることです。
以降で、issueをベースにタスク管理をしていきますが、その際にコレを大事にしています。

issueで全てのタスク管理

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

issue template

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

issue templateの雛形

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

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

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

commitを１つにまとめる

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

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

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

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

// 保存して終了
esc
:wq

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

// 保存して終了
esc
:wq

最新remoteブランチを取り込み

remote最新との差分を表示

git fetch
git diff --stat origin/main

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

Mergr/Pull Request

タイトルはissue名と同じに設定
discriptionには最低でも対応するissueを記載

# Reference
#0

merge時にリモートブランチを削除するにチェック
asigneeはmergeして欲しい人を設定

レビュー

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

レビュー対応

commit

こんな感じでレビュー対応のcommitメッセージを作ると履歴が綺麗！

git commit -m'[レビュー対応] #0 誤字を修正'

Merge

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

Hint

似たようなcommitを１つにまとめる

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

expected

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

actual

// 直近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