1

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?

Joyce Babu
  • 19,602
  • 13
  • 62
  • 97

4 Answers4

2

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/.

kauppi
  • 16,966
  • 4
  • 28
  • 19
1

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".

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • Thanks VonC. As I mentioned, currently we don't even have a dev branch. Every day, we push latest changes to the master branch, even if they are not stable. I know what we are currently doing is the worst use of git. – Joyce Babu Aug 11 '11 at 06:15
  • If we move the development to a new dev branch, it won't be stable enough to merge with master. – Joyce Babu Aug 11 '11 at 06:17
  • 1
    @Joyce: not the worse, but the idea of a dev branch is to allow master to be the exact image of the live web site at all time. You only merge dev when you have a stable point (which you can tag), while going on with further devs. – VonC Aug 11 '11 at 06:17
  • I have a doubt regarding the model you suggested. Programmer 1 is working on Section A and programmer 2 is working on Section B. Both are working on dev branch. When section A is ready for production, won't the dev branch have a stable Section A and unstable Section B? So when I merge it with master, should I cherry pick only changes related to Section A? – Joyce Babu Aug 11 '11 at 06:23
  • 1
    @Joyce: if you have separate features, then yes, you need separate branches, and each branch needs to be rebase first on top of master, before any merge (to be sure to include the latest modifications) – VonC Aug 11 '11 at 06:35
1

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.

Karl Bielefeldt
  • 47,314
  • 10
  • 60
  • 94
  • Thanks Karl. But the main issue here is that the master branch rarely gets stable. When one section is stable, another section might be unstable. Each section is uploaded to production server, as and when they get stable enough. Since changes to each section is normally independent, is it a good practice to create separate branch for each section? – Joyce Babu Aug 11 '11 at 06:37
  • Nothing wrong with using as many branches as you need, but I would still merge them into master just before deploying, so you know what combination of sections are in place at any given time. – Karl Bielefeldt Aug 11 '11 at 14:23
0

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?

Community
  • 1
  • 1
Michael Dillon
  • 31,973
  • 6
  • 70
  • 106