とある開発現場で、GitHub Flow をベースとしたワークフローで開発をしていました。
featureブランチをdevelopブランチへマージした後に、そのfeatureブランチは削除すべきかどうか、悩みました。
featureブランチは、issueを切って、それを元に作っています。
個人的には、削除する派です。
コミット内容は issueから追うだろうし、GitHub上から開発途中の未マージ以外のブランチが見えてしまうのも可読性よくないかなと思って。
結論
削除するでよい。（と思う。プロジェクトの方針とかにもよる、となるだろうけど）
確認した内容整理
ググって確認
削除するのが一般的なような気がします。
※ほぼ、一択なのでリンクは割愛
残す派である意見としては、誤って消してしまうリスクぐらいが見受けられました。
（未マージなものは、簡単に削除できないはずですが、それでもいろんな開発者がいるので、可能性はゼロではないですかね）
また、GitHubの設定で、自動削除する設定があるようでした。
これ有効にすればよいのでは、、、デメリットあるのかな。
ChatGPTで確認
※質問が削除派よりな文になっています。。。
Q:
Githubで Pull Request においてマージされたブランチは不要となり削除して問題ないと考えております。
削除するのと残しておくのは、どちらがよいとされていますか。
また、削除する場合、残しておく場合のデメリットも述べてください。
A:
GitHubでPull Request（プルリクエスト）においてマージされたブランチを削除するか残すかにはいくつかの要因が影響します。以下に、それぞれの選択肢に関連するメリットとデメリットを説明します。
ブランチを削除する場合:
メリット:
整理されたリポジトリ: マージ済みのブランチを削除することで、リポジトリが整理され、開発者がどのブランチがアクティブでないかを明確に把握できます。
ブランチの数を抑える: ブランチが増えすぎないようにするために、不要なブランチを削除することはリポジトリのメンテナンスを容易にします。
デメリット:
過去の作業へのアクセス: マージ済みのブランチを削除すると、過去の変更履歴やコードにアクセスすることが難しくなります。特にバグ修正や機能の再評価が必要な場合、過去のブランチが役立つことがあります。
コラボレーションの問題: ブランチを削除すると、そのブランチ上でのコラボレーションが困難になる場合があります。たとえば、別の開発者が以前のブランチで作業している場合、それを維持する必要があります。
ブランチを残す場合:
メリット:
過去の履歴へのアクセス: マージ済みのブランチを残すことで、過去のコード変更や議論に簡単にアクセスできます。これはバグ修正や問題の特定に役立つことがあります。
コラボレーションの柔軟性: 開発者が必要に応じて以前のブランチで作業を再開でき、コラボレーションがスムーズに行えます。
デメリット:
リポジトリの混乱: 多くのマージ済みブランチが残っている場合、リポジトリが混乱し、管理が難しくなることがあります。
ストレージの使用量: ブランチを残し続けることで、リポジトリのストレージ使用量が増加する可能性があります。これは大規模なプロジェクトでは問題になることがあります。
選択肢はプロジェクトのニーズやチームのワークフローに応じて異なります。一般的には、マージ済みのブランチを長期間残すことは避け、定期的に整理することが推奨されます。ただし、重要な履歴やコラボレーションのニーズに応じて、一部のブランチは残しておくことが有用である場合もあります。
「ブランチを削除する場合」のデメリット、「ブランチを削除する場合」は、ブランチからアクセスするより、その修正にあたるissue、もしくは Pull Request から辿るのが普通と思う。
（時間が経てば経つほどブランチ名から内容を追うのは難しくなる認識）
「コラボレーションの問題」は、マージされたところからじゃなくてそのブランチからじゃないとダメなのがちょっと想像できない。あってもレアケースだと思うので、そのコミットからHEADとって新規にブランチ切るとかでよいのかなと思いました。
コメント