Guys,
I must say this. I have been trying to, in general, hold myself to doing this rather formally up until recently. I admit that I have been more directly pushing things in as of late.
Since, as you say, this could have been avoided by doing PRs... which it could have. Should we not, as an project, move to this model? It's known as gitflow and it's what I was following when I would create a branch with large changes and then have it reviewed by yourself and others before merging. This would slow some development down, but it would have the effect of keeping master in a condition where it always builds and is always releasable (which should always be the case).
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.
I disagree with Riccardo's position wholeheartedly. A more controlled and disciplined approach should be adopted and we should stick to it.
Any thoughts?
Yours, GC
|
|
Sender notified by Mailtrack 11/14/19, 11:23:51 PM |