Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm trying to come up with a personal workflow. I've put together a flowchart of the hypothetical lifespan of a release: one developer pushing to a public github repo + a friend helping with some feature and fixing a bug.

Is this a reasonable approach to version control?

The main idea is to keep the public repo tidy:

  • Each new release gets on its own branch until it's finally tagged in the master branch when it's finished.

  • All work is done on "feature" or "hotfix" branches, never on an actual release branch, to prevent anomalies.

  • Merges to higher-level branches are always rebased or squashed (to avoid clutter).

If it's overkill I don't mind because the whole point is for me is to learn skills I might need for a larger project. The only problem would be if I'm doing something flat out wrong or unnecessary.

edit 2: fixed bad idea in the original flowchart and made it a bit easier to navigate.


share|improve this question
+1 OMG! - Beautiful! – ClintNash Aug 25 '12 at 5:53
@ClintNash Thanks! I updated the image to fix the --squash mistake and added a grid to make it easier to follow. – iDontKnowBetter Aug 26 '12 at 5:29
"Merges to higher-level branches are always rebased or squashed (to avoid clutter)." Sometimes I feel this adds more clutter, since the history doesn't match what really happened. – Matsemann Aug 26 '12 at 11:12
check this out – Andre Dublin Aug 26 '12 at 21:37
I think my brain just exploded O.O – Zaz Jul 6 '14 at 18:13

What I see a lot in the git/github community is this

branches master develop

You and contributors work primarily in develop, but someone may have an idea or new feature, so you create a topic branch like git checkout -b user_comments.

Then as you progress through the development you push to master once you git a version you are happy with and tag that in the master branch as 1.0 or 1.1.2 etc ( look up semantic versioning )

share|improve this answer
I was not aware of proper semantic versioning. I mus admit up until today I've been numbering things without any real method to it. I'll start using it from now on. Thanks for the tip! -- website: – iDontKnowBetter Aug 25 '12 at 6:21

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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