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