I was going to post to say that using Git as a source control tools and using branching for managing work in a team are very different things, but I can see that everyone's already jumped in on this one. No surprise, that people have different firmly held beliefs too. Best we stay away from subtleties like whether to squash merge commits!
A lot of it does depend on how you team works, so I don't think there is a definitive right or wrong with branching strategy. No direct commits to master is probably a fairly consistent approach, although as I have found myself on a one-man team at the moment I find I sometimes bend (OK - blatantly break) this rule.
One thing I'm really appreciating in my current job is that I got a chance to set Continuous Delivery up right from the start. If code in master passes unit tests, it's automatically deployed to AWS.
I was going to post to say that using Git as a source control tools and using branching for managing work in a team are very different things, but I can see that everyone's already jumped in on this one. No surprise, that people have different firmly held beliefs too. Best we stay away from subtleties like whether to squash merge commits!
A lot of it does depend on how you team works, so I don't think there is a definitive right or wrong with branching strategy. No direct commits to master is probably a fairly consistent approach, although as I have found myself on a one-man team at the moment I find I sometimes bend (OK - blatantly break) this rule.
One thing I'm really appreciating in my current job is that I got a chance to set Continuous Delivery up right from the start. If code in master passes unit tests, it's automatically deployed to AWS.
