Web Software Architecture and Engineering – Life on the Bleeding Edge

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!


Comments on: "Git is Scary – But it doesn’t need to be!" (3)

  1. We’re currently on CVS and planning on moving to either SVN or Git. I’ve used CVS for so long that I’m most comfortable with the centralized master copy model that CVS and SVN use, and it’s been hard for me to wrap my head around how Git works. This is the clearest explanation that I’ve found thus far. Thanks.

  2. As someone who hasn’t researched Git for years, I’m astonished at how frightfully opaque even SmartGit turned out to be. Naturally, the first thing I wanted to do was “git somethin” from a repository. In response to clicking on reasonable things like “Pull”, I was told I have to edit a .get config file. Lame, but lamer still, those files are hidden by default. Not hidden, are the configs of the mammoth assortment of unix batch, exe, perl, tcl, script and cgi programs that had to be installed separately. After perusing man? files in notepad for awhile, I googled up a clue: “clone”… which makes perfect sense; because I only wanted to download a couple of old files, but by injecting windows with genetic material from unix, a complexity emerges with which Tortoise pampered specimens like myself are ill adapted.

  3. James,

    I have no idea what you are talking about. Everything is wizard driven, you just create a new project, select a folder, and enter the repo info and it will clone everything for you. Looks like you need to read up on Git. You never need to edit hidden files.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: