Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question
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 '12 at 10:11
10  
@Euphoric depends on your tooling and workflow. –  user1249 Jun 18 '12 at 10:50
2  
@ONOZ please describe your current way of working in more detail. –  user1249 Jun 18 '12 at 10:56
21  
@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 '12 at 13:16
7  
@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 '12 at 14:25

4 Answers 4

up vote 8 down vote accepted

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.

share|improve this answer
    
If you're in a consulting or enterprise situation, you may also want to have a branch for UAT. –  John MacIntyre Jun 18 '12 at 14:18
    
Agree, i am using this work flow. –  Cheung Tat Ming Sep 12 '13 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 16 hours ago
    
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 15 hours ago

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.

share|improve this answer
    
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 '13 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 '13 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 '13 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.

share|improve this answer
    
I've also used this to create branching models in the past few years. It's a fantastic model. –  John MacIntyre Jun 18 '12 at 14:20
    
Thumbs up for the link –  Rahul Gautam Aug 2 '13 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.

share|improve this answer
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 '12 at 10:10

Your Answer

 
discard

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.