リリース後に別チームへアプリ開発を引き継ぐときの Git 運用〜タグ使お〜

想定読者

• アプリをいったんリリースし、次の開発を別チームへ引き継ぐ人
• main、タグ、開発ブランチの使い分けを整理したい人
• リリース済みの状態を残しつつ、次期開発を安全に始めたい人

この記事で伝えたいこと

リリース後に別チームへ開発を引き継ぐ際、次の形にしておくと運用がかなり明確になったので共有。

• リリース済みの version1 は タグ で固定する
• 次期開発の version2 は 専用ブランチ で進める
• main はリリース済みの安定版として扱う

たとえば、以下のような構成です。

main
  A --- B --- C
              ^
              tag: v1.0.0
              \
               develop/v2  --- D --- E --- F

v1.0.0 はリリース済み状態を指す固定ラベルです。
develop/v2 はこれから進んでいく version2 開発用のブランチです。

背景

アプリの version1 をリリースした後、別チームが version2 の開発を担当することになりました。
どうすればいいかわからなくて。え、新しくリポジトリ作る・・・？いやブランチつくる・・・・？となりました・・・・

このとき何も整理せずに main で開発を続けてしまうと、次のような問題が起きやすくなります。

• version1 のリリース時点がどこだったかわかりにくくなる
• version2 の作業が main に混ざり、本番安定版との差分が追いにくくなる
• version1 に不具合が出たとき、どこから修正すべきか迷う
• 引き継ぎ先のチームが「どのブランチを使えばよいか」で迷う

そこで、リリース済み状態と次期開発の作業場所を Git 上で明確に分けます。

結論

今回のようなケースでは、以下の運用がわかりやすいです。

git switch main
git pull --ff-only

# version1 のリリース地点を固定
git tag -a v1.0.0 -m "Release v1.0.0"
git push origin v1.0.0

# version2 用の開発ブランチを作成
git switch -c develop/v2
git push -u origin develop/v2

引き継ぎ先のチームには、以下のように伝えます。

version2 の開発は develop/v2 ブランチを使用してください。

作業開始時:

git fetch origin
git switch develop/v2
git pull --ff-only

新しい機能開発や修正は develop/v2 から feature ブランチを切り、
完了後は develop/v2 宛に Pull Request を作成してください。

main はリリース済みの安定版として扱い、
version2 リリース時まで直接コミットやマージをしないでください。

タグとは何か

Git のタグは、特定のコミットに付ける「名前」です。

ブランチと違って、タグは通常あとから動かしません。

コミット履歴:

A --- B --- C
          ^
          v1.0.0

この例では、C というコミットに v1.0.0 という名前を付けています。

あとから開発が進んでも、v1.0.0 は C を指し続けます。

A --- B --- C --- D --- E
          ^
          v1.0.0

そのため、タグは「リリース時点のスナップショット」として使えます。

タグとブランチの違い

タグとブランチは似て見えますが、役割が違います。

種類	役割	動くか	主な用途
タグ	特定のコミットに名前を付ける	原則動かさない	リリース地点、節目、復旧基準
ブランチ	開発の流れに名前を付ける	コミットとともに進む	機能開発、統合、修正

ざっくり言うと、以下のように考えるとわかりやすいです。

タグ     = 保存点
ブランチ = 作業場所

version1 のような「リリース済みの状態」は、作業場所ではなく保存点です。
そのため、ブランチではなくタグで残すのが自然です。

一方で version2 はこれから開発が進むため、ブランチとして用意します。

なぜ version1 をブランチではなくタグで残すのか

「version1 用のブランチを作る」こともできます。

ただし、単にリリース時点を残したいだけなら、ブランチよりタグの方が向いています。

理由は、ブランチは「動くもの」だからです。

たとえば version1 というブランチを作ると、誰かがそこにコミットしたり、誤ってマージしたりする余地があります。

version1 ブランチを作った場合:

A --- B --- C
          \
           version1

# 後から何かが入る可能性がある

もちろん、保守用に version1 系の修正を続けるなら release/v1 や maintenance/v1 のようなブランチを作る選択もあります。

しかし、今回のように「リリース済みの状態を固定しておきたい」という目的なら、タグで十分です。

v1.0.0 タグ:

A --- B --- C
          ^
          v1.0.0

# 原則として動かさない

version2 用のブランチを作る理由

version2 は、これから新しいコミットが積み上がっていく開発ラインです。

そのため、タグではなくブランチが必要です。

main
  A --- B --- C
              ^
              v1.0.0
              \
               develop/v2 --- D --- E

この形にしておくと、次のルールが明確になります。

• version1 のリリース地点は v1.0.0
• version2 の開発先は develop/v2
• feature ブランチは develop/v2 から切る
• Pull Request の向き先は develop/v2
• main は次の正式リリースまで安定版として維持する

引き継ぎ時に伝えるべきこと

他の開発チームへ引き継ぐときは、Git の状態だけ作って終わりにしない方がよいです。

最低限、以下を明文化して渡すと迷いが減ります。

1. リリース済み version

version1 のリリース地点は v1.0.0 タグです。

確認コマンド:

git fetch origin --tags
git show v1.0.0

2. 開発に使うブランチ

version2 の開発は develop/v2 を使用してください。

作業開始:

git fetch origin
git switch develop/v2
git pull --ff-only

3. feature ブランチの切り方

git switch develop/v2
git pull --ff-only
git switch -c feature/example-feature

作業が終わったら、Pull Request は develop/v2 に向けます。

feature/example-feature -> develop/v2

4. main の扱い

main はリリース済みの安定版として扱います。
version2 の正式リリースまでは、main に直接コミット・マージしません。

可能であれば、GitHub などで main に branch protection を設定しておくと安全です。

version2 をリリースするとき

version2 の開発が完了したら、develop/v2 を main にマージし、次のリリースタグを作ります。

git switch main
git pull --ff-only
git merge --no-ff develop/v2

git tag -a v2.0.0 -m "Release v2.0.0"

git push origin main
git push origin v2.0.0

これで、version2 のリリース地点もタグとして残ります。

main
  A --- B --- C -------- M
              ^          ^
              v1.0.0     v2.0.0
              \        /
               D --- E
              develop/v2

version1 に緊急修正が必要になったら

version2 の開発中に version1 の障害対応が必要になることもあります。

その場合は、v1.0.0 タグから hotfix ブランチを切ります。

git fetch origin --tags
git switch -c hotfix/v1.0.1 v1.0.0

修正後、必要に応じて v1.0.1 としてタグを付けます。

git tag -a v1.0.1 -m "Release v1.0.1"
git push origin v1.0.1

その修正が version2 側にも必要なら、develop/v2 に cherry-pick するか、適切にマージします。

git switch develop/v2
git cherry-pick <hotfix_commit_hash>

避けたい運用

main でそのまま version2 開発を始める

一番シンプルに見えますが、リリース済み安定版と開発中の変更が混ざります。

main = 本番安定版 + 次期開発中

この状態になると、障害対応や差分確認が難しくなります。

version1 をブランチだけで残す

保守する予定があるならよいですが、リリース地点を残したいだけならタグの方が明確です。

リリース地点を残す -> タグ
継続的に修正する -> ブランチ

タグを後から付け替える

一度共有したリリースタグを付け替えると、他の人の認識と手元の状態がずれる可能性があります。

タグは原則として不変のリリース地点として扱うのが安全です。

まとめ

リリース後に別チームへ開発を引き継ぐときは、Git 上で「固定するもの」と「動かすもの」を分けると運用しやすくなります。

• リリース済み version はタグで固定する
• 次期開発は専用ブランチで進める
• feature ブランチは次期開発ブランチから切る
• Pull Request の向き先を明確にする
• main は次の正式リリースまで安定版として扱う

今回の例では、以下の形です。

version1 の固定点: v1.0.0
version2 の開発先: develop/v2
安定版ブランチ: main

この状態まで作ってから引き継ぐと、次のチームは「どこから作業を始めるべきか」で迷わずに済みます。

タグ・・・・使ってみようぜ！⭐️
ではでは