Source Code Management with Git: Basics for Product Development Managers
The source control management (SCM) system Git has gained a major foothold in the software developer community in recent years. Our consultants have been getting an increasing number of questions about Git from managers at various levels in Polarion’s customer companies. For this article, we caught Polarion consultant Lutz Dornbush between roll-out visits to customer sites, and asked him for a quick overview of the most important things for managers to understand about Git.
Editor: What is Git, and what sets it apart from other SCM products?
Lutz: Git is a decentralized version control system. This means you do not need a central server to work with it. Each user holds the whole data locally and can share code and changes with other users. It’s a bit like peer-to-peer networking.
Editor: Is Git better suited to some kinds of development than others – embedded software, or something like that?
Lutz:Git is very flexible in many ways, especially if you are working on open source code (like custom kernel development). You can easily integrate other open source repositories and keep your project and dependencies up to date. Or you can stick to an old version and backport new changes, or use a mixed approach. The possibilities are endless.
However, due to its open nature Git is not that well suited for projects that are proprietary, or need restricted access for other reasons. Git has no visibility or authorization mechanisms, so even external developers are getting access to the whole repository. If you need to protect your IP and you need a lot of external developers, you need to plan accordingly, mainly by structuring your projects based on your security needs.
Also, Git is not designed to work with binaries, as it lacks a central locking feature. So storing binary files is usually not advisable.
Editor: What is most important for a development manager to know about Git, assuming his or her teams aren’t already using it?
Lutz: The learning curve is steeper than Subversion (the current SCM market leader – ed.). To unleash the power of Git you need to master more commands, but not that many more. Also, you should evaluate the disadvantages (read/write permissions, binary objects, no empty directories) and decide about how you want to circumvent them.
Also, you need quite a plan (a.k.a. “Branching Strategy”) for how you want to work, because otherwise you cannot train your developers accordingly. Git doesn’t set up any structure of repositories. Instead, it gives every user a powerful toolset to modify their own Repository in virtually every possibility, and to share these changes.
One possible Git branching strategy
Editor: What should our Polarion customers know about Git if a team in their organization says they want to use it to run a new project?
Lutz: It’s no problem to use Git to manage source code and Polarion to manage Requirements, traceability, compliance, etc. You just specify the URL of your Git repository in the External Repositories page of your project Administration. You can do the same for external SVN repositories. Polarion then monitors Git, and automatically links revisions with Polarion Work Items, provided your developers include the relevant Work Item ID(s) in their log message. This means you can manage source code in one ore more external Git and/or SVN repos. It does not make any difference in using Polarion. It is just a different URL.
Editor: I’m a prospect needing a comprehensive ALM solution. Our developers mostly use Git for source code management, but Polarion uses SVN internally. Will it be tough to integrate with Polarion?
Lutz: It is very easy. Polarion uses SVN for its internal storage. That’s just an implementation detail you don’t need to care about. You are never forced to access Polarion with a regular SVN client. You can just use the easy web UI to manage all tasks. In fact, if you don’t tell them, your developers may not ever recognize that they are using a tool based on SVN!
We’re finding that a lot of our customers are requesting us to leave out all SVN details from our roll-out training altogether, because they are concentrating on application lifecycle management tasks. They just want to make sure source code revisions get linked to Polarion Work Items for traceability. A simple configuration, as just discussed, connects up Polarion with Git so that commits get linked up with other project artifacts. Once that’s done, our customers are generally happy to leave the version control tool details of Git and Subversion usage up to their experts in development.
EDITOR’S NOTE: Polarion Software is launching a new Workshop on Git. The first one will be held in Munich, Germany (in German) later this year. For more info (also in German), see the Git Workshop registration page. Watch our Events page for more Workshops, Conferences, and Webinars throughout the year.
