CODEWITHSUNDEEP
gitbranching-and-mergingremote-branch
emboss
emboss

Reputation: 39660

Synchronizing local git forked repo branches with changes from remote original

I found a lot of q & a about synchronizing a forked git repository with the original remote repository but none applied to my exact problem.

Let's assume I forked a project with a remote name of upstream, my fork's name is origin. I have a master and a dev branch locally that track master and dev of origin.

As long as I make no changes to my forked repo I know I can sync my forked repo at origin with upstream/master by 

git checkout master
git pull upstream master
git push origin master

So far, so good. But now I work on my local dev branch and once I'm done I would like to merge it into my local master. But first I would bring my local master up to date with the changes in upstream by

git checkout master
git pull upstream master
git push origin master

First Question(s): Is this correct? But then what would I do with my local dev branch? Rebase it on my updated master before merging it into my local master or try to merge it without rebasing? Or should I try to keep my local dev in sync with upstream/master all along, by pulling in upstream/master from time to time?

Once this is accomplished I would

git push origin master

and delete my dev branch, locally and in origin. But now my master (locally and in origin) deviates from upstream/master by the changes made by my local dev.

Second Question: What is the proper way to go now to keep in sync with upstream/master? Do I still simply do

git checkout master
git pull upstream master
git push origin master

or is anything else recommended here (e.g. some form of rebasing)? If I created a branch dev again, would I apply the same strategy that applied for the first question again or would something else apply?

Thanks for your help!

Upvotes: 4

Views: 855

Answers (1)

Jani Hartikainen
Jani Hartikainen

Reputation: 43253

Question 1:

I'd say either way is fine. In my experience something like this usually works pretty well:

  • When you merge from upstream/master into local/master, it makes sense to rebase local/dev.
  • By rebasing dev when you get changes to master, you reduce the size of the merge/rebase you'd have when you want to merge dev back to master.
  • This works as long as you always rebase changes from master to dev

Once done with dev, you can either rebase once more and then merge on master, or simply merge directly on master. You may want to change the message in the merge commit to indicate what was in your merge.

Question 2:

When merging from upstream, as long as you don't have any differing changes on your local or origin, the merges will be fast-forwards. This basically means git just stacks the commits from upstream on top of whatever you had, and there will be no merging of conflicts or anything.

Because of this, you don't need to rebase or anything. As mentioned above, if you work on something on dev, it may be a good idea to rebase dev at this point so you'll have it more up to date.

At the point where you have changes that differ from upstream, you will have an actual merge and the possibility to do a rebase if you so wish.

Rebase or merge?

This is mostly up to you and how you like to work, but if you consider rebasing, remember that it changes history.

If anyone else is using origin/master or origin/dev, and you rebase it, it's possible they will run into some issues when trying to merge their work back. So generally if a branch is being used by more than just one person, you should use merges. Never use rebase (or anything else that changes history) if more than one person uses a branch.

Upvotes: 5

Related Questions