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

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

ただいまの
回答率

88.09%

拡張 Git flow (Git Feature flow)でdevelopブランチへのmergeにmasterへのコミットログが出てくる

解決済

回答 1

投稿

  • 評価
  • クリップ 0
  • VIEW 368

score 17

前提・実現したいこと

featureブランチが独立している事が特徴と謳われている
拡張 Git flow (Git Feature flow) を試しています。

masterブランチからfeatureブランチを作成し、
featureブランチからdevelop,masterへとpull request~mergeを行うのですが、

その後、新たにfeatureブランチを作成し、developブランチにmergeを行おうとすると、
それ以前のmasterブランチへのコミットログが履歴に介入してきます。

これはこのブランチモデルの想定通りなのかどうか、ご教示いただきたく存じます。

発生している現象

feature(1~3)からdevelopとmasterにそれぞれPR,mergeを行います。(mergeコミットができあがる
![イメージ説明](1c02dd0f092bc56c93e5a0547687802c.png)

上述のPRが承認されたと仮定して、あらたにfeature(gap_1)ブランチを作成します。
イメージ説明

しかし、developにはmasterはのmergeコミットログがないので、
feature1だけではない・・・
master へのコミットログがgithub上で出てきます。

該当のソースコード

//まずはmaster からdevelop作成
git checkout -b develop

//feature 1 作成
git checkout master
git checkout -b feature1

//feature1でなんやかんや
touch file1.txt
git add .
git commit -m "add:1th"

//git hub で master と developにプルリク(このブランチモデルではdevelopからmasterにはmergeしないと。。。)

~~~~github上でPR 承認 etc

//master でpull
git checkout master
git pull

//新しいfeatureブランチ作成
git checkout -b next_sprint
touch next.txt
git add .
git commit -m "add:next feature"

//ここで、developの親コミットはmasterのmergeコミットを含んでいないので、
masterから新たに派生したブランチのコミットログが含まれてくる。
(開発者は自身の修正分しか認識がない状態)

感覚的な認識としては、masterブランチへのPRと同じく、developへも修正分のこみっとろぐしかのころ

試したこと

上述の通り

質問の本題

この状態は、拡張 Git flow (Git Feature flow)としては想定内のことなのでしょうか?
多人数での開発においては、各々のプログラマは自身の触ったソースコード以外の変更が現れてくるのは意図していない挙動なのかなという認識より質問させていいただいております。

なにか観点の見落としなどあればご指摘いただけますと幸いです。
お手数をおかけしますがよろしくお願い申し上げます。

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

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

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

    クリップを取り消します

  • 良い質問の評価を上げる

    以下のような質問は評価を上げましょう

    • 質問内容が明確
    • 自分も答えを知りたい
    • 質問者以外のユーザにも役立つ

    評価が高い質問は、TOPページの「注目」タブのフィードに表示されやすくなります。

    質問の評価を上げたことを取り消します

  • 評価を下げられる数の上限に達しました

    評価を下げることができません

    • 1日5回まで評価を下げられます
    • 1日に1ユーザに対して2回まで評価を下げられます

    質問の評価を下げる

    teratailでは下記のような質問を「具体的に困っていることがない質問」、「サイトポリシーに違反する質問」と定義し、推奨していません。

    • プログラミングに関係のない質問
    • やってほしいことだけを記載した丸投げの質問
    • 問題・課題が含まれていない質問
    • 意図的に内容が抹消された質問
    • 過去に投稿した質問と同じ内容の質問
    • 広告と受け取られるような投稿

    評価が下がると、TOPページの「アクティブ」「注目」タブのフィードに表示されにくくなります。

    質問の評価を下げたことを取り消します

    この機能は開放されていません

    評価を下げる条件を満たしてません

    評価を下げる理由を選択してください

    詳細な説明はこちら

    上記に当てはまらず、質問内容が明確になっていない質問には「情報の追加・修正依頼」機能からコメントをしてください。

    質問の評価を下げる機能の利用条件

    この機能を利用するためには、以下の事項を行う必要があります。

質問への追記・修正、ベストアンサー選択の依頼

  • hoshi-takanori

    2020/12/29 06:55

    拡張 Git flow の記事を読んでみましたが、記事中の「これらのブランチの役割自体は Git flow と変わりません。」という認識は間違ってる気がします (拡張 Git flow の release が本来の Git flow の develop に相当するはず)。というか、そもそも前提にしている開発モデルがまったく違います。本来の Git flow は (https://nvie.com/posts/a-successful-git-branching-model/ の先頭に追記されているように) Web ではなく数ヶ月〜数年周期でリリースするパッケージソフト的なものが想定されているのに対して、拡張 Git flow はそれこそ毎日リリースする Web の話ですよね。

    私の理解では、拡張 Git flow の記事の develop ブランチは、自動テストを各 feature ブランチごとではなく、すべての feature ブランチの変更内容をまとめて 1 回で済ませるための便宜的かつ write only なもの (feature-test みたいな名前にした方がいい気がします。) で、いろんな feature ブランチの途中経過が混ざっているため各 feature ブランチとの diff には意味がないし、マージもわざわざプルリクを作る必要がない (むしろ自動マージでもいいのでは) と感じました。(個人の感想です。)

    キャンセル

  • UnripeTomato

    2020/12/29 14:04

    拡張 Git flowの記事の確認までしていただきありがとうございます。
    おっしゃられているように、このブランチモデルはリリース頻度が高く、しかも各々の機能のリリース日が異なるようなものを楽にするためにでてきたモデルのようです。

    後半の私見について、diffをすべきはmasterとの比較であり、developブランチとのdiffには意味がないという見解についてもなるほど・・・と思いました。
    git運用モデル、色々あり難しいです。
    ありがとうございます。

    キャンセル

回答 1

checkベストアンサー

+1

git feature flowとしては想定通りのような気がします。

リリースしない、マージもしないブランチで自動テスト流してもあまり意味がないし、バグを検知したとしてもマージ済で原因の切り分けが大変なので、それは良いブランチ運用方法には見えません。

gitflow, github flow, trunk basedから特徴とpros/consを選んで上でどれかを選んだ方が良いような気がします。
参考: https://bliki-ja.github.io/PatternsForManagingSourceCodeBranches/

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2020/12/29 14:10

    ご回答ありがとうございます。
    回答の冒頭一番に、質問の本題に対する回答「git feature flowとしては想定通りのような気がします」を記載いただいていたこと、また他に参考記事のご提案をいただいたいたことでベストアンサーとさせていただきました。

    拡張Git flowはこれはこれで、開発機能単位でテストができるし、リリース単位も融通がきくのでメリットは確かにあるのかなと思っていますが、提示いただいたURLを熟読し、モデルの本質を正しく理解できるようになっていこうと思います。
    ありがとうございました。

    キャンセル

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

  • ただいまの回答率 88.09%
  • 質問をまとめることで、思考を整理して素早く解決
  • テンプレート機能で、簡単に質問をまとめられる

関連した質問

同じタグがついた質問を見る