けれど、○○な機能を実装している途中で、△△を修正しないとダメだから、先に△△の作業をやるか・・・という状況がよくある。 △△の修正だけを先にコミットしようにも、○○の作業で同じソースコードにすでに修正が入っていて、キレイに△△の修正だけでコミットするのが難しい。 だから、やむなく、○○と△△をまとめて、○○の修正として大きなコミットを作ってしまう。

処方箋

このやるせない事情を解決するために stash をうまく使ってみてほしい。

例えば、○○の作業として、「企業登録画面を作成する」というタスクがあったとする。 そして、作業中に、△△の作業が必要であることがわかったとする（例えば、電話番号のバリデーションを共通化する等）。

こんなときのやり方である。

1. ○○作業用の main ブランチを作成する（※1）
2. ○○の作業を始める
3. △△の作業が見つかった！
4. ○○の作業を、いったん stash する（※2）
5. △△のための sub branch を作成する（※1）
6. △△の作業をする
7. sub branch を commit する
8. main に切り替えて、sub branch をマージする
9. stash を復元する
10. 復元時にコンフリクトがあったら修復する（※3）
11. 元の○○の作業を再開する

補足する。

※1 mainブランチを作成する意図

• main のブランチを作っておいて、サブブランチの統合先を main ブランチだと決めておくと、サブブランチが作りやすくなる。
• ブランチ名は、プロジェクト内で規則を決めればよいが、例えば、 main ブランチは、末尾に /main を付けることにすると、↓こうなる。
• (例 main) feature/{issue-no}/create-company/main
  • {issue-no} は、チケット番号（ブランチ名に Issue の番号を入れる規則にしておくと、必ず Issue を作ってから作業することができる）
  • create-company は○○の作業名
  • main <—- /create-company をメインブランチにすると、/create-company/xxx が作成できないので、/main を末尾につけておくとよい
• (例 sub) feature/{issue-no}/create-company/shared-phone-validation
  • ブランチ名には相変わらず issue-no が含まれているし、このsub branch の作業が何キッカケで必要になったのかがわかる。
  • サブブランチ化して作業すると、△△の作業に、あとから修正が必要だとなったときに、このサブブランチに戻って作業ができる
  • コードレビューもサブブランチ単位に小さく依頼することができる

※2 stash の使い方

• 新規のファイルは stash から漏れるので -u のオプションを付ける
• stash は、保存時に stash 名も指定しておいた方がよい
• 保存時
  • git stash save -u ‘hoge’
  • stash はログが残らないので、名前は、なんでもいい。”2023-08-21 09:00″ とか、ぶつからない命名規則を自分で決めておくのもよさそう。
• 復元時
  • stash pop を使うと消えてしまうので、apply で復元した方がよい。apply は消えないので。
  • hogeの名前では復元できないので、git stash list で探して復元する。以下の例では、 hogeは stash@{0}で復元できる $ git stash list stash@{0}: On branch_name: hoge git stash apply 'stash@{0}' (注) stash@{0}は、シングルクオートで囲うこと!。@や{} はシェルの変数を展開しようとするので。

※3 stash のコンフリクト

stash を復元するときに、コンフリクトが出るが、小さいコミットなので、コンフリクトも小さく対処はそんなに大変ではない。

まとめ

○○と△△の作業を見極めてから作業を始めるのは、なかなか面倒で手が止まりそうなので、 あとから別にまとめられそうな作業が見つかったら、いったん stash してサブブランチを作る方針がよさそうだ。 また、小さい修正で再修正の懸念がないものだったら、ブランチを分けなくてもコミットがまとまってるだけでよい場合もあると思う。

ちなみに、ビッグなコミットログを悲しいと思っているのは、あなただけではない！みんなが抱えている悩みだったりする。 かく言う私も、上記に紹介した解決策に気が付いたのは、けっこう最近なのだ。なんとなく、git 本には書いてあるような処方箋だけど。

いままで stash をあまり使ってこなかった人は、 stash して本当に保存されてるのか不安で躊躇すると思うのだけど、使ってるうちに慣れる！

コミットを小さく刻むと、1日1コミットが、当たり前に実現できるし、 そして、コミットすると気持ちがいいので、1日1回はコミットして、小さい達成感を味わいましょう。

The post 1日1コミットのススメ first appeared on 株式会社Altus-Five.

github の Issue チケットの番号は、コミットログや PR のコメントなどに含めると、コミット と Issue、PR が自動連係されて、 使い勝手がよくなるので、WBS で進捗管理する場合でも、Github のチケットは、うまく使いたいものです。

Issue の放置防止策

WBS と Issue を併用する場合、WBSを作成した段階で、同じ全タスクを一気にGithubのIssueにも登録してしまいがちですが、 それはやらずに、タスクに着手する担当者が Issue を1つ作成するようにするのがよいです。

そして、ブランチ運用ルールで、ブランチ名に Issue チケットの番号を含めるようにします。

PR にも Issue チケットの番号を記載することをルールにすると、Issue の放置は無くなります。

例えば、このような流れで仕事をします。

1. WBS のタスクに着手したときに、Issueチケットを作成する（IssueチケットにはWBSの番号を記入しておく）
   • 作成された issue チケット No が #123 だとする
2. ブランチ名に Issueチケットの No を入れて作成する
   • ブランチ名の例: feature/123/awesome-function
3. 開発する
4. コミットログには、Issueチケットの No を入れる
   • コミットログ例: feat: #123 awesome function added.
5. PR にも、Issueチケットの No を入れる
6. マージされる
7. Issue チケットをクローズする
8. WBS のタスクを終了にする

カンバンだと進捗が見えない

Scrum ならバーダウンチャートで進捗を確認することができますが、Scrum じゃないプロジェクトの場合に、チケット駆動で GitHub等で Issueチケットを使っている場合、1つ1つのタスクの完了は、見えるけど、進捗率が見えません。
それもあって、SI案件のほとんどでは、WBS で進捗を管理しているので、チケットとWBSの併用方法が必要でした。

The post WBS と GitHub (GitLab) の Issue の併用方法 first appeared on 株式会社Altus-Five.