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

Transcript

1. 社内のGitの運用ルールを作った話
2. カルキチ副島 フロントエンドエンジニア@ショーケース Twitter: @karukichi_yah GitHub: https://github.com/Yota-K 経歴 2020年4月にエンジニアになったので、エンジニアとしての実務経験は2年目で す。 1社目ではWordPressを使ったサイト構築と社内ツール（PHP・Laravel）の開発に 携わっていました。 2020年5月からショーケースにジョインして、現在は自社SaaSアプリのフロントエ ンド開発（主にTypeScript・React）及び、技術選定に携わっています。 プロフィール
3. Gitの運用ルールを作った理由
4. リリース時の手順が定められていなかったから 自分が入社した時点でリリース時の手順が定められておらず、プロジェクトごとに バラバラでした。 リリース手順が定められていないと、以下のような問題が発生します。 • 新しく入ってきた人にリリース作業を教えるのが大変！ • 別のプロジェクトからジョインしてきた人が混乱してしまう • 結果として、リリース作業の属人化に繋がってしまう 💡 リリースの手順が定められていないと、新卒で入ってきたエンジニア や経験の浅いエンジニアに研修等でリリース作業について教えることが 難しくなるため、人材採用にも影響すると考えました。
5. Gitグラフが煩雑でコミットログが追いづらかったから プルリクエストをマージする方法（Create a merge commit・Squash and merge など）に関しても特に定められていなかったので、コミットログが追いづらいとい う問題が発生していました。 コミットログが煩雑だと、コミットログから過去の実装が追いづらくなって、プロ ジェクトの概要を掴むのが大変です...😢
6. 課題解決のために導入したGitの運用ルール
7. 導入したルール 1. ブランチの運用方法に関するルール 2. プルリクエストのマージ戦略に関するルール 3. リリース手順に関するルール
8. ブランチの運用方法に関するルール
9. ブランチの運用方法に関するルール リリース作業をスムーズに行うためには、ブランチの運用ルールを定める必要があ ると考えたので、ブランチの運用ルールを作りました。 ブランチの命名規則や必要なブランチ、マージする際の手順等が明確になっていれ ば、開発やリリース作業を行う時に余計なことを考える必要がなくなります。
10. ブランチの運用ルールとしてgit-flowを導入 ブランチの運用ルールにはGitのブランチモデルの一つであるgit-flowを採用しま した。 ブランチの運用ルールを決めることで、複数人で開発を行う時に好き勝手にブラン チを作成を防止し、混乱を防ぐことに繋がります。 💡git-flow以外の著名なブランチモデルとしては、GitHub-flowや GitLab-flowなどがあります。
11. 図にするとこんな感じです
13. 開発をするとき mainから切ったdevelopブランチから featureブランチを切って開発を行い、 developブランチにマージする。
14. リリースを行う時 developブランチから releaseブランチを切って README.mdやCHANGELOG.mdを編集して、 mainブランチとdevelopブランチにマージする。 マージ後にmainブランチでタグ付けを行う。
15. 緊急の不具合対応を行う時 mainブランチから hotfixブランチを切って、不具合 対応を行なって、 mainブランチとdevelopブランチ にマージする。 マージ後にmainブランチでタグ付けを行う。
16. git-flowでのブランチの役割 main（master）: プロダクトしてリリースできる状態のブランチ。 リリース時のタグ付けを行う以外、このブランチで作業を行ってはいけません。 develop: 開発用のブランチ。 レビュー済みの内容のみが取り込まれた状態のブランチです。 releaseブランチを切る以外、このブランチで作業を行ってはいけません。 feature: 開発を行うためのブランチ。 developから分岐してレビューが完了したら、developにマージします。 release: リリース時に使用するブランチ。 developから分岐して、リリース準備（バージョンやREADMEの更新等）が完了したら、 developとmainにマージします。（マージ完了後はすぐに削除します。） hotfix: リリース後にクリティカルなバグが発生した際に使用するブランチ。 mainから分岐して、バグの対応が完了したらmainとdevelopにマージします。（マージ完了後 はすぐに削除します。）
17. git-flowにはCLIツールもあります git-fllowでのブランチ運用をサポートするCLIツールを使用すれば、誰が作業して もgit-flowのルールに則ってブランチをチェックアウトしてくれます。 git-flow initで初期設定を行った状態で、 git-flow release start v1.0.0を実行すると release/v1.0.0というブランチを自動で チェックアウトしてくれます！
18. プルリクエストのマージ戦略に関するルール
19. マージ戦略とは？
20. マージをする際の手段のことです。 「Create a merge commit」、「Squash and merge」、「Rebase and merge」の 3種類が存在します。 マージコミットの有無や、元のコミットログや マージ元のブランチとの関係を残すか残さな いかが異なります。 マージ戦略とは？
21. プルリクエストのマージ戦略に関するルール コミットログが追いづらいという問題を解決するために、マージ戦略に関するルー ルを作ることにしました。 開発を行う際にfeatureブランチをdevelopにマージする際は、「Squash and merge」でマージを行う決まりを作りました。 featureブランチのコミットログをdevelop・mainブランチに取り込んでしまうと、 作業過程のコミットも全て残ってしまうので、コミットログが見づらくなる原因に なります！
22. Squash and mergeとは？ Gitのマージ戦略の1つで、複数のコミットを1つにまとめたマージコミットが作成 される。 コミットが多くなる傾向にあるfeatureブランチでの作業内容を1つのコミットにま とめて、developブランチにマージすることができるので、Gitのログをきれいに保 つことに繋がる。
23. Create a merge commit • マージコミット・・・作成される • 元のブランチのコミットログ・・・残る • 元のブランチとの関係・・・残る Squash and merge • マージコミット・・・作成される • 元のブランチのコミットログ・・・残らない • 元のブランチとの関係・・・残らない Create a merge commitとの違い
24. リリース手順に関するルール
25. リリース手順に関するルール git-flowのルールに則ってリリースを行うルールを作りました。 releaseブランチからdevelop・mainブランチにマージを行う際のマージ戦略は 「Create a merge commit」を使用しています。
26. Gitの運用ルールを導入するためにやったこと
27. 運用ルールを導入するまでにやったこと 1. スライド資料の作成 スライド資料と合わせて、ハンズオン用のgitリポジトリの作成も行いまし た。 2. 作った資料を元に社内のエンジニアとルールのすり合わせを実施 3. ハンズオンの実施 リモートで作業を行っているメンバーがほとんどのため、Googleミートでハ ンズオンを行いました。
28. Gitの運用ルールを決めて良かったこと
29. • 普段の開発やリリース作業を行う際にブランチの切り方やリリースの手順に関 して迷うことがなくなった • 自分が携わっていないプロジェクトでも、Gitのログがきれいになっているも のが増えた • Gitの理解が以前より深まった Gitの運用ルールを決めて良かったこと
30. 今後の課題
31. • ルール自体のブラッシュアップ • 今回作成したルールの普及率をあげていく • レクチャーの内容を理解しきれていない人がいる（個人・個人のスキルに差が あるのが原因。今後は個人・個人のスキル差をなくしていくことが必要） 今後解決する必要がある課題
32. ご静聴ありがとうございました