I won't say any of this is hot, new information. This is my attempt to document the use of the subtree merge strategy/workflow in a way that would have helped me in figuring it out. While most of the information was out there, my best understanding came from working through multiple sources.
If anyone sees where I have something wrong, I would love to know so I can correct it. I do NOT want to be propagating bad information.
There is a real basic walk through for folks who are not deeply experienced with Git, and also a link to more of a reference for those who are more fluent and need less of the narrative/screenshots.
As always, feedback is appreciated.
Really useful info, I know of at least one open source and one proprietary software project both of which could put this to great use. It it certainly less documented than the submodule workflow. And I find 50% of the joy of git come from switching to it, the rest from learning to use it to do cool stuff. The first time I used git bisect it made my day, no my week!
Totally agree about 50% of the joy coming from learning to use git. Frustrating at times, but in the end, that's the kind of thing that keeps me learning to code!
If I understand correctly, the subtree workflow is a (relatively) newer thing, and there is an actual subtree command either newly added or soon-to-be added which simplifies things a little further.
I decided to learn the old, hard way before I started exploring the subtree command itself (prior to the addition of the command, my understanding is that "subtree" represented a merge strategy, from which evolved the subtree "workflow" and out of which a git contributor evolved a "command," which appears to have been added to git 1.7.11: