0

I am maintaining a forked version of another Free Software project. It offers few extra features that cannot be merged with the upstream at the moment. And I want to keep this fork, up to date with the latest updates of the upstream project.

This is what I do:

  • Have another branch like 'my-custom-version'
  • I keep local master, synced with upstream master
  • I use git rebase to rebase my custom branch with master on every new release of upstream project
  • Since there are some conflicts between my branch and master (like version and description in package.json file, I get merge conflict. I solve the conflict and use git rebase --continue.

Here, I think my history gets corrupted as the merge happens to replace or amended to the last commit. This makes me worried about if my approach is right or not.

Should I rebase my custom branch (which is like master of the customized fork) with master? If so, how should I rebase to keep the history safe. If not, what is the right approach?

Mostafa Ahangarha
  • 340
  • 2
  • 14

1 Answers1

1

By definition rebase rewrites history. There's no easy way to make it safe, and indeed it is dangerous to rewrite history that is publicly visible.

I would say the cleanest approach is just to do the regular merge from master to your branch. 

git checkout custom-branch
git merge master

Git graph will look like this (A - common base, B - your own changes that you want to keep, A1..A4 - development going on in master, M1, M2 - your merges):

A   -> A1 -> A2 -> A3 -> A4 (master)
|            |           |
+-> B -----> M1 ------>  M2 (custom branch)
sbat
  • 1,453
  • 10
  • 21
  • But this is not solving my issue. I should keep updating my branch based on the latest updates in the main repo. Currently I try to keep master identical and keep my feature branch as my own master. How should I do it this way? – Mostafa Ahangarha May 18 '20 at 12:31
  • Unless I am missing something, you can do `git pull` to sync master, which will make it identical to the upstream master. Then you merge your master --> custom-branch, adding all the new things that occured on the master and keeping your own changes. Right? – sbat May 18 '20 at 12:40
  • Added how the git tree would look like, if I understood your situation correctly. – sbat May 18 '20 at 12:45
  • 1
    OK! I think you somehow suggesting I consider pull upstream master to my master and them merge those changes to my custom version and sure, resolve conflicts accordingly. I even can do merge on a new feature branch before merging into the custom-branch. Am I right? – Mostafa Ahangarha May 18 '20 at 12:47
  • 1
    Sure. If this is open source project accessible to everyone you can make two branches "original-master" (will track the upstream master) and "master" (will include your changes). Just so that everyone can clone the repo, get the default master branch and just use it with all the changes you've made. You, as a maintainer, will sync original-master with the upstream master, and merge it to master. (But this all is just choosing the naming convention, as master does not have any special meaning in git afaik.) – sbat May 18 '20 at 12:55
  • 1
    Sounds good. I wait for few days if possibly anyone come with a better solution. Though I think what you say all make sense. Then I will accept the answer. Thanks for your help. – Mostafa Ahangarha May 18 '20 at 13:57