So by now the git-flow of ‘Fork the upstream, create a branch in your repo, make a change, submit a pull request, delete your branch and pull from upstream’ is well known. Github, gitlab, slightly different but similar.But what I don’t see is… what about the case where I have many pull requests in flight, and I want to have my fork be the one I use. Eventually my changes hit upstream, but I want them now.
E.g. some project ‘AlmostGreat’ exists. I see that if me and my team were to make a few small tweaks AlmostGreat would become great. We have a need for great now, and the maintainers of AlmostGreat are busy so they take our pull requests slowly, intermingled with others.
So we end up with a timeline of:
(repo AlmostGreat) master————————–>
And I do a fork:
(repo BecomingGreat) master————->
with branches “fix1”, “fix2”, …
My team finishes fix1. They submit a pull request, but, then, in the meantime, what do we do?
If we merge to our own master, then we have timeline and clean patch issues.
If we create our own ‘integration’ branch, we get history rewritten when we do pull from upstream.
Does anyone have a pointer to an AlmostGreat writeup on the gitflow for this? Where you will maintain a fork of something for perhaps indefinitely, but you do want to cleanly push your changes up, and cleanly get them back again without merge hell.
A) I want to share it w/ my org, but not yet upstream. I merge don/feature1 -> don/master
B) I want to share it w/ the world, and also my org. I submit PR to upstream of don/feature1 -> upstream/master, but also do a merge of don/feature1 -> don/master
In B), if they lag by months and then ask for material changes, I’ve already merged into don/master, do I keep don/feature1 around, keep making the changes on there, until they accept? And then merge upstream/master into don/master (even tho I merged don/feature1 into don/master already)?
Leave a Reply