Reverse a relationship between git branches

Question

Say you had a git branch named branch A and you created a new branch derived from branch a named branch B.

Would it be possible through a series of commands(rebase?) to have branch A be derived from branch B? If so, how would this affect other branches already derived from the branch A? How would the commit history of the branches be affected?

To give the question context:

I have a staging branch(B) and a branch that I derive task branches from(A). I am seeing that every time I pull request A into B, when I compare B to A on GitHub, the changes that I just pull requested into B are showing up as differences. To fix this I keep having to locally merge A into B (which doesn't change any files) to get the comparison of the two to show up as having no differences. I want to reverse their relationship to fix this.

Feel free to answer this question in a way that simply solves the problem I listed here.

Visual:

I have:

   *(Feature Branches)
  /
 /
A (Developing Branch)
 \
  \
   B (Staging Branch)

I want:

B (Staging Branch)
 \
  \
   A (Developing Branch)
    \
     \
      * (Feature Branches)

This site is about *practical programming problems*; is there something you're actually trying to achieve with this? Have you looked into what rebasing means? — jonrsharpe, Jan 04 '18 at 21:09
Yes, I have a staging branch(B) and a branch that I derive task branches from(A). I am seeing that every time I pull request A into B, when I compare B to A on GitHub, the changes that I just pull requested into B are showing up as differences. To fix this I keep having to locally merge A into B (which doesn't change any files) to get the comparison of the two to show up as having no differences. I want to reverse their relationship to fix this. — , Jan 04 '18 at 21:14
Then please [edit] the question to explain the context of what you're doing, what you've tried and what precisely the problem with that is. — jonrsharpe, Jan 04 '18 at 21:16
In Git, branches don't derive from branches at all. Commits have parents, and branch names point to commits. From the existing set of branch-names-as-pointers, you can construct / construe some sort of relative relationship of the branch names—but branch names *move*. See https://stackoverflow.com/q/3161204/1256452 for more on this concept. — torek, Jan 04 '18 at 21:48
git checkout -b foo bar would create a branch foo derived from branch bar. I get that its all commits underneath, but I don't see why its incorrect to say that a branch is derived from another. Branch A points to a commit and Branch B points to its parent, how is it wrong to say that branch A was derived from branch B? How would I reverse the commit ancestry then? — , Jan 04 '18 at 22:29
When you say "showing up as differences", what about that is a problem? Are these showing up as conflicts? Each commit contains a set of changes (or differences, they way you call them). This is normal and shouldn't be considered in anyway a problem. The whole point of a pull request is for a person to review those differences before merging. — eddiemoya, Jan 08 '18 at 16:38
The pull request is correctly showing the differences and works as expected when the code is merged. The problem is after the pull request is merged, If I compare the two branches on GitHub, the changes that were just merged in the pull request are showing up. To fix this (so it shows 0 files being different when I compare the two branches). I keep having to locally merge my developing branch into my staging branch (This 'merge' changes 0 files). This is a nuisance. — , Jan 08 '18 at 18:55
Can you elaborate on how you're comparing after the pull request is merged? I would try to eliminate Github as a variable - do you see the same problem merging a branch locally (instead of a pull request), then running `git diff A B`? — Stecman, Jan 09 '18 at 01:53
When I say compare, I mean when I select the compare button on the GitHub web interface. I will run a git diff the next chance I get. — , Jan 09 '18 at 13:22

score 3 · Accepted Answer · answered Jan 09 '18 at 13:29

To achieve what you want you should not do pull requests from your develop branch into staging. Instead, staging branch should follow develop, and you should update the staging branch by rebasing.

Before

o < develop
|
o < staging
|
o < v0.2
|
o < v0.1

After

o < develop  < staging
|
o 
|
o < v0.2
|
o < v0.1

You can do this locally by calling

git checkout staging
git rebase develop
git push origin staging

Reverse a relationship between git branches

1 Answers1