0

I've made a private fork of a public git repository and want to keep the fork up to date with upstream. Upstream will not take pull requests and I also have no interest in contributing patches to upstream. I have made several non-trivial changes that usually require manual intervention to properly merge (auto-merge won't work, results in merge conflicts and/or broken builds).

What is the best and easiest way to maintain this for as long as feasible? in terms of amount of work required. Is rebasing or merging the branches better? Is there a way to structure the code to require less manual intervention for merging? Is there a better way to organize the commits for easier merging? Merge frequently with upstream or infrequently all at once?

Any tips would be welcome thanks,

goweon
  • 1,111
  • 10
  • 19
  • 1
    Questions with words like *best* in them are generally unanswerable (at least on a technical basis). We can say, however, that the longer you go between merge/rebase/whatever operations, the harder it tends to get. – torek Jan 12 '22 at 05:19
  • Does this answer your question? [Git workflow for maintaining a derivative fork](https://stackoverflow.com/questions/22471151/git-workflow-for-maintaining-a-derivative-fork) – jkmartindale Apr 07 '22 at 22:46

0 Answers0