Git Life

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

1. タイトルはissue名と同じに設定

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

# Reference
#0

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

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

レビュー

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

レビュー対応

1. commit

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

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

Merge

1. 頑張ったら最後はMergeされる。
2. 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