2

We use a monitor in our office to display information about all feature branches on our git repository. One of the reasons for this is so that we know when feature branches are 'obsolete' (i.e. all their commits have been merged to master). We use:

git log --pretty=format:'%cd %s' --no-merges --abbrev-commit -n 1 --date=short master..origin/<branch>

Recently we've been trying to keep a cleaner history by squashing commits when merging features back into master. The downside is that our current method of identifying 'obsolete' branches no longer works.

Is there a git command we can use to figure out if a branch can be safely deleted?

svick
  • 236,525
  • 50
  • 385
  • 514
Rob Fletcher
  • 8,317
  • 4
  • 31
  • 40
  • if you save auto-generated commit message in squash merge you can retrive commit hashes from it – galadog Aug 29 '12 at 11:23
  • Why use a `git merge --squash`? A simple `git merge` will generate the same big commit on `master`. And wouldn't jeopardize your `git log`command. – VonC Aug 29 '12 at 12:01
  • @VonC We do it just to keep the commit history simpler. There's then only one commit per feature so it's easy to see at a glance what was done to implement it & if we need to remove a particular feature we can just revert the single squashed commit. People are more likely to do small incremental commits when working on a branch if they know the history will get tidied up when it's merged. – Rob Fletcher Aug 29 '12 at 12:23
  • @PirateRob but a merge will always produce *one* commit on `master`, so I don't follow the point. – VonC Aug 29 '12 at 12:26
  • No, `git merge` will bring all the commits from the branch over to _master_ with an extra merge commit if there are conflicts. – Rob Fletcher Aug 29 '12 at 12:30
  • @PirateRob I think VonC is suggesting you can get at the diff another way: `git diff ~1`. You can also get single-commit reverts with `git revert -m 1 `. These two commands obviate the need for `--squash`. – Christopher Aug 29 '12 at 13:37
  • 2
    @PirateRob: do `git merge --no-ff` and you will always have a merge commit. Using `git log --first-parent` you will only see the merge commits directly on master (no merged in side branches). Also, it's always possible to interactively rebase (tidy up) a branch before merging it – knittl Aug 29 '12 at 13:39
  • @knittl yes, I think we should do something other than squashing commits on merge. Rebasing on the branch before merging it across looks like the simplest strategy. – Rob Fletcher Aug 29 '12 at 14:26

1 Answers1

0

The following only applies to branches that haven't been squashed, and thus isn't applicable directly to your situation. It might still be useful in some cases.

Well, you could always use git branch -d itself:

git checkout master
git branch -d <branch>

The -d flag refuses to delete branches that haven't been merged into HEAD, in this case, master. I actually use it for a cleanup-branches alias that simply deletes any feature branch in my repository that's already in our production codebase:

git config --global alias.cleanup-branches \
    '!git branch | grep -v "\*" | awk "{ print $1 }" | xargs git branch -d'

I suppose for your purposes you could just cron this command on a canonical repository. Any branches left over are active and in development.

Community
  • 1
  • 1
Christopher
  • 42,720
  • 11
  • 81
  • 99