Welcome to End Point’s blog

Ongoing observations by End Point people

git branches and rebasing

Around here I have a reputation for finding the tiniest pothole on the path to git happiness, and falling headlong into it while strapped to a bomb ...

But at least I'm dedicated to learning something each time. This time it involved branches, and how git knows whether you have merged that branch into your current HEAD.

My initial workflow looked like this:

 $ git checkout -b MY_BRANCH
   (some editing)
 $ git commit
 $ git push origin MY_BRANCH
 $ git checkout origin/master
 $ git merge --no-commit origin/MY_BRANCH
   (some testing and inspection)
 $ git commit
 $ git rebase -i origin/master

This last step was the trip-and-fall, although it didn't hurt me so much as launch me off my path into the weeds for a while. Once I did the "git rebase", git no longer knows that MY_BRANCH has been successfully merged into HEAD. So later, when I did this:

 $ git branch -d MY_BRANCH
 error: the branch 'MY_BRANCH' is not fully merged.

As I now understand it, the history is no longer a subset of the history associated with MY_BRANCH, so git can't tell the two are related and refuses to delete the branch unless you supply it with -D. A relatively harmless situation, but it set off all sorts of alarms for me, as I thought I messed up the merge somehow.

1 comment:

Brian J. Miller said...

Based on some offline discussion it was determined that the potential mishap may have been higher up the history, where Jeff did "git checkout origin/master" but we couldn't determine if this was the issue based on the bash history or whether he issued "git checkout master" as one would expect. is possible that the issue was with checking out against a remote branch which you'll rarely want to do, unless you actually know why you are doing it.