Separated branch for each bugfix vs graft from dev branch

Question

I have a application with 3 environments - dev, stage and production. I have a lot of features/bugfixes that have to be independently deployed to stage and production.

The bugfixes and features have usually 2/3 commits.

Currently I use mercurial for my project, but I can't decide which way to go. The best it should be to use named branches, but I don't know it is right for 1/2/3 commits within. I found that grafts look also promising.

So my question is how to version files if I need to be able deploy changes separately?

Answer 1

You can use any Mercurial branching model (named|anonymous branches, bookmarks, clones) - it's more question of tastes and habits and tasks - with named branches you'll be able easy in future (if|when needed) detect part of history of repo, related to every completed|WIP job (just because unique branch-name is permanent metadata in every changeset, contrary to anonymous /share the same name as parent/ branch or bookmark-driven /history is mixed in common branch with other changes/ fork of history).

Single drawback of intensive usage of named branches is long output of hg branches after some time. I prefer to use named branches just because it give recoverable history of changes and more polished log: instead of repeating changes with grafted changeset I see one merge for each integration of finished task and graph of repository show all merge-targets

Answer 2

You should only be deploying to production from the "master" or primary branch. Each bug fix/feature is usually its own branch so that you can verify the behavior independently without affecting the master branch. Once a fix is confirmed, or a feature is complete, it should be merged back into the master branch. In this sense, you should be using graft, whose purpose is to cherry-pick accepted changes from the alternate branch (i.e. your bug fix branch) back into the master branch for deployment. You can't use grafting without branching, and branching is the most appropriate way to test changes to a source code repository so you don't clutter the master branch with meaningless or false commits. Your master branch should be able to be deployed at any time and still function correctly.