CODEWITHSUNDEEP
gitgithubbranch
d3vkit
d3vkit

Reputation: 1982

Git branching from another branch

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.

Upvotes: 0

Views: 268

Answers (1)

sparrow
sparrow

Reputation: 1957

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!

Upvotes: 1

Related Questions