19
7

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

アイレット株式会社Advent Calendar 2024

Day 17

GitFlowについて今一度考える

Last updated at Posted at 2024-12-31

年末最後に記事の投稿です。
毎回プロジェクトを立ち上げる際に考えるgitリポジトリの運用について。
プロジェクトの要件によって臨機応変に変えたいと思っているのですが、
なかなかうまくいかず...
いつも悩みの種となります。

今年も大きなプロジェクトを一つ立ち上げました。
そのgitリポジトリの運用についてまとめてみました。
来年、実際に稼働していってどう変わっていくかわかりませんが備忘録に残していきたいと思います!

前提

開発するものは下記になります。

  • Webアプリ
  • API

今回のプロジェクトは開発が下記の2チームに分かれています。

  • フロントデザイン反映チーム(略称:デザインチーム):Storybookを用いて画面のデザインのみ反映するチーム
  • フロントエンドロジック&バックエンド実装チーム(略称:開発チーム):React&APIを実装して、画面に動きをつけていく&機能を追加していくチーム

今回のプロジェクトの性質上、開発中にデザイン変更がどんどん入っていくというところがあり、
デザインと開発を分けて並行に作業が進められるようにしていきたい
という意図からこのプロジェクト構成が生まれました。

また、1週スプリントでスクラムを進めるということで、
毎週、PO・ステークホルダーが開発した機能を確認して、細かい仕様修正・改善を決めていくことになります。
なので、必要な環境としては

  • 開発環境(dev)
  • PO・ステークホルダーが確認する検証環境(stg)
  • 実際に運用していく本番環境(prod)

3環境が必要となります。

そして、1つ大きな課題としては

  • リリースしたい機能を選んで本番環境にあげたい

ということです。
上記を踏まえて、git運用を考えていきました。

基本のGitFlowを確認

よく記事にあるGitFlowを参考にしてみます。
image.png
ここで問題となるのは、

  • 複数チームの並行開発はどうする?
  • 機能を選んでリリースをしたい場合どうする?
    になりました。

このGit-Flowをもとに、今回のプロジェクト構成に合わせた運用に変えて考えてみます。

プロジェクトに適用したgit運用①

image.png

  • featureブランチ(図のオレンジ色、紫色のブランチ):

    • デザインチームがdevブランチからブランチを切り、仮デザインを反映
    • デザイン反映されたブランチから、開発チームがブランチを切り、ロジックを反映
    • 開発チームがロジック実装中に、デザインチームが仮デザインから本デザインを反映
    • 開発チームの成果とデザインチームの成果をまとめてdevelopブランチに反映
      → この際に squshマージを実施する!
       ※1機能分の成果物を1コミットにまとめるため
  • developブランチ:

    • 開発した機能をここにまとめる
    • 開発環境とする
    • mainからブランチを切ります
  • releaseブランチ:

    • mainブランチから切る
    • developブランチのcommit履歴からリリースするべきcommitをcherry-pick
      ※ ただし、この運用だと、どのcommitをリリースしたか、表にまとめておく必要がある
    • ブランチ名にリリース番号をつける
    • ここを検証環境とする
    • ここでテストを行い、アプリ動作に問題がなければmainにマージをする
  • hotfixブランチ:

    • Issue番号をhotfixブランチ名とする
    • releaseブランチ・mainブランチにて修正が発生したら、それぞれのブランチからhotfixブランチを切ります
    • 修正したものは、最新のreleaseブランチにマージをして動作を確認します
  • mainブランチ:

    • relaseブランチで動作が問題なければこちらのブランチにマージをします
    • こちらにマージをした時点で、developブランチを、mainブランチの最新へrebaseします

プロジェクトに適用したgit運用②

開発を進める上で課題が出てきました。
デザインチームも開発チームも人数が1人以上いるため、
1機能を全員で開発するより、複数機能を並行で開発したほうがいいということになりました。
①の運用だと、1機能ができるまでdevelopにマージされないため、待ちが発生してしまいます。
そこで、featureブランチの運用方法を変えました。
各担当者がdevelopブランチからブランチを切り、
開発・デザイン反映をしてdevelopブランチにマージをしていく従来の方法です。
image.png

今後の懸念点&課題

  • developからリリースするものをピックアップする際に、もれなく機能ごとにピックアップできるのか
  • mainブランチにリリース成果物をマージした際に、developブランチのrebaseがうまくいくのか

まとめ

まだリリースをしていなので、来年どのようにこのgit運用の方法が変わっていくかわかりませんが、
今のところこのような形で動かす想定をしています。
commit履歴に沿ってリリースできればいいのですが、なかなか開発側にビジネス側が合わせることってできませんよね...
まだ課題もあるので、
両者が円滑に作業を進められるように、慎重に試していきたいと思いました。

駆け足で備忘録失礼しました...!
もし、ベストプラクティス等あれば共有いただけると幸いです!

もう今年もあと少しですね。
みなさん良いお年をお過ごしください!:hand_splayed:

19
7
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
19
7

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?