質問：結合試験時のgitブランチの運用方法

Question

はじめに

現場でgitを使用してソースをしていますが、ブランチの管理に関してご意見を伺えればと思います。
※皆様の作業場でやっている運用方法を知りたい（今後私の開発現場での改善もしていきたい）という思いです。

概要

ご意見を伺いたい概要は、下記になります。
0. 結合試験を行う際のブランチ
0. 結合試験で検出された不具合のコミット先
0. 不具合のコミットログ（release→developマージ時）

基本的には以下のようなブランチ構成で作業しています。一般的なブランチ運用（構成）だと思っています。

• master（マスターブランチ）
• develop（開発ブランチ）
• feature/xxx（個別開発ブランチ(developからの切り出し)）
• release/vx.x.x（リリース用ブランチ）
• hotfix/yyyy（不具合用ブランチ）

feature/xxxブランチで各開発者が開発を行い、単体試験程度までの確認が完了したらdevelopブランチへマージしていきます。
（マージリクエスト使用しています）

運用状態

今の現場では、developブランチにリリース案件がマージされた時点でdevelopブランチを凍結し、releaseブランチを作成しています。
releaseブランチの資材で結合試験を行っています。
結合試験で不具合が発生した場合は不具合単位でreleaseブランチにコミットしています。
結合試験で不具合の対処及び確認が最終的に終了（リリースした時点）でdevelopとmasterへマージしています。（ログはまとめてます）

質問詳細

1. ご覧いただいています、皆さんの現場では結合試験行うブランチはどのようにされていますでしょうか？

(どのブランチで試験を行っていますでしょうか？）

1. 不具合が発生した際は、結合試験用のブランチにコミットでしょうか？別ブランチを切って対応されていたりするのでしょうか？

2. releaseブランチをdevelopやmasterにマージする際、不具合のコミットログはどのようにされていますか？

(まとめている・コミットしたものをそのまま残している・全て消してリリースしたことだけを残しているなど)

よろしくお願いたします。

Answer 1

※teratailではアンケートは禁止です。
なので教科書通りの回答みたいな感じになります。

---

綺麗なGitflowですね。
同じくブランチ運用ルールとして有名なGitHub Flowもあります。

大抵のプロジェクトはこの2つをまず勉強して、
自身のプロジェクトの規模等を考えながらGitflowから中抜きしてブランチ運用ルールを作る事が多いでしょう。

因みに私の職場は完全なGitHub Flowです。
バージョンを指定したいならGitのタグ機能である程度まかなえます。
GitHub Flowのような大仰な事は必要ではないという判断でしょう。

---

質問文に「Gitflow」や「GitHub Flow」といったワードが出て来ませんでした。

しかしここ迄Gitflowに酷似しているとなると
誰かから現行のプロジェクトを引き継いだ等で
体系的な勉強をせずにここまできたと思うんですよね。

もしGitflowという単語が初耳ならば、Gitflowを勉強なさっては？
「まんまうちのプロジェクトやんけ！」と瞬殺で勉強終わると思います。

---

不具合が発生した際は、結合試験用のブランチにコミットでしょうか？別ブランチを切って対応されていたりするのでしょうか？

Gitflow的な回答でいえばこうなります。

• releaseブランチの検証中に出た不具合→releaseブランチに混ぜればOK
• 本番環境(masterブランチ)で出た不具合→hotfixをmasterにマージして対応、その後releaseやdevelopに配布する

releaseブランチをdevelopやmasterにマージする際、不具合のコミットログはどのようにされていますか？

GitHubのエンタープライズ版でやっている想定での回答をします。
まぁGitLabやBitBucketでも同様です。

まずGitHubのIssueを立ち上げて、
ブランチを切って修正を開始します。
このコミット履歴に#Issue番号を含めると、Issueにこの目的でコミットされたよという情報がたされてIssueが更新されます。

git commit -m "xxxの不具合を修正 #123"

それらのコミットを勝手に潰したら対応が切れるので追えなくなります。

まぁ1件のIssueを解決する為に4〜5個のコミットがあって、
それをプルリク出してマージする際に潰して1個にしておくならまだしも、
マージされた後に潰すのは積み上げてきたコミット履歴が壊れるので危険です。

危険を排除する為に慎重にコミット履歴をにらめっこ……
この作業に何の意味があるんだい？って思います。
だったら1Issue1コミットくらいの運用ルールでやれば良いんじゃないでしょうか。

Comments

[underfield]

早速、ご回答いただきありがとうございます。
アンケートのような質問になってしまい、申し訳ございませんでした。
またご丁寧にご回答いただき、参考になりました。

> 体系的な勉強をせずにここまできたと思うんですよね。
実は１年ちょっと前からgitでのソース管理を行うプロジェクトに参画しています。
gitの操作的なところはわかり始めたところで、今のプロジェクトが急遽立ち上がりました。
今のプロジェクトもgitで管理ということで運用しているですが、
私も周りのメンバーも正しいgitの運用経験がなく、立ち上がって３ヶ月ほどはdevelopにひたすらpushするという状態になっていました。

ネットでgitのことを調べ、なるべく正しい運用をしたい、間違えた知識のままの運用はだめではないかと思い、git flowモデルにたどり着きました。
ただ、既に運用しているものを切り替えれるのかという不安もあり、git flowっぽく少しづつ運用を改善した結果が質問の状態となります。

github flowは、初めて聞きましたので調べてみようと思います。
また、不具合とissueの連携も大変参考になりました。取り入れさせていただきたいと思っています。