git - handling many similar-yet-slightly-different applications?

Question

I'm currently working for a company that's using Rational/IBM ClearCase for a great many of its source control needs and have been looking (predominately in my free time, of course) at if/how we could migrate to git in the future.

For background: many of our projects in ClearCase are derived from a common "base" system which we then branch as needed. Most applications start out as strictly base, but client needs require that we branch the files within, resulting two versions: one base, one client-specific. Since the customer-specific version has its own label, each application can evolve independently of one another. Since the labels are affixed to a certain version of each changed file, we don't need to worry that a change in base will break things for a client (since they'll be at different revisions until someone goes in and moves the labels around). We also track the state of the code (sent to QA, awaiting customer feedback, in production) via labels as well.

As far as I can tell I'd create a new repo for the 'base' version and use tags to define the state, but handling the customer-specific versions is really confusing me. Would I need to create an entirely new repo for the client and manually move changes between the base and client versions or is there a better way? Is using tags the best way to handle delineating which revisions go w/ a particular client or am I missing something? I'd seen some mention of submodules, but from what I can tell that's predominately used to handle code related to the application and not essentially large swaths of identical code?

My questions might give it away but all of my git experience has been w/ git for personal projects. It's (relatively) easy to understand the behaviour when you're dealing with a greenfield project, not so much when you're trying to impose a new tool on an existing workflow.

I'd appreciate any insight you might have and thanks for taking your time to read my question!

Answer 1

From what you described, Git would be very well-suited to handle the use cases at your company. You would create a new Git repo based on the existing "base" system. This "base" system would correspond to the master branch in Git. For each customer version, you could create a new Git branch. Branching is an area where Git really beats out just about every other version control system, because it can create a new branch very quickly, while requiring very little storage space. Note that you would not have to initialize a new Git repository for each customer branch.

If you need to move specific features between master ("base") and any customer branches, you can do so using git merge, git rebase or even git cherry-pick. Git rebase allows you to maintain the entire history of a feature branch when bringing it back into the master branch. This could be extremely valuable to your organization if you need to carefully preserve the details of every feature added for every customer.

This question has actually been thoroughly discussed on Stack Overflow already.