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?

  • Also, there are quite a few questions here. And some of it is reasonably subjective; yes, there are best practices, but there's also what's reasonable for teams to accomplish - which may depend on project size, team size, development style (agile, waterfall, etc), or a bunch of other factors. Jun 13, 2014 at 15:05
  • 1
    Do you have a separate "development branch"? Or do you work in "feature branches"?
    – Doc Brown
    Jun 13, 2014 at 15:09
  • @DocBrown: Thanks for sharing your thoughts below. Developers create dev branches and prefix 'dev-' for all such branches. Dev branch creation is handled by developers themselves. They do not have feature branch concept here. When work is completed on dev branch, we receive request from dev to create a release branch for the same.
    – Technext
    Jun 14, 2014 at 17:34
  • @Technext "Do you think that fixing bug on the same branch from which release was done, a good idea?" - how does the bug fix get back into the mainline?
    – user40980
    Jun 14, 2014 at 17:58
  • When the testing (going through release and staging env.) on the branch on which bug-fix is done is completed, then the branch is merged into mainline. This merge process is automated.
    – Technext
    Jun 14, 2014 at 18:27

2 Answers 2


The important thing here is to have a consistent workflow which can be easily followed by both newbies and veterans in your organizations. Decide on a process which meets your requirements and ensure that the workflow makes sense for both trivial and more complex changes.

That said, there are a few standard workflows out there. Here's a few of them:

GitHub Flow

GitHub Flow is a lightweight, branch-based workflow that supports teams and projects where deployments are made regularly. Scott Chacon explains the differences from Git Flow here.

So, why don’t we use git-flow at GitHub? Well, the main issue is that we deploy all the time. The git-flow process is designed largely around the “release”. We don’t really have “releases” because we deploy to production every day – often several times a day.

This site provides a great visual walkthrough for the GitHub Flow.

Git Flow

Git Flow

Git Flow defines a strict branching model designed around the project release. This provides a robust framework for managing larger projects. It defines specific branches for release, development, hot-fixes, etc. and the transitions between them.

There are a number of git extensions and tools available online to help support this workflow. Take a look at the nvie/gitflow extension for a starting point.

You can get a detailed explanation of the various stages and roles in the workflow here and here.

  • Thanks for sharing your views! I already read the famous post by Vincent (nvie) earlier and it's a good approach. :) Looks like i'll have to rephrase my question for the exact concern i have.
    – Technext
    Jun 14, 2014 at 17:40

Reintegrating several times a day into the mainline is a fully valid strategy - it has indeed a name, it is called continuous integration. If this is a good strategy for your team or not depends mainly on how well your automatic tools for quality assurance are, and if your team is used to deliver "baby steps". To apply CI with sucess, you should have an automatic build server running, a lot of automatic unit and integration test and ideally something like a (semi)automatic way of deploying (which includes versioning and tagging).

If that's not the case, it is probably better to apply a more conservative model and to work with different branches, giving you the chance of collecting features and bug fixes in separate places before the final decision is made if the a specific change will be integrated into the mainline (or not).

It is of course possible to combine these strategies. For example, let the CI server deal with the mainline, from which your software is delivered. Develop every "new feature" in a development branch or separate feature branches. The latter are reintegrated into the mainline when they have reached a certain quality. Urgent bugfixes go directly into the mainline (and soon delivered from there) - because they are urgent. The feature branches prevent your team of bringing half-baked features into the mainline (and so unintentionally into production because of an urgent bug-fix delivery). Changes from the mainline should be at least once a day be reintegrated into all feature branches.

Other, more sophisticated models are possible, depending on the number of stakeholders involved (for example, do you have a QA team? How do they work? Which state of the software will they test?). What you have to do is to think about your environment and which model suits you best - what goals you have, what problems you see with the current model, and what you want to improve.

Not the answer you're looking for? Browse other questions tagged or ask your own question.