社内のGitの運用ルールを作った時の話

Transcript

1. 社内のGitの運用ルールを作った話
   

   View Slide

2. カルキチ副島
   フロントエンドエンジニア@ショーケース
   Twitter: @karukichi_yah
   GitHub: https://github.com/Yota-K
   経歴
   2020年4月にエンジニアになったので、エンジニアとしての実務経験は2年目で
   す。
   1社目ではWordPressを使ったサイト構築と社内ツール（PHP・Laravel）の開発に
   携わっていました。
   2020年5月からショーケースにジョインして、現在は自社SaaSアプリのフロントエ
   ンド開発（主にTypeScript・React）及び、技術選定に携わっています。
   プロフィール
   

   View Slide

3. Gitの運用ルールを作った理由
   

   View Slide

4. リリース時の手順が定められていなかったから
   自分が入社した時点でリリース時の手順が定められておらず、プロジェクトごとに
   バラバラでした。
   リリース手順が定められていないと、以下のような問題が発生します。
   ● 新しく入ってきた人にリリース作業を教えるのが大変！
   ● 別のプロジェクトからジョインしてきた人が混乱してしまう
   ● 結果として、リリース作業の属人化に繋がってしまう
   💡 リリースの手順が定められていないと、新卒で入ってきたエンジニア
   や経験の浅いエンジニアに研修等でリリース作業について教えることが
   難しくなるため、人材採用にも影響すると考えました。
   

   View Slide

5. Gitグラフが煩雑でコミットログが追いづらかったから
   プルリクエストをマージする方法（Create a merge commit・Squash and merge
   など）に関しても特に定められていなかったので、コミットログが追いづらいとい
   う問題が発生していました。
   コミットログが煩雑だと、コミットログから過去の実装が追いづらくなって、プロ
   ジェクトの概要を掴むのが大変です...😢
   

   View Slide

6. 課題解決のために導入したGitの運用ルール
   

   View Slide

7. 導入したルール
   1. ブランチの運用方法に関するルール
   2. プルリクエストのマージ戦略に関するルール
   3. リリース手順に関するルール
   

   View Slide

8. ブランチの運用方法に関するルール
   

   View Slide

9. ブランチの運用方法に関するルール
   リリース作業をスムーズに行うためには、ブランチの運用ルールを定める必要があ
   ると考えたので、ブランチの運用ルールを作りました。
   ブランチの命名規則や必要なブランチ、マージする際の手順等が明確になっていれ
   ば、開発やリリース作業を行う時に余計なことを考える必要がなくなります。
   

   View Slide

10. ブランチの運用ルールとしてgit-flowを導入
    ブランチの運用ルールにはGitのブランチモデルの一つであるgit-flowを採用しま
    した。
    ブランチの運用ルールを決めることで、複数人で開発を行う時に好き勝手にブラン
    チを作成を防止し、混乱を防ぐことに繋がります。
    💡git-flow以外の著名なブランチモデルとしては、GitHub-flowや
    GitLab-flowなどがあります。
    

    View Slide

11. 図にするとこんな感じです
    

    View Slide

12. View Slide

13. 開発をするとき
    mainから切ったdevelopブランチから
    featureブランチを切って開発を行い、
    developブランチにマージする。
    

    View Slide

14. リリースを行う時
    developブランチから releaseブランチを切って
    README.mdやCHANGELOG.mdを編集して、
    mainブランチとdevelopブランチにマージする。
    マージ後にmainブランチでタグ付けを行う。
    

    View Slide

15. 緊急の不具合対応を行う時
    mainブランチから hotfixブランチを切って、不具合
    対応を行なって、 mainブランチとdevelopブランチ
    にマージする。
    マージ後にmainブランチでタグ付けを行う。
    

    View Slide

16. git-flowでのブランチの役割
    main（master）: プロダクトしてリリースできる状態のブランチ。
    リリース時のタグ付けを行う以外、このブランチで作業を行ってはいけません。
    develop: 開発用のブランチ。
    レビュー済みの内容のみが取り込まれた状態のブランチです。
    releaseブランチを切る以外、このブランチで作業を行ってはいけません。
    feature: 開発を行うためのブランチ。
    developから分岐してレビューが完了したら、developにマージします。
    release: リリース時に使用するブランチ。
    developから分岐して、リリース準備（バージョンやREADMEの更新等）が完了したら、
    developとmainにマージします。（マージ完了後はすぐに削除します。）
    hotfix: リリース後にクリティカルなバグが発生した際に使用するブランチ。
    mainから分岐して、バグの対応が完了したらmainとdevelopにマージします。（マージ完了後
    はすぐに削除します。）
    

    View Slide

17. git-flowにはCLIツールもあります
    git-fllowでのブランチ運用をサポートするCLIツールを使用すれば、誰が作業して
    もgit-flowのルールに則ってブランチをチェックアウトしてくれます。
    git-flow initで初期設定を行った状態で、
    git-flow release start v1.0.0を実行すると
    release/v1.0.0というブランチを自動で
    チェックアウトしてくれます！
    

    View Slide

18. プルリクエストのマージ戦略に関するルール
    

    View Slide

19. マージ戦略とは？
    

    View Slide

20. マージをする際の手段のことです。
    「Create a merge commit」、「Squash and
    merge」、「Rebase and merge」の
    3種類が存在します。
    マージコミットの有無や、元のコミットログや
    マージ元のブランチとの関係を残すか残さな
    いかが異なります。
    マージ戦略とは？
    

    View Slide

21. プルリクエストのマージ戦略に関するルール
    コミットログが追いづらいという問題を解決するために、マージ戦略に関するルー
    ルを作ることにしました。
    開発を行う際にfeatureブランチをdevelopにマージする際は、「Squash and
    merge」でマージを行う決まりを作りました。
    featureブランチのコミットログをdevelop・mainブランチに取り込んでしまうと、
    作業過程のコミットも全て残ってしまうので、コミットログが見づらくなる原因に
    なります！
    

    View Slide

22. Squash and mergeとは？
    Gitのマージ戦略の1つで、複数のコミットを1つにまとめたマージコミットが作成
    される。
    コミットが多くなる傾向にあるfeatureブランチでの作業内容を1つのコミットにま
    とめて、developブランチにマージすることができるので、Gitのログをきれいに保
    つことに繋がる。
    

    View Slide

23. Create a merge commit
    ● マージコミット・・・作成される
    ● 元のブランチのコミットログ・・・残る
    ● 元のブランチとの関係・・・残る
    Squash and merge
    ● マージコミット・・・作成される
    ● 元のブランチのコミットログ・・・残らない
    ● 元のブランチとの関係・・・残らない
    Create a merge commitとの違い
    

    View Slide

24. リリース手順に関するルール
    

    View Slide

25. リリース手順に関するルール
    git-flowのルールに則ってリリースを行うルールを作りました。
    releaseブランチからdevelop・mainブランチにマージを行う際のマージ戦略は
    「Create a merge commit」を使用しています。
    

    View Slide

26. Gitの運用ルールを導入するためにやったこと
    

    View Slide

27. 運用ルールを導入するまでにやったこと
    1. スライド資料の作成
    スライド資料と合わせて、ハンズオン用のgitリポジトリの作成も行いまし
    た。
    2. 作った資料を元に社内のエンジニアとルールのすり合わせを実施
    3. ハンズオンの実施
    リモートで作業を行っているメンバーがほとんどのため、Googleミートでハ
    ンズオンを行いました。
    

    View Slide

28. Gitの運用ルールを決めて良かったこと
    

    View Slide

29. ● 普段の開発やリリース作業を行う際にブランチの切り方やリリースの手順に関
    して迷うことがなくなった
    ● 自分が携わっていないプロジェクトでも、Gitのログがきれいになっているも
    のが増えた
    ● Gitの理解が以前より深まった
    Gitの運用ルールを決めて良かったこと
    

    View Slide

30. 今後の課題
    

    View Slide

31. ● ルール自体のブラッシュアップ
    ● 今回作成したルールの普及率をあげていく
    ● レクチャーの内容を理解しきれていない人がいる（個人・個人のスキルに差が
    あるのが原因。今後は個人・個人のスキル差をなくしていくことが必要）
    今後解決する必要がある課題
    

    View Slide

32. ご静聴ありがとうございました
    

    View Slide