You can also evolve, basically, to each model in the order that they appear in the article.
As an example: I've been working on a new spike for the past 2 weeks with one other developer. Maybe 10 times a day we'll need something that the other person has committed, so we work against one branch (master). The workflow suits this extremely rapid iteration.
One repo has now matured to the point where developer branches make sense. We created "develop" on it as well as our own branches off that. We're not close to a v0.1 yet - but we'll be evolving to git flow the minute we want to ship.
Eventually as more devs join, we'll need the full-blown PR workflow, that also naturally stems from its predecessor.
There's a "meta-workflow" here, which implies which workflow to use.
There are many people in this conversation describing then as the Savior of comments for commits, as it not using them is a disservice to the team. I'm not much of a coder myself, but the suffering opinions are interesting.
As an example: I've been working on a new spike for the past 2 weeks with one other developer. Maybe 10 times a day we'll need something that the other person has committed, so we work against one branch (master). The workflow suits this extremely rapid iteration.
One repo has now matured to the point where developer branches make sense. We created "develop" on it as well as our own branches off that. We're not close to a v0.1 yet - but we'll be evolving to git flow the minute we want to ship.
Eventually as more devs join, we'll need the full-blown PR workflow, that also naturally stems from its predecessor.
There's a "meta-workflow" here, which implies which workflow to use.