0

There is an external repo that is updated regularly. I maintain a fork of that repo. I want to get the updates from the upstream repo and build releases with the latest changes. My fork is mostly just a vanilla upstream clone; however, I have several small changes, mainly to configuration files, along with several additional build and CI files I've added.

For legal and practical reasons, these changes will never be committed back to the upstream branch.

I don't really want to commit my changes to the master branch, because that will conflict with upstream changes unless I track them on separate branch names. I thought about making all my changes in a separate branch and constantly merging or rebasing after each upstream pull, but thought that might lead to additional issues and be unintuitive to other developers.

What are my options for maintaining changes on top of an upstream repo that will cause the least amount of headaches and won't seem completely foreign to any other developers that work out of the forked repo?

Brendan Abel
  • 35,343
  • 14
  • 88
  • 118
  • Proper way: contribute back to upstream. For your own use: just rebase (I do this regularly for many repositories I have, not a big deal, users know this and do their best to not rely on my forks). – 0andriy Aug 11 '20 at 22:33
  • @0andriy Rebase breaks the property "*won't look completely crazy to anyone else that has to work out of the forked repo*" Merge is a much better option: more cooperative. – phd Aug 12 '20 at 09:48
  • https://stackoverflow.com/search?q=%5Bgit%5D+update+fork – phd Aug 12 '20 at 09:49
  • @phd, you probably didn't get my comment. Read it again, please! (Actually the accepted answer in the dup question also bending to the rebase than merge) – 0andriy Aug 12 '20 at 10:51
  • @0andriy That's up to you. I still don't recommend rebase even for sole user. I used to use rebase workflow. After a few years I switched to merge workflow and now recommend it over rebase. Rebase is only for not yet published commits. – phd Aug 12 '20 at 10:56
  • @phd, depends on the use of your repository, there is no black and white sides of it. If you do a fork of the alive project w/o contributing back then this is something wrong on a different level (philosophy of Open Source, for example), but there is no issues with rebase. The rule of thumb I'm using is merge in upstream, rebase in downstream. If you upstream, you do merges. – 0andriy Aug 12 '20 at 10:58
  • @0andriy I will never be able to commit these changes to upstream, they contain site-specific information and aren't useful to others. – Brendan Abel Aug 13 '20 at 16:35
  • Exactly my case when I keep all my branch histories clean, by implying rebase on top of each release of my choice. – 0andriy Aug 13 '20 at 19:51

0 Answers0