Yes, more or less a new branch for each fix. But with git and Kiln, it's really not a drag at all; the merges are generally really easy and mostly performed by our release manager when the card makes it to 'Ready to Merge'.
Do I understand correctly that your stable 'master' branch is always ready for release? Basically it means that changes (fixes) should be relatively small, otherwise they are released via channels, correct?
Everyone runs dev environments locally and tests. A dev environment is really easy to set up with mongo and node. Occasionally, we’ll put stuff on a staging environment if we want to test a database or infrastructure change. Big, experimental client changes go to the alpha channel on production.
So when you have 2 features/bug fixes in the same area, built in 2 different branches and deployed to isolated dev/test environments... the first time you might find out that they dont work well with each other is in Staging? Why wait for that when you could deploy to a common environment and catch issues sooner?
Btw... I am trying to get some teams in my company to get out of branching. So trying to understand your view (which is exactly what these teams are doing), hence these questions...
That rarely happens in our experience. With our internal board, we know who is working on what and in what area of the code. Plus, all code is reviewed by someone working in the same area.