If you try to delete a branch that contains changes that haven’t been merged to its upstream, git warns you, the branch is not fully merged. If you are sure you want to delete it, run 'git branch -D xxx'. Suppose you want to check that all of the changes in the branch have been cherry-picked or rebased into the upstream branch. How can you confirm this? How can you do the “If you are sure” step?
One way to do this is to merge the branch into its upstream and see if the result produces any changes.
# Detach the HEAD from the upstream so we can do some tinkering.
$ git checkout --detach featurebranch{@u}
# Propose a merge of the feature branch.
$ git merge featurebranch
$ ⟦ resolve any merge conflicts and commit ⟧
# See if anything would have changed.
$ git diff HEAD HEAD~1
# Return to original branch, abandon detached HEAD.
$ git checkout -
If the git diff produces no output, then everything in your featurebranch is already present in the upstream, so you can delete the featurebranch.
If the git diff produces output, then there is content in your featurebranch that is missing from the upstream, so you want to look at those changes and see if they are worth keeping.
The older the featurebranch is, the more likely that you’ll get a merge conflict when doing a test merge with its upstream, since that gives the upstream more time to make a conflicting change to the files that you changed in featurebranch.
Isn’t this what the “git cherry” command is for?
I think of myself as a skilled git user, but every time I see a post here about git, I learn something new.
For those that aren't familiar with the `featurebranch{@u}` syntax, like me, this StackOverflow post provides a good description of the various commit-ish and tree-ish syntaxes that git supports.
I think what it means (when used with `git checkout`) is checkout the upstream version of featurebranch - it is not clear to me how/if this...
Besides what Raymond wrote: your target upstream repository might not be named “origin”, and there might even be multiple upstream repositories. When I am working on open-source GitHub issues, I usually have two upstream repositories, one for the original project, and one for my forked version. That way I can work on my PR in my fork, and keep my fork and the original project synced.
Agreed, I think Raymond’s deep dives into weird git areas are my favorite part of the blog – it’s the thing I probably learn the most useful things for day to day development from.
It’s possible that the upstream of the local branch “featurebranch” is not “origin/featurebranch”. It might be “origin/raymond/bugfix-1234567” (because your team has rules about branch names, but you want a nicer name locally), or even “personal/featurebranch” if you pull from one repo and push to another.