Git is Scary – But it doesn't need to be!
News , Tools of the Trade , Version Control 1 Comment »I watched two Git preso over the last week by CF folks. They both tried really hard to make Git sound better than SVN, and easier to use.
But looking at their preso, if I was a newbie to source code management, I'd be scared. All that Git bash stuff is a nightmare!
Git isn't perfect, nor is it well suited for web development. But it also doesn't need to be scary.
As a long time SVN (and previously CVS) user, I moved to Git for all development earlier this year, but this was after watching preso and researching Git for years! And I found one common thread, it does better merging, but it can also be scary. Why? There aren't any good tools!
Earlier this year, the great folks at syntevo GmbH launched SmartGit, and it made Git sooooo much easier to use and manage. This is what made the switch from SVN (for which they have a killer tool called SmartSVN) so much easier, and really did it for me.
Maybe someday someone will create a version control tools best suited for web development, without the confusing terminology that Git and SVN has, but for now, we've found a great combo that works.
Each developer has his own branch in which he works, then we have a dev branch, a staging branch, a UAT branch, and a prod/master branch. Developers commit code in their branch on a daily basis. When they feel ready they merge in (which is very easy with SmartGit) their changes to the Dev branch. As other developers have also been committing code to the dev branch, they also merge out their changes from dev back into their branch, so that they have the latest changes. The dev branch is where intergrations testing can occur, all developers code meets up, and we do our own testing on the dev box. Once we're good, we merge from dev to stage, where QA does their testing on the staging server. And then when tickets are passed, then we merge from stage to UAT, which is on the same environment externally as prod. If we need to show off any code to customers early, we can do that here, and we also make sure the code runs OK in prod. And finally, when code has passed UAT testing, then we merge to MASTER, and push the update to the servers on the next launch. Works well for us.
Developers may also create their own experimental branches on the fly. I have one right now for testing our move from Verity to Solr, for example.
The only problem with this model is that you have to be careful when pushing up, as you can push up code that hasn't been fully passed. So you can cherry pick commits, or just be careful. This is where the "art" of source control comes in, there is no exact science, its all what works best for your team.
My greatest wish for source control would be if you could tag a commit as being at a specific level only. So if you commit code, and say this is, for example, "dev" only, any merge from dev to stage would ignore that code, until the ticket associated with that code passes on dev, and then it'll move up. This would make merges soooo much easier, and you could be sure your code will never make it to prod unless its passed at that level by QA. Anyways, wishful thinking.
Oh, and Git integration into Eclipse is half-baked, so much so its useless for me. I always have SmartGit and CFBuilder open side by side. Good thing is that SmartGit runs on most platforms!
 |  |
8-19-2010
8-9-2010
8-5-2010
8-5-2010
7-13-2010