GithubのPull Requestにおいてmergeされたらブランチを消すか論に終止符を打つ
概要
githubのレポジトリ運用において「Automatically delete head branches」をonにするかoffにするか悩ましいところです。
デフォルトはoffです。
GPTに聞いてみた
Q: githubのrepositoryの設定にある、 “Automatically delete head branches” をonにするかoffにするか悩んでます。どちらのほうが一般的でしょうか?
A:「Automatically delete head branches」の設定は、プルリクエストがマージされた後に、そのブランチを自動的に削除する機能です。この設定をオンにするかオフにするかは、チームやプロジェクトのワークフローと好みによって異なります。しかし、一般的な考え方をいくつか紹介します。
オンにする利点:
- リポジトリがきれいに保たれる: 不要なブランチが自動的に削除されるため、リポジトリが整理されやすくなります。
- ブランチの管理が楽になる: 作業が完了したブランチを手動で削除する必要がなくなり、メンテナンスが容易になります。
オフにする利点:
- 履歴の追跡: ブランチが削除されないため、過去の変更履歴を容易に確認できます。
- 再利用可能: 削除されないため、同じブランチを再利用して追加の変更を行うことができます。
一般的には、プルリクエストがマージされた後にブランチを自動的に削除してリポジトリを整理しやすくするため、この機能をオンにすることが多いです。しかし、過去の変更履歴を追跡したい場合や、ブランチを再利用する必要がある場合はオフにすることもあります。
最終的には、チームやプロジェクトの要件に基づいて判断してください。機能を試してみて、適切な設定を見つけるのも良い方法です。
Followerさんに聞いてみた
onにしている人が多いです。
考察
GPTが回答した論点に関しては、すでに自分の中で考えていた論点と全く同じでした。
GPTの回答から新たに得たインサイトとしては、onにしている方が多いという情報です。
私の主張
ちなみに私は残しておく派。
tigで見たときにブランチの目的が追いやすいから。
そして、やっっぱりremoteにpushした情報って消しちゃいけないと思うんですよ。他の誰かがtrackingしているかもしれないのでブランチが消えると追いづらくなってしまいます。
容量は食わないし、見づらくなるぐらいのデメリットぐらいしか無いので、どんどんstockしていくのが根本かなと思います。
もし、ブランチ名を消す運用をしていて、再度同じブランチ名で別のfeature branchを作り出したときにURIの指す中身が違ってしまうというのもあるからブランチ名はレポジトリーに対してユニークになっていることも重要です。
妥協点の模索
ブランチを残すことも、消すこともそれぞれメリットとデメリットがあります。それぞれの良いとこ取りをするための手法として、
ある程度時間が経過したブランチの重要性は下がるので古いブランチは消すという運用が考えられます。
こちらのGithub Actiionsを使えば上記の運用ができます。
手元のレポジトリで運用して居る設定を記載しておきます。一年間残しておいて、tagは自動で消さないようにしてあります。
name: Cleanup old branches
on:
push:
branches:
- master
jobs:
housekeeping:
name: Cleanup old branches
runs-on: ubuntu-latest
steps:
- name: Checkout repository
uses: actions/checkout@v2
- name: Run delete-old-branches-action
uses: beatlabs/delete-old-branches-action@v0.0.10
with:
repo_token: ${{ github.token }}
date: '6 months ago'
dry_run: false
delete_tags: false
minimum_tags: 5
extra_protected_branch_regex: ^(foo|bar)$
extra_protected_tag_regex: '^v.*'
exclude_open_pr_branches: true
Discussion