If you’re not seeing any difference, I suspect you lost your changes. You can likely use git reflog to identify the branch that existed before the rebase, and use git reset --hard <my-branch-tip-before-rebase> to get back the original branch. And yes, you’ll have to run through the process again. 🙁
I’m not quite sure how you ended up with them looking the same though. I would have expected to see the following with the command you gave:
1 = 2 = 3 = 4 (master)
\ \
\ 5' = 6' = 8' (my_branch)
\
5 = 6 = 7
In this case, you probably should’ve used rebase --onto:
git rebase --onto master <commit id for 6> my_branch
That would have left you with a graph that looked like this:
1 = 2 = 3 = 4 (master)
\ \
\ 8' (my_branch)
\
5 = 6 = 7
As far as losing your changes, it does take a bit of practice dealing with merge conflicts, especially when you have a couple of big blocks that look nearly identical. I always resort to looking at the actual diff introduced by a commit, and the attempting to tease out that change and merge it with what is already on the branch in an appropriate way. I can easily see how your change may have gotten lost in there.
One thing to remember. If you don’t expect a bunch of merge conflicts–because you don’t feel the sources diverged enough, the seeing one is a warning flag of doing something wrong. It’s good to back up, by doing a git rebase --abort, investigating the branches and checking again if you expect a conflict. Make sure to take note of where the conflict happened (there’s usually a “Applying …” just before rebase kicks you to the command line). That’s usually a great place to start.
At times, conflicts are unavoidable, and are tedious to work through. But I suspect with practice, you’ll run into this problem less.
For more information on transplanting changes between branches, look at the git rebase man page. Search for “rebase –onto”. The first hit should land you in a section talking about transplanting changes to another branch.