Best approach for forking git into a new repository but still be able to merge repos and push changes one repo only?


I’m working on a fork of a project, let’s call the original OpenX and a more polished, stable fork of it, let’s call it StableX. Due to "political reasons", they are on different Git repositories and I take new functionalities from OpenX and add them to StableX on a yearly basis, then polish them and add StableX functionalities – all manually.


Is there something like "merge repo1 and repo2; show me conflicts so I fix them manually and push final thing onto repo2" in Git?

Long story:

I’m still new to Git (long-time svn user) so please forgive me for mixing SVN and git terminology 🙂 I’d like to know if I can somehow automate my workflow:

OpenX is hosted on REPO1,
StableX is hosted on REPO2.

OpenX has a "release" branch that gets branched out every couple of months, but it’s still a little """untested""" (read: never ready for real production). Owner of OpenX is not interested in stability fixes (only the new features). Even more, original owner "won’t host my ”’nonsense”’ additions, skins and stuff they don’t need".

That’s why I have my own "production ready" fork called StableX.

But still, once a year or so, I take all new features from OpenX, include them into StableX, thoroughly test them on real data, add some things / patches / fixes and release it as StableX after testing.

Until now, I was manually patching latest OpenX version with StableX fixes and additions, which took a day of two of semi-manual work (list of my additions / files + Meld diff). So I basically:

  1. exported from OpenX SVN1 (after they switched to Git, "archived out")
  2. copied export/archive into a temporary directory
  3. did diff + additions + fixes
  4. copied pathed OpenX onto StableX developement branch, commited (pushed) it onto StableX repo
  5. tested, fixed new bugs, eventualy released stable branch of StableX

Is there a way to automate this yearly thing in git between two repos? Something like "merge repo1 and repo2; show me conflicts so I fix them manually and push onto repo2"?

Thanks 🙂


Well…. maybe you need to start getting into the git way and that might ease if off a bit. The fact that you hold multiple repos doesn’t matter in git. Git cares about commits and you can host them (the same commits, for example) in multiple repos. So…. the whole thing might have started like this:

git clone openx-url my-local
cd my-local
git checkout -b stable origin/main # create stable branch from origin/main
# start doing all your magic in stable branch
# when you are finally happy with how stable branch is after changes are committed:
git remote add stable-repo my-stable-repo-url 
git push stable-repo stable # hold stable branch in stable repo
# a year goes by
# let's make sure we are on our stable branch
git checkout stable
# let's see what is in openx and merge those changes
git fetch origin
git merge origin/main
# now you start having fun to stabilize the whole thing and correct al issues
# when you are finally happy with what you got
git push stable-repo stable
# let's wait for one more year

Now…. let’s assume that you have two separate histories that you hold in two separate local repos… is it still possible to correct it and get it all in a single repo/single history so that you can then continue using the yearly-git-merge workflow? Sure, it’s possible…… let’s assume that you do not care much for the history that you did to stabilize your branch…. then you could do this:

cd local-stable-repo
git remote add unstable url-to-original-openx-repo
git fetch unstable
# now you can see _all_ stuff that is in unstable
# create a branch temporary on the commit from unstable/main that you last stabilized.... it might have been from a year ago, make sure to pick the right one:
git checkout -b temporary id-to-the-commit
# let's put our stable stuff on top of this
git restore --staged --worktree --source=the-local-stable-branch -- . # the stable branch is your local branch
# now, you have all changes use to _stabilize_ them in index, ready to commit
git commit -m "Here is all my magic to stabilize"
# and now you got all the stabilization changes in a single commit
# let's put local main branch over here if we _really_ like it
git branch -f main
# let's push this into our stable repo
git push origin -f main 
# now you can merge the changes that were applied on unstable/main after the commit that you last started to work on
git merge unstable/main
# do all your magic to stabilize it
# when you are done
git push origin main

We can now go into the yearly pull workflow:

# wait for a year
git fetch unstable
git merge unstable/main
# stabilize again
git push origin main
# wait for a year....
git fetch unstable
git merge unstable/main
# stabilize again
git push origin main
# wait for a year
# you see the pattern, right?

Tip: you have a bunch of commands there… I would sit down and digest every single one of them to understand what they are doing… that will be a good way to get yourself into the git mode. Feel free to make questions…. also, I might have made a mistake here or there as I am writing from memory but the basics should be sound (or it might be the case that I wrote it correctly).

Answered By – eftshift0

This Answer collected from stackoverflow, is licensed under cc by-sa 2.5 , cc by-sa 3.0 and cc by-sa 4.0

Leave a Reply

(*) Required, Your email will not be published