Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

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

Soejima Karukichi

June 08, 2022
Tweet

More Decks by Soejima Karukichi

Other Decks in Technology

Transcript

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  18. マージ戦略とは?

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  29. 今後の課題

    View full-size slide

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

    View full-size slide

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

    View full-size slide