3

I am trying to find a way to organize the branches in my repository in a sensible way. I would like the main branch to contain only "clean" commits: features that are (mostly) complete, no superfluous code that has no role in the current version of the application, etc.

I thought that for each feature I should have a separate development branch, and once that feature is complete, it should be merged into the main branch.

It this a valid way to organize your repository? Can you recommend a good naming scheme for the development branches? What other ways to organize your repo can you recommend?

closed as too broad by gnat, user40980, jwenting, Kilian Foth, GlenH7 Aug 14 '14 at 15:31

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

5

I would model something off of Vincent Driessen's Git branching model.

http://nvie.com/posts/a-successful-git-branching-model/

There are plugins for git and mercurial. Bitbucket's program source tree even has the mercurial version build in.

The main idea is that you have separate "swim lanes" for different parts of the development phase. You have one for your main, one for testing, and one for development.

For development there can be a new branch for each new feature that gets added to the product. Once complete and the code passed local testing it can be moved into the testing branch and the feature can be closed. Each feature starts with the main feature branch.

The testing branch is the only branch that should be merged into the main branch. The goal is that every feature is merged into testing and tested before being merged into the main branch.

The goal of the main branch is that it is always release ready. This means that you can deploy from it at any time. Additionally you can then have a separate branch off of the main branch to address any quick fixes if issues are discovered in production. (Read: not major issues.) i.e. typos and such.

The main problem with this model is that there is a lot of merging that happens. In most cases there should only be clean merges though it can still look confusing on a graph. I tend to like this model however because it keeps an always "clean" branch and its not too difficult to use and convert a project to using.

Take a look at the plugin for mercurial, hgflow: https://bitbucket.org/yujiewu/hgflow/wiki/Home

Or if you prefer git-flow: http://scottchacon.com/2011/08/31/github-flow.html

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