1

I always prefer to rebase -i my changes locally and leave a very clean and useful commit history for my feature branches. This also have the benefit of being able to prune local/remote branches after they are merged into main (or master) with total confidence by using branch -d.

For example, I use the following alias/macro after merging a branch without squashing it:

# ~/.gitconfig file snippet
[alias]
cleanmerged = "!git branch --merged | grep -v '*' | xargs -n 1 git branch -d"

But, when working with projects where the team just YOLO their commits and then require the unsightly mess to be squash-merged by having it be mandatory on github, I am not sure how to confidently clean local branches so I end up just leaving everything around, which makes clean up even less-certain later on as it depends on memory.

Is there any way to fix this? any incantation that will check if the squashed branches are already present in main (or master) with confidence?

Gabriel
  • 177
  • 13
  • Does this answer your question? [Remove tracking branches no longer on remote](https://stackoverflow.com/questions/7726949/remove-tracking-branches-no-longer-on-remote) – ti7 Jun 22 '21 at 00:23
  • @ti7 thanks but not quite. Because the branches are still on remote too. it can be a good secondary step though. – Gabriel Jun 23 '21 at 20:47

2 Answers2

1

I wrote a custom ruby script for this purpose which I've been using for several years now. One of these days I'll release it as a ruby gem. I keep my custom ruby scripts in a folder like ~/dev/ruby

Then add an alias in your shell profile like alias git-clean-branches="ruby ~/dev/ruby/git_clean_branches.rb"

Or you could rename it without .rb and make it executable

chmod +x git_clean_branches

And symlink it

ln -s ~/dev/ruby/git_clean_branches /usr/local/bin/git_clean_branches

And if your $PATH variable loads usr/local/bin then you're good.

Here is the script code

lacostenycoder
  • 10,623
  • 4
  • 31
  • 48
  • 1
    This is clever. slightly more fragile as it depends on branch names instead of content as the original non-squash solution, but i'm starting to believe this is the only solution to this. can probably be done with a couple grep and git commands directly on an alias line... thanks for sharing! – Gabriel Jun 25 '21 at 16:13
  • 1
    @Gabriel yes it has dependencies, but it's been working just fine for me :) I used to do without the `gh` cli tool and I'd lost an earlier version of this script. But you may want to have a look at https://stackoverflow.com/a/66843547/3625433 which links to a python script that seems similar, though I haven't tried it and didn't want to bother adding python dependency as any system with git will already have ruby. – lacostenycoder Jun 25 '21 at 16:34
0

After the squash merge into main/master, just go ahead and delete all three branches: your local branch, your remote-tracking branch, and the branch on the server.

There is no loss of history or data, because the pull request keeps the "branch" reachable forever.

matt
  • 515,959
  • 87
  • 875
  • 1,141
  • 1
    the question is on finding the merged branches automatically to know which ones one can delete. Branches usually linger around for days or weeks until reviewed and it is easy to loose track. – Gabriel Jun 23 '21 at 20:47
  • Well, when they squash and merge on the remote, they delete the branch. So you can do a remote show to see what remote branches there are are; if you have one that the remote doesn't have, you can delete it. Of course that doesn't help with the "automatically" part. :) – matt Jun 23 '21 at 22:49
  • `@matt` you suggestion is dangerous. it will delete all your still-local work that doesn't even have a PR ready remotely. that is work lost forever if you don't do the even more complicated work to recover headless lost branches. – Gabriel Jun 25 '21 at 16:10