This question already has an answer here:
We have very frequent releases and we use Git for version control. When i am mentioning about frequency, please assume it to include bug-fixes and feature release too. All releases are eventually merged into ‘mainline’. When a release is deployed on production and if a bug is identified, people start fixing the bug on the same branch from which the latest release was deployed on production. They do not create a new bug-fix branch for the same. I feel that’s not the right way to go for. There are several components and each component has a different owner, and thus, different perspective. Though I have not initiated talks with them, I am sure there will be a lot of resistance. Main issue that they might cite would be, “There’s a lot of work involved in creating and tracking branches especially when there are so frequent deployments on production. This will consume a lot of dev effort.”
Do you think that fixing bug on the same branch from which release was done, a good idea? If yes, how do you manage it? Using tags?
I know that best practices may not always be applicable due to several factors but still I would like to know what might be a good approach for branching in a scenario where releases/bug-fixes happen almost on a daily basis.
Edit: Thanks everyone for sharing your views and for the useful links. I think the main concern i have here is this: Do you think that fixing bug on the same branch from which release was done, a good idea? Is this approach fine in the long run or are we messing up things just to realize it later?