Rethinking Git Workflow
Closed this issue · 3 comments
We are going live this Monday. So with production code that continuously integrated, it creates a dilemma that a not well tested code, but a reasonable looking one, can kill production server, and make people unable to take surveys, or a bad merge of good code can make the service unusable.
Currently, we are using number 2. Git Feature Branch Workflow in the following article.
https://zepel.io/blog/5-git-workflows-to-improve-development/
We could continue with 2, but be extra-careful in forcing every merge have a loom to demonstrate functionality before pull-request is approved (for major feature changes). We could go with 3, which will maintain our development speed, but have additional layer of protection (review) before committing to master (in this way only several features get committed to master at once).
I think 4 is bit overkill for our purposes.
Sure. I'm fine with 3, however, I'd usually do it as everyone PRs to main then we have a prod branch that requires extra testing etc, but that's just because of what I've used in the past, and because I think it makes most PRing simpler (people don't need to know details of the prod cycle and will probably default to PRing onto the right branch). That said, I'm happy to go with any option here.
I like that. Let's have prod branch that gets deployed.
Sounds good. I've set you up with privileges to make any adjustments around commit rules etc.