

githubにて以下のようなブランチ構成で作業をしています。

  * mainブランチ：実際のサーバーにデプロイする状態のコードを反映
  * developブランチ：作業内容を反映してテストするブランチ
  * featureブランチ：作業を行うブランチ

コードの修正時は、featureブランチで作業をしてdevelopへマージし、テストを行なって問題なければmainへマージする流れです。  
developからmainへマージすると、mainに以下のようなマージコミットが追加されると思います。

[code]

    Merge pull request #1 from hoge/develop
    
[/code]

この状態でdevelopブランチをgithub上で確認すると、`This branch is 1 commit behind main.`
となっています。当然、マージコミット分遅れているのはわかるのですが、これだとdevelopブランチを作り替えない限り、マージするごとにどんどん遅れていくことになるかなと思いました。逆に上記の状態でmain→developのマージをしても今度はdevelopが先行してしまいます。

質問としては

  1. 一般的には、このような問題は起きないのでしょうか？
  2. ブランチモデル的にも珍しい使い方だとは思っていないのですが、マージし終わったブランチは都度削除する運用が一般的なのでしょうか？（今回のdevelopブランチのような商用リリース前のstagingのような使い方をするブランチ）
  3. この問題を解決する良い方法は何かありますか？


CC BY-SA 4.0
2023-03-18T04:18:35.800
94231
2023-05-24T01:06:25.250
2023-05-20T07:58:12.073
3060
57574
question
git github
githubでdevelopブランチをmainブランチへマージした際の状態について


[A successful Git branching model](https://nvie.com/posts/a-successful-git-
branching-model/)(俗に言う git-flow)のreleaseブランチが省略された運用になっているのかと思われますが。

> 一般的には、このような問題は起きないのでしょうか？

リンク先の図の通り、普通の状態です。  
つまりそもそも問題とは捉えられていません。

>
> ブランチモデル的にも珍しい使い方だとは思っていないのですが、マージし終わったブランチは都度削除する運用が一般的なのでしょうか？（今回のdevelopブランチのような商用リリース前のstagingのような使い方をするブランチ）

A successful Git branching model やここから派生した運用フローでは master(main), develop
ブランチは削除しません。  
つまり一般的ではないです。

> この問題を解決する良い方法は何かありますか？

develop を main に merge した直後に、 develop を main に rebase すれば良いのでは。

* * *

> 今はコードの差分もあるのか？マージコミットの差分だけなのか？をコミット履歴を参照しないといけないので。

main ブランチは develop からのマージコミットだけになる(ように運用する)ので、それ以外の可能性を考える必要はありません。  
(逆に言うと、それ以外の可能性を考える必要が出ているのなら、運用方法が間違っているということになります)

あと質問内容とは直接関係ないですが、質問者のような運用では default branch は develop に設定するのが妥当ではないかと考えます。  
(現状は main が default branch になっているかと思います)


CC BY-SA 4.0
2023-05-24T01:06:25.250
94953
2023-05-24T01:06:25.250
2808
94231
answer