0

I am trying to make sure I don't mess up a large feature branch I have been working on. I have two remotes:

origin - with branch dev
my - a fork of origin, with my branch dev

So, workflow is to fetch origin, pull into my origin dev, branch from that, push up, and merge branches into origin dev:

# On my dev
git fetch origin
... received new stuff...
git pull origin dev

I had a feature which depended an un-merged other branch feature. So, I did this:

# On my dev
git checkout -b first-feature
git checkout -b second-feature-based-on-first-feature

From here, I've been following our normal workflow, where when origin dev is updated, we rebase our branch on that:

git checkout first-feature
git pull --rebase origin dev
git push my first-feature -f

And then I would pull that first branch under my second branch:

git checkout second-feature-based-on-first-feature
git pull --rebase my first-feature
git push my second-feature-based-on-first-feature -f

Today first-feature was merged into origin dev. I expected second-feature's pull request on github, which showed two commits (first-feature and second-feature), to basically just now show second-feature. But it doesn't. I rebased second-feature on origin dev, and while everything seems okay, I am worried about this. Do I just force push second-feature up?

I know this is a bit specific. I suppose my question is: how should this work, and where have I gone wrong (if I have)? I tried to follow other answers to basing a branch off a branch, but this is such unfamiliar territory, I don't want to make a huge mistake.

d3vkit
  • 1,942
  • 1
  • 24
  • 36

1 Answers1

1

I think the problem you are seeing is the side effects of rewriting history.

When you rebase, it actually changes the commit hash

The hash of a commit is depending on:

  1. the tree of this commit (i.e. the current state of your sources)
  2. The hashes of any parents of the commit
  3. the commit metadata (author date, author, commit date, committer, commit message, and similar.)

source

So the commits on your first-feature when rebased with origin/master, second-feature was still based on commits from the the original first feature, so when you rebased the second-feature with first-feature, the commits on the first-where different, then the rebase changed the top two commits where changed as well. So you had:

1) -- A 
       \ -- B
             \ -- C 
After rebase origin/dev
2) -- A  -- B'
   -- A  -- B
            \ -- C
Rebase with first-feature
3) -- A' -- B' -- B -- C'

At least this is what it appears from your flow you have described. I hope this helps!

Community
  • 1
  • 1
sparrow
  • 1,888
  • 11
  • 22
  • So, when I rebased first-feature on dev, and then second-feature on first-feature, and then first-feature was merged into dev, the first-feature under second-feature has a different commit-hash than what was merged into origin dev? (This is confusing). Are there any problems with now rebasing second-feature on origin, and pushing that up? Will it merge into origin okay? It _seems_ as though it will work out. TBH I am not super happy with the flow here and all the rebasing, but then I am not very good with git yet. Seems to go against what most say (don't rebase). – d3vkit Nov 15 '13 at 04:55
  • More precisely, rebase makes a *copy* of a (or many) previous commits, but since the copies have at least one thing changed—usually a parent commit ID—they are at least subtly different so they necessarily have different "true names" (SHA-1 values). The *old* copy of the commit is still there in the repo, and any commits descending from the old commit, still descend from the old commit. (And, @d3vkit, yes: this is why people avoid rampant rebasing. Very *selective* rebasing is fine. :-) ) – torek Nov 15 '13 at 10:02
  • git is a very large tool chest, and it has a tool for just about everything you would need to do with managing code. Rebasing is a perfectly good tool in the right context. Usually, I make it a rule not to rebase with published branches and only rebase with my local branches. But to answer your question, it should be ok to rebase your second-feature with origin. Git actions can always be reverted and undone if it doesn't work. – sparrow Nov 15 '13 at 17:22