質問をすることでしか得られない、回答やアドバイスがある。

15分調べてもわからないことは、質問しよう!

新規登録して質問してみよう
ただいま回答率
85.48%
Git

Gitはオープンソースの分散バージョン管理システム(DVCS)です。

git-flow

git-flowとは、gitのブランチモデルを使う時の補助ツールです。gitを使う際のブランチ作成などで、一定のルールをまとめたものを指します。

Q&A

解決済

1回答

1675閲覧

git-flowのmasterブランチの存在意義

yuba

総合スコア5568

Git

Gitはオープンソースの分散バージョン管理システム(DVCS)です。

git-flow

git-flowとは、gitのブランチモデルを使う時の補助ツールです。gitを使う際のブランチ作成などで、一定のルールをまとめたものを指します。

1グッド

1クリップ

投稿2019/12/25 05:05

git-flowのmasterブランチにあたるものはリリースタグで十分ではないかという仮説を持っています

  • リリースする際は、developからリリースブランチを生やし、そこでQAや修正コミット追加をしてOKとなったらリリースタグを打つ。

リリースタグをの付いたコミットが本番リリースなりパッケージ公開なりされる

  • リリースタグを打った時点でリリースブランチはdevelopへ戻しマージする
  • リリース済みバージョンの緊急修正が必要になった場合は最新のリリースタグからhotfixブランチを生やしてそこで修正やQAを行い、OKとなったらリリースタグを打つ。同じくdevelopへ戻しマージする

これでgit-flowでやりたかったことは十分できているのではないかと。

あえてmasterブランチを持つ理由があるとしたら

  • 最新のリリースがどれだかわかりやすいようにするマーカー
  • リリースブランチやhotfixブランチをWebツール上でマージリクエストの形にできるのでQA工程が可視化できる

というのも考えられますが、前者は「タグリストの一番大きい数字を見ろ」で十分に感じますし、後者もdevelopへのマージリクエストにできるのでとなります。

むしろmasterという直接コミットしてはいけない先がコミット可能ポインタであるブランチであるよりはコミット不能ポインタであるタグである方が用途と機能があっているのではと思っておりの質問です。

どう考えるのが良いでしょうか。

yumetodo👍を押しています

気になる質問をクリップする

クリップした質問は、後からいつでもMYページで確認できます。

またクリップした質問に回答があった際、通知やメールを受け取ることができます。

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

guest

回答1

0

ベストアンサー

こんにちは。

その方式の場合、リリース済のブランチ(master)へhotfixを当てられないのでは?

git-floaは「仕様Fix→リリース・ブランチでテスト」にそれなりの長期間がかかるようなプロジェクトにおいて開発を止めない仕組みと理解しています。そのためリリース・ブランチの寿命が長いのでその間にセキュリティ・ホールが見つかったらホットフィックスすることが望ましいです。リリース・ブランチは信頼性検証中のブランチなのでそこにホットフィックスを当ててもリリースには時間がかかるので意味がないです。
結果、リリース済のmasterブランチへホットフィックスする必要があるので、masterブランチは必要と思います。

投稿2019/12/25 05:38

Chironian

総合スコア23272

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

yuba

2019/12/26 07:31

もう少し掘り下げさせてください。 hotfixが必要になった場合、 1. リリースタグからhotfixブランチを生やす 2. hotfixブランチ上で修正・QA 3. QA完了したらhotfixブランチの先頭に新たなリリースタグを打ち、developへマージ これでリリースブランチを絡めずにhotfixできるかと思いましたが、これだとどのあたりが足りないでしょうか。
Chironian

2019/12/26 08:46

gitで使用するフローは各プロジェクト毎に使いやすい方法で行えばよいですので、yubaさんのプロジェクト・メンバーがそれを使いやすいと思うのでしたら、それで良いと思います。 ただ幹がなくて特別な葉っぱ(リリースタグ)で来歴管理というやり方は、あまり見かけないのでついてこれなくなる人がそれなりに増えそうな予感はします。単にmasterブランチにマージしているか居ないかだけの差しかないので本質的には大差ないとは思いますが。
tamoto

2019/12/26 08:55

横から補足ですみませんが、hotfix が常に一本のみ存在するとは限らないはずなので、hotfix の統合先が必要になり、それが master になるのだと思っています。
yuba

2019/12/27 04:10

>Chironianさん 本質的には大差ないとの見解、ありがとうございます。 >tomotoさん hotfixブランチを複数立てることは有り得ると思いますが、それをmasterに「統合する」とはどういうフローを指しているでしょうか。 1. 問題Aと問題Bが発覚する 2. hotfix/A と hotfix/B ブランチが立ち上がり別個に修正作業 3. hotfix/A と hotfix/B をmasterにマージし、masterをQA、OKならリリース みたいな流れを意図なさっていますか?
tamoto

2019/12/27 04:23

master はリリース済みブランチを表す場合であれば、hotfix/A と B を個別に QA し、それぞれが master へマージしつつリリースとなるのではないかと思います。 タグ運用で困るのは、hotfix ブランチのマージ先が「不定」になることだと思います。例えば hotfix/B をマージ (タグ打ち) する1秒前に hotfix/A をマージ完了したとすると、リリースがフォークしてしまうことになります。 リリースタグの繋がりを「線形に保てる」ことが master ブランチの存在意義だと言えると思います。
guest

あなたの回答

tips

太字

斜体

打ち消し線

見出し

引用テキストの挿入

コードの挿入

リンクの挿入

リストの挿入

番号リストの挿入

表の挿入

水平線の挿入

プレビュー

15分調べてもわからないことは
teratailで質問しよう!

ただいまの回答率
85.48%

質問をまとめることで
思考を整理して素早く解決

テンプレート機能で
簡単に質問をまとめる

質問する

関連した質問