Github rebase upstream/master with origin/master
I’m rather new to github social coding and are having trouble following github guidelines. I’ll try to describe what happened and what I’m trying to achieve – hoping that more experienced git wizards can help me figure out the arcade commands needed to get there.
- Original project: https://github.com/phatboyg/MassTransit
- My fork: https://github.com/davidcie/MassTransit
- Platform: Windows, with Github for Windows + its PowerShell
- I forked MassTransit back in July 2012. Its master branch back then was at version v2.1.1, with last commit on Mar 29, 2012.
- Following github advice, I then started coding some changes on a topic branch.
- A few commits later, when the feature was finished, I merged my topic branch into my clone’s local master and then pushed that to github.
- Ever since Mar 29, 2012, MassTransit was being developed on its develop branch. All of those changes, making up v2.6.0, were merged with its master recently.
What I’d like to do
I’d like to get all changes that were merged into upstream/master. Preferrably as their respective commits, not one massive commit of hundreds of files. Because I was doing development on the former upstream/master (dated Mar 29, 2012), I guess would effectively need to “insert” some commits in between the last upstream/master change of Mar 29 and my first commit of Aug 8, and then on top of that add those that happened later. How do I do that?
(I’d also like not to destroy my commits/fork in the process 😉
What I tried
git checkout master git remote add upstream git://github.com/phatboyg/MassTransit.git git rebase upstream/master git push
However, it would not let me then do
git push, complaining that my local tip was 10 commits behind the origin (possibly the commits I made on my topic branch and later merged into origin/master?).
It seems that I may have been bitten by recommendations. Eg. perhaps it would be better to create a separate branch, eg. local-master, and treat that as… well, my own master. Then master would be there only for keeping in touch with upstream/master, and I would occasionally rebase origin/master with upstream/master and merge with origin/local-master…
How do you guys manage your forks?
I’ve been unable to find a way to visualize branch history, what branch was merged with another and when, etc. Github for Windows only shows a flat history for the currently selected branch (sad face here). The website does have some visualizations for the network (here is one for MassTransit), but this feels a lot less informative than say the graphs in TortoiseHg. Am I missing something obvious? Does everyone else just remember what was merged with what and when?
Edit (31st August)
I’m sharing a poor-man’s visualization to help explain what happened.
- I forked when C1 was latest on upstream/master.
- I then developed on my origin/feature-1.
- One the feature was complete, I merged it with my origin/master.
- When upstream/mega-feature was completed, it was merged with upstream/master, effectively historically copying C2 and C3 to upstream/master. (Or perhaps upstream/master was rebased with upstream/mega-feature?)
- I would now like to copy C2, C3 and C4 to my origin/master.
2 Solutions collect form web for “Github rebase upstream/master with origin/master”
I assume that you will be, or have, set up an
origin remote to your fork, and the same again for
upstream (as described).
I would then do a fetch of the
upstream so that you have all their branches held locally. You can then make the comparisons between the repos and see if there is a common commit at or near the divergence date.
gitk --all visualisation is useful here. Don’t forget that even if you do a rebase the old commit series is still there so you can give it a name
[EDIT] A wordy description.
Clearly the merge commit is ‘getting in the way’ so needs to be massaged away so that the repos can be brought in sync again.
- create a
tempbranch at your current head, so nothing gets lost.
resetyour master branch back to the last common commit between you and upstream.
resetyour feature branch to just before the merge.
checkoutthat merge commit to get the working tree as you expect, then
- switch to your feature branch (without checking out anything!)
committhat fixed work tree on your
featurebranch (i.e. no merge).
You now have a clean line on
master, a clean but old line on
feature, and any post merge developments on
temp. if Happy, you should be able to force push this to your
pullfrom upstream – it (i.e.
master, etc.) should all fast forward.
rebasethose post merge developments from
featureto the last commit you know well on master (should be relatively easy).
feature(again) to the latest commit on master, fixing up as you go (combine with the last step if it’s easy;-).
This should finally give you a clean line of feature development at the head of master, and suitable for pulling upstream without any conflict.
Here are some ideas.
Cherry pick method:
git checkout master git cherry-pick C2..C4
New branch rebase method:
git checkout upstream/master git branch new-master git rebase master # new-master should now look like what you want, once you confirm this git branch -m master old-master git branch -m new-master master
Rebase –onto method (lets you pick which range of commits you want):
git checkout master git rebase --onto master C2 C4 # puts you into a detached HEAD git branch new-master # rename branch as above if it is correct