9

Scenario: I've forked a github project and begun working on it (after adding the original project as a remote called 'upstream'). While working on my fork, a number of releases are made to the upstream project: v1.3-stable, v1.4-stable, v1.5-experimental, etc. Now I need to merge in the upstream commits to my master branch, but ONLY up to a specific release, for example, release v1.4-stable. What's the best workflow for this scenario?

Harald Nordgren
  • 11,693
  • 6
  • 41
  • 65
rednoyz
  • 1,318
  • 10
  • 24

4 Answers4

4

Assuming v1.4-stable is a tag on the remote, you can apply those changes to your local repo by calling this from the branch that contains your work:

git fetch
git rebase --onto $(git rev-list -n1 v1.4-stable)

Rev-list finds the ID of the latest commit from v1.4-stable, after which those commits are replayed and your own work placed neatly on top. There will be conflicts if the remote has changed significantly since you forked.

If v1.4-stable is a branch on the remote you will instead want to do

git pull --rebase origin v1.4-stable
Harald Nordgren
  • 11,693
  • 6
  • 41
  • 65
2

This assumes that v1.4-stable is a a tag for a commit indicating the release, on the master branch. Checkout master and pull the latest changes:

git checkout master
git pull --rebase

Next, rebase your development branch on top of this commit. Make sure your working tree is clean and your HEAD is pointing to your dev-branch:

git rebase v.14-stable

This command will change the base of your branch to include the v.1.4-stable tagged commit, and all other releases preceding it.

Before rebase:

o---o---v.1.2---v.1.3---v.1.4---v.1.5-exp  master
     \
      o---o---o  dev

After:

o---o---v.1.2---v.1.3---v.1.4---v.1.5-exp  master
                           \
                            o---o---o  dev
1

First make sure you are working in a dedicated branch for v1.5-experimental.

Second, reset your master branch to upstream/v1.4 (make sure you don't have any work in progress: an hard reset would wipe them out)

git fetch upstream
git checkout master
git reset --hard upstream/v1.4
git push -f

Finally, rebase your v1.5-exprimental branch on top of master (that is on top of v1.4)

Fist, activate rerere (in case you have to do multiple rebase later on: that will record how you resolve similar conflicts in the past)

git config --global rerere.enabled true

Then rebase (replay your commit from your branch on top of v1.4):

git checkout v1.5-experimental
git rebase master
git push -f

The conflicts you will have to resolve there should only be conflicts of interest (concurrent modifications done both in upstream and in your experimental branch).

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • 1
    You're telling someone to run `git reset --hard` on their repo. At least warn about the possible consequences... – Harald Nordgren Nov 10 '16 at 23:48
  • @HaraldNordgren thank you. I have edited my answer accordingly. – VonC Nov 10 '16 at 23:53
  • 1
    What makes you think they wouldn't have work in progress? The whole point of this question seems to be about rebasing to consolidate personal work with the changes on the remote. A git reset seems downright destructive. – Harald Nordgren Nov 10 '16 at 23:56
  • @HaraldNordgren it is just the generic warning for an hard reset. Here, the goal is to reset master to where it should be, which is the release on top of which you will rebase your work. – VonC Nov 11 '16 at 00:08
-1
git pull --rebase origin v1.4-stable
Bhargav Rao
  • 50,140
  • 28
  • 121
  • 140
Balaji Natarajan
  • 1
  • 1