Pasar de ClearCase a Git

Vengo de un entorno ClearCase en el que (simplemente hablando) teníamos un flujo de trabajo compuesto por tres pasos en los que el tronco más a la izquierda era inestable, el tronco medio era Quality Assurance y el rightmost era estable. es decir)

AAA | | | BC | | /| | C | E | | / DE | / E 

Como puede ver, el tronco estable contiene solo las versiones que han sido calificadas. Tengo problemas para replicar este flujo de trabajo en Git ya que las versiones B, C y D también se insertan en el tronco de QA y, posteriormente, en el tronco estable. En mi opinión, esto frustra el objective de un baúl "limpio" que solo contenga versiones estables.

Ahora bien, obviamente existen diferencias fundamentales entre Git y ClearCase, y estoy seguro de que explican por qué tengo problemas para utilizar mis conceptos previos para especificar un flujo de trabajo.

He estado tratando de entender estas nuevas herramientas de SCM (también miré a Mercurial) durante un par de días y realmente podría usar algunos consejos sobre cómo proceder . Estamos desarrollando PC para Mac y Windows, y la gran mayoría de los equipos prefieren herramientas GUI en comparación con la línea de command.

¡Gracias! 🙂

Primero, puedes leer esta comparación entre ClearCase y Git

Como se explica en el punto medio entre los submodules y las twigs? , el único concepto que probablemente te engañe al venir de ClearCase es la noción de composition (inheritance de configuration): ver Flexible vs derivación estática (GIT vs Clearcase / Accurev) .

ClearCase funciona file por file (o actividad por actividad, cada actividad es un grupo de files).
Git funciona blob delta por blob delta (cada blob representa un contenido : si dos files tienen el mismo contenido, solo se almacenará un "blob")

Eso significa que lo que intenta hacer en ClearCase a través de las sucursales / secuencias y actividades (si está utilizando UCM), se logrará más fácilmente a través de:

  • commit reorderamiento (rebase –interactive, que es el modo "git", y no se recomienda en mercurial)
  • y / o publicación (que es una dimensión ortogonal a la bifurcación, específica para DVCS)

reorderación + fusión (solo para confirmaciones que aún no están "publicadas", es decir, que no se han insertado):
Está reorderando las modificaciones deltas aplicadas a su código, para fusionar solo lo que desea.

 trunk => trunk' QA => QA' stable AB' | | BD' | | C A'----A' C'' | | | | DC' C' A''-- A'' (--: merge to branch) | | | | | EEEEE 
  • reorderamiento + publicación (push):

También puede representar cada promoción de código mediante un repository git propio.
Una vez que los commits están en el order correcto, usted empuja las twigs relevantes a un repo QA, o un repo estable.


El reorderamiento (reescritura de historial) es:

  • no se fomenta en Mercurial , aunque es técnicamente posible
  • problemático cuando un desarrollador tira de una twig que otra persona ha cambiado (reorderándola): vea la sección RECUPERACIÓN DESDE LA REBASE DE UPSTREAM de la página de git rebase .

Ver también:

  • Un exitoso model de ramificación de Git
  • Usando Mercurial en una gran organización