overview
- Gitを使った開発の流れを全て時系列で整理してみたよ！
- 基本CLIでSourceTreeは使わないので細々したことをよく忘れるのでメモとして。
- remote環境に入ってCLIしか使えない環境でGit操作する時とかってSourcetreeしか使えないと詰むので、あらかじめCLIでGitをマスターしたい。
- 随時更新
Get Staretd!
issueの作成
ポリシー
最初の一歩を踏み出す前に、最後の一歩を想像しよう！
- とどこかの有名な人が言っていました。
- 「始める前に終わった瞬間のことを考えたか」
- ちゃっちゃとタスクを消化していくために心がけていることです。
- 以降で、issueをベースにタスク管理をしていきますが、その際にコレを大事にしています。
issueで全てのタスク管理
- 仕事でもプライベートでも、全てのタスクをgitのissueを使って管理しています。
- 色々あるけどIssueにした理由
- コードと親和性が高い
- そこそこに汎用性が高い
- 移ろいゆくブームに惑わされない
- 履歴がぜ〜んぶ残る
- 不便だな〜と思うところ
- カレンダー表示ができない
- サクッと作れない
- エンジニア以外に共有できない
- 基本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