Question

I’m coming from a ClearCase background where we (simply speaking) had a workflow made up of three steps where the leftmost trunk was unstable, middle trunk is Quality Assurance and the rightmost was stable. i.e.)

A  A  A
|  |  |
B  C  |
| /|  |
C  |  E
|  | /  
D  E
| /
E

As you can see the stable trunk contains only the versions that have been qualified. I’m having problems replicating this workflow in Git as versions B, C and D are also pushed into the QA trunk and subsequently the stable trunk. In my eyes this defeats the purpose of a “clean” trunk containing only stable versions.

Now there’s obviously fundamental differences between Git and ClearCase which I’m sure explains why I’m having trouble using my previous conceptions to specify a workflow.

I’ve been trying to wrap my head around these new SCM tools (I’ve looked at Mercurial too) for a couple of days now and could really use some pointers on how to proceed. We’re developing on Mac and Windows PCs and the vast majority of the teams prefer GUI tools compared to command line.

Thanks! 🙂

Answer 1

First you can read this comparison between ClearCase and Git

As explained in Middle-ground between submodules and branches?, the one concept which is likely to trick you when coming from ClearCase is the notion of composition (configuration inheritance): see Flexible vs static branching (GIT vs Clearcase/Accurev).

ClearCase works file by file (or activity by activity, each activity being a group of files).
Git works blob delta by blob delta (each blob representing a content: if two files have the same content, only one “blob” will be stored)

That means what you are trying to do in ClearCase through branch/streams and activities (if you are using UCM), will more likely be achieved through:

• commit reordering (rebase –interactive, which is the “git” way, and not recommended in mercurial)
• and/or publication (which is an orthogonal dimension to branching, specific to DVCS)

reordering + merge (only for commits not yet “published”, ie not pushed):
You are reordering the modifications deltas applied to your code, in order to merge only what you want.

trunk => trunk'  QA => QA'  stable
  A        B'    
  |        |  
  B        D'
  |        |  
  C        A'----A'    C''
  |        |     |     |
  D        C'    C'    A''--  A''  (--: merge to branch)
  |        |     |     |      |
  E        E     E     E      E

• reordering + publication (push):

You can also represent each code promotion by a git repo of its own.
Once the commits are in the proper order, you push the relevant branches to a QA repo, or a stable repo.

---

The reordering (history rewriting) is:

• not encouraged in Mercurial, while being technically possible
• problematic when a developer pull a branch someone else has rebased (reordered): see the RECOVERING FROM UPSTREAM REBASE section of the git rebase man page.

See also:

• A successful Git branching model
• Using Mercurial in a Large Organization