Slashdot Mirror
Guide For Small Team Programming?
dm writes "I run a small design shop and have been doing more and more web development, including fairly involved back-end programming of what's now essentially become our own CMS. Up to now I've been doing all the programming myself. Now we are working with a second programmer for the first time. I already use version control (SVN) and an issue-tracking system, and I guess we are both decent at what we do — although self-taught, but we both lack experience programming in a team context. Is there a useful guide for this? Most of the tutorials I have seen for Subversion are surprisingly organized from a single coder's perspective. Where else should I look?"
I agree, I've found git to be an absolute joy for any project I can use it on. In fact, it's so easy to setup a repository (mkdir project && cd project && git init), the excuse I used to use for one-man jobs not being maintained in Subversion ("Too much work to setup a repository") effectively disappeared. This even makes it trivial for other people to join latter on, as you don't need to worry about setting up a repository filled with files that apparently were created from magic (aka, not version controlled in the past). Hell, the lack of centralisation even eliminates the question I, and probably others, had with Subversion, on whether I should put the server on my laptop (expecting only me to use it, latter causing moving issues when others need a repo), or on a more permanent computer (cutting me off from my own repo when I'm on a plane/bus). There's no question to ask, just create it, and have others clone when needed, and they have the full history to play with as well.
Though perhaps the biggest advantage I've found with git, is that branching+merging is a breeze and feels natural. It's so quick, users of CVS/SVN might even wonder if git did anything at all (I did at first). Indeed it did, and has none of the CVS or SVN merging headaches.
Git solves this problem in two ways.
;)
First, it doesn't automatically upload every commit. (In my experience, this also promotes developer review of their own patches before submission, but at the very least, it gives you time to say "oh crap!")
Second, it's very easy to rearrange your commits (easy branching and whatnot) when you realise you've made the mistake.
Upstream needs never know!