Simple Git branching model for website

Can someone suggest a simple git branching mode for website development. I have seen several discussions on successful git branching models, unfortunately they are all very开发者_运维百科 complicated for our case. Most of the branching models are suited for softwares with versions and release cycles.

Our company manages several web portals. We have 5 people working on these sites. Most of the time 2-3 people might be working on the same websites, but on different sections (chances of conflict are near zero). We don't have any versions or release cycles. A programmer will develop a particular section, after which it will be passed to another person, who will write content for the section and perform SEO. Once it is done, the section will be uploaded to the public website. In the mean time, another programmer might be working on updating an existing section. If a bug or error is reported, it will be fixed and uploaded immediately.

Usually, every week 2-3 new sections are added / updated.

Currently we have only one branch (master) and create a new branch only if the person is working on big change which will take more than 2 weeks to complete. The problem here is that the master branch is not in sync with the current production files. I would like to change this and move the development to another branch, so that bug fixes can be directly applied on the master branch without any worry.

Update Is it bad to create a separate branch for each section? In other words, how much branching is considered too much?

It sounds to me that what you really need is to refine your working model and process. Git is not an answer to process problems, it is just a tool that should support your chosen process.

Even though you claim that you don't have release cycles, you still have releases: at least the running copy in production should be considered a release/version. Nothing prevents you from producing 10 releases a week if it is acceptable from QA/testing point of view.

Some points for a thought:

• The production site must always have 1:1 clone in a branch (be it master, release or whatever)
• The "release" running in production site should always have a tag in version control for tracking purposes.

For what it is worth, I think that you describe a model like this: http://nvie.com/posts/a-successful-git-branching-model/.

You have a fairly sequential development cycle, so you are right: no need for tons of feature branches there.

A simple model:

*--*--*--*---*   (master, for prod)
    \       /
     *--*--*--* (dev, for current development)

The question is:

When there is a bug in prod ('master', the live website), can you fix it on dev branch and include whatever development is in progress?

Because if you can't, that mean you have changes on master must be merged back immediately on dev. If that fix is quickly done, you don't even need a 'fix' branch.

In other word, you don't need all the sophisticated model of "A successful Git branching model".

You say you only create branches for changes longer than two weeks, but technically every developer's local copy is a separate branch, especially with a DVCS like git. I'm guessing your official master branch doesn't match what's in production because you are using that branch to share changes between the programmer and the content creator. What I would do in your situation with such a short release cycle is have those two collaborators share their local repositories with each other, completely skipping the central repository until it has been tested and is ready to push to production. That way you automatically have as many development branches as you need and your official central repository remains clean.

If that's too much of a departure for your group, you can always create a production branch that receives only bug fixes directly, and merge over the master branch whenever it's at a stable point to push into production. That way your developers are still mostly working out of the central master branch as they are accustomed.

If complexity is a problem for you, then have a look at Mercurial as a GIT replacement.

GIT and Mercurial use an equivalent distributed VCS model, however Mercurial tends to be easier to use and does not expose as much of the underlying complexity to the user.

Have a look at the answers to this question What is the Difference Between Mercurial and Git?