What would be the easiest way to use git correctly in a small team of about 5 developers, with one server running the live application?

  • 5
    I would question using git in this case. There is no advantage for using decentralised source control, when you have all people in one room with one dedicated server. And there is still overhead of pulling/pushing on top of commits.
    – Euphoric
    Jun 18, 2012 at 10:11
  • 10
    @Euphoric depends on your tooling and workflow.
    – user1249
    Jun 18, 2012 at 10:50
  • 3
    @ONOZ please describe your current way of working in more detail.
    – user1249
    Jun 18, 2012 at 10:56
  • 22
    @Euphoric - What an incredibly narrow minded attitude. For the ease of branching and merging alone git or hg beats most centralised VCSs. I can understand people getting annoyed at people constantly harping on about how great DVCSs are, but burying your head in the sand and refusing to acknowledge that you can develop different and possibly more efficient workflows with DVCS than without one is just as bad.
    – Mark Booth
    Jun 18, 2012 at 13:16
  • 8
    @Euphoric, using Git doesn't mean your source control is "decentralised". I work in a small team, and we use Git, and we still have a central repository. That's what you push to. Using a DVCS doesn't usually mean every person is pulling from every other person with no central point.
    – Kyralessa
    Jun 18, 2012 at 14:25

4 Answers 4


I suggest you to create some branch:

  • production
  • master
  • local

Production branch is "live" branch. Is the application in use right now.

When an update is needed, a developer can pull master branch into local branch. Than, can start to code. At the end, just pull and push from developer local branch to master. A Project manager can take a look in master branch. Test it. And when ready, can merge production with master. And now you'll have new software.

  • If you're in a consulting or enterprise situation, you may also want to have a branch for UAT. Jun 18, 2012 at 14:18
  • Agree, i am using this work flow.
    – Cheung
    Sep 12, 2013 at 2:31
  • Could you elaborate on why the difference between a local and master branch? I can see why you would want to have a working production version, but when you pull/push changes it will automatically merge even without a local branch right?
    – Luc
    Oct 21, 2014 at 20:21
  • 1
    Because of local branch can be named as XXX-feature-name, thus, you have master branch as merge of all feature branch you want in production. Yes: because some feature may not be included.
    – sensorario
    Oct 21, 2014 at 21:18

Start simple and build up to a more complex workflow as and when you need to.

Whatever you do, don't let A successful Git branching model be the first thing people see, it will only confuse and overwhelm them. Look at this later when you have more experience.

I would suggest that you start with a central git repository and have everyone, including your production and test builds clone from that.

Within your git repository, create a production branch and a test branch.

Developers should work in their own local or remote feature branches until they are completed and merged into master. From here they can be merged into the test branch for deployment into the test environment and when they pass the tests they can be merged into the production branch.

That way you can always see what is new and untested, what is tested but not yet deployed into production and what is actually in production.

  • Interesting opinion, I would consider the git branching model to be a deal breaker for git, on the other hand it might not be so obvious to non-git users.
    – wirrbel
    Jul 29, 2013 at 18:56
  • @wirrbel There is no such things as the git branching model, you can implement whatever branching model you desire using git to fit your workflow. The one I suggest here is simple and is likely to be better for inexperienced git users than A successful Git branching model but AsGbm is likely to be better for more experienced git users, but isn't so suitable for some teams (people wanting to maintain multiple release branches for instance). As I said though, the problem with AsGbm is that it can look overly complicated.
    – Mark Booth
    Jul 30, 2013 at 10:09
  • I see your point. Just for me, I started with AsGbm (or rather adapted it to my needs). It was perfect since I could see how git could be used differently than svn
    – wirrbel
    Jul 30, 2013 at 18:52

We've got a similar situation -- except we have dozens of web apps not one. We've been successfully using A successful Git branching model for the last year or so with no significant complaints.

  • I've also used this to create branching models in the past few years. It's a fantastic model. Jun 18, 2012 at 14:20
  • Thumbs up for the link Aug 2, 2013 at 7:16

You must have one master repository on integration server and each developer must clone it. After it just do pull and push. Develop new big features in separate branch. No rocket science here. On live server - you also must clone master repository. And it's good practice to have branch like "live" for it.

  • 2
    git archive is another option for deploying on the live server on the assumption that you don't actually want to directly edit stuff on the live server
    – jk.
    Jun 18, 2012 at 10:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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