So I have this exact need:
There is an upstream project doing their own thing over git and I want to build container images locally and commit them to my image repository all while following the same version system as upstream.
To be more precise (perhaps abstract) about my need, what is the best way to apply the same patch when upstream release a new version.
Any input and best practices or lessons learned are welcome.
If the changes are so small, I’d say you could just rebase your fork periodically, as it would generate very few conflicts.
I am over thinking this, but wouldn’t history be lost this way? Like If I wanted to revert to an earlier version.
You can merge instead of rebasing. That would preserve the history.
Ideally, both your local commits and upstream commits should remain untouched. If you want to revert either, you can rebase, revert local history or even fork your local branch.
Currently I have a local repository with two remotes, one is mine, the other upstream. I just had to update today So I updated upstream, cherry-picked the last commit in new release branch and pushed to main (my origin).
But I am too lazy to keep looking for which commit to cherry-pick.
On your remote, I’d have a branch tracking upstream, and a fork of it with your changes. Then you can either rebase it on top of new versions or merge the main branch into your fork periodically.
Thanks. I am going to give this approach a try.
