きっかけ

git運用でコミットがゴチャゴチャしていたり、メンテナンスするのが複雑になっているものを見かけたので、参考になればと思って記事書くことにしました。

余談

SourceTreeやIDEに入っているGUIツールを使っている人がいると思うが、以前使った時にアプリが重かったり、コンフリクトした時に解消がめんどくさかったりした時があったので、個人的にはCUI推奨として、記事ではコマンドベースでの説明になります

コマンドリスト

今回使用するコマンドリスト↓

  • rebase ⭐️今回のコアとなるところ
  • merge
  • log
  • checkout
  • branch
  • fetch
  • pull
  • etc..

コマンドの動きは今回伝えたいことに入らないので、git初心者の方はサルでも分かるGit入門を見てから次項を読んでみて下さい

伝えたいこと

No branch 説明
1 mater 本番リリース用ブランチ
2 develop masterから作成したブランチ
3 work/~ developから作成したworkブランチ

上記ブランチ構成を前提とした資源管理方法を記載

  • workブランチへdevelopブランチをmergeではなく、workブランチでdevelopブランチをrebaseする
    • rebaseをすることでコミット単位で比較し、developブランチのコミットIDの順番を踏襲する形で取り込むため、developとの差分は自分の作業分だけとなる
  • developブランチからmasterブランチへmergeする（本番リリース）時はsquash mergeにする
    • squash mergeをすることでリリース単位でコミットIDがまとめられ、リリース単位でコミットをまとめることができる
    • squash merge後は紐づくブランチを再作成してもらうのも忘れずに実施

サンプル

※逆にworkブランチへdevelopブランチをmergeした場合はどうなるか？

  • workブランチへdevelopブランチをmergeするとworkブランチを作成してからmergeするまでの間にdevelopに取り込まれた資源がdevelopとは異なるコミットIDで自身の作業コミットの上に作成される
    • その結果、同じ資源なのにdevelopブランチとworkブランチでコミットIDが異なることで、プルリクエストの差分として、自分が変更していないものまで変更資源扱いとされてしまう

→複数メンバーで資源更新する場合程、資源管理は厳格にしないと「今の資源って何が入ってるんだ？」「revertしようと思ってもどこまで戻せばいいのかわからない。。」って自体がより起きやすいので、mergeはNGってことがわかってもらえたと思う。

まとめ

git資源管理にこれが正解と言ったものはないので、個人的に運用しやすかった例程度で記載したので、やりやすいかは置いといて、この記事を読んだ方が「こういう方法あるんだ！」って思ってもらえたらいいかなーって思ってます。　　　　　　　　　　　　　　今後もこういうナレッジがあったら記事化していこうと思うので、気が向いたら覗いてもらえるとありがたいです　　　　　　　　　　では、またどこかで〜