On Mon, Oct 21, 2013 at 2:57 PM, Daryle Walker
Since a project that’s made of a bunch of sub-repositories that’s later merged is (AFAIK) unusual, I don’t think the writer of gitflow had it in mind.
Gitflow is about managing the flow of work through the branches of a project. Why would it matter if that project is included in another project as a sub-module? Or included in 100 projects as a sub-module, for that matter?
I’m guessing that each sub-repository independently uses gitflow. When it’s shipping time, the release-merge script grabs from the “master” branch of each sub-repository. Of course, this doesn’t cover multiple libraries that have to work together or what happens when fixing is necessary (probably due to cross-library problems).
I'm guessing something similar to your guesses, but I was hoping to get a response from someone who had actually used Gitflow in a submodule environment.
And do the test runners work off “develop,” “master,” “release,” or does it shift depending where we are in the release cycle?
That's a whole topic in of itself, and may have different answers for the short term and the long term. I don't want to waste CPU cycles on that until the basic local machine docs are further along. --Beman