3 ms·

Agreed. In my teams, I've always implemented a simple model, which hasn't failed me. Main branch triggers deployment, and name rest of the branches <author>/<fe

• rewmie 3y ago
  > Agreed. In my teams, I've always implemented a simple model, which hasn't failed me. Main branch triggers deployment, and name rest of the branches <author>/<feature>. Just works. So you work with a small team that does not need to put together releases nor does have quality assurance engineers verifying your code before it's released. That's perfectly fine. Your team also has the luxury of pausing any additional development work while lining up a release. That's cool too. Perhaps you don't even have releases, and just continuously integrate everything you throw at it to deploy it somewhere and rely on a multi-stage pipeline to catch problems. That's fine. That's also not the usecase for gitflow. I don't think it's a good idea to project your team's needs to absolutes, and pretend that just because you don't benefit from a process it means none do.
  • atomicnature 3y ago
    You are making too many assumptions in the answer there; most of the things you assume about me, my team or experience are not correct :) I do think the gitflow model is over-complicated.