Hi,
Gregory Casamento wrote:
Here is a link, for reference:
https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow
Some might argue that this should only be done with large teams, but I
used this process on a small team when I worked at a company known as
customink where we only had 4 people and it still helped things go
very smoothly.
This is the process I've been trying to adhere to. I would advocate
that, if PRs could have prevented this then, perhaps, we should all
move to it. I had a discussion with Riccardo where he thought this
process was too much and was silly and that merging to the master
branch directly is always the best way to go. That's precisely what
caused this. We can make all of the arguments that "a focused
developer wouldn't make these mistakes" but that's BS. Process is
here to prevent mistakes or to mitigate them.
Git Flow Workflow - Release Branches
Actually... I might revise what I previsouly said, also because while
discussing thigns with Fred and Gregory, I propose essentially the same
model, with two "amendments"
1) some minor stuff can also be done directly in "develop" instead of
Master (e.g. to follow Richard's flow, to avoid having too many branches)
2) to have us all developers essentially build and compile "develop"
which becomes the equivalent of our current trunk
Trunk thus becomes the "stable". If we all live on the violet branch, it
means that we continue checking stuff. Thus, still keep the mantra that
"Develop" should not break, although it is not as bad as "Trunk"
What do you think?
Riccardo
