Ramificación flexible vs estática (Git vs Clearcase/Accurev)

https://stackoverflow.com/questions/763099

11-09-2019
|

Pregunta

Mi pregunta es sobre la forma en que Git maneja las ramas:cada vez que se bifurca desde una confirmación, esta rama nunca recibirá cambios de la rama principal a menos que usted fuerza con una fusión.

Pero en otros sistemas como Clearcase o Accurev, puedes especificar cómo se llenan las sucursales con algún tipo de mecanismo de herencia:Quiero decir, con Clearcase, usando config_spec, puedes decir "modificar todos los archivos en la rama /main/issue001 y luego continuar con los de /main o con esta línea de base específica".

En Accurev también tiene un mecanismo similar que permite que las transmisiones reciban cambios de las ramas superiores (transmisiones como las llaman) sin fusionar ni crear una nueva confirmación en la rama.

¿No te pierdes esto mientras usas Git?¿Puedes enumerar escenarios en los que esto herencia ¿es un deber?

Gracias

Actualizar Lea la respuesta de VonC a continuación para centrar mi pregunta.Una vez que coincidimos en que el "almacenamiento lineal" y los SCM basados en DAG tienen capacidades diferentes, mi pregunta es: ¿Cuáles son los escenarios de la vida real (especialmente para empresas que utilizan más OSS) en los que lineal puede hacer cosas que no son posibles para DAG?¿Valen la pena?

Solución

Para entender por qué Git no ofrece algún tipo de lo que usted se refiere como un "mecanismo de herencia" (que no implican un commit), primero hay que entender uno de los core de los SCM (Git vs. ClearCase por ejemplo)

ClearCase utiliza un lineal de almacenamiento versión : cada versión de un elemento (archivo o directorio) está vinculado de manera directa linear relación con el de la versión anterior de el mismo elemento.
Git utiliza un DAG - Dirigido acíclicos Gráfico : cada "versión" de un archivo es en realidad parte de un conjunto global de los cambios en un árbol que es en sí mismo parte de una confirmación. La versión anterior de que se debe encontrar en una confirmación anterior, accesible a través de una sola trayectoria gráfico acíclico dirigido.

En un sistema lineal, una especificación de configuración puede especificar varias reglas para el logro de la "herencia" que se ve (para un archivo dado, primero seleccione una determinada versión, y si no está presente, a continuación, seleccione otra versión, y si no está presente, a continuación, seleccione un tercero, y así sucesivamente).

La rama es un tenedor en un linear historia de una determinada versión de una regla dada de selección (todas las otras reglas de selección antes de que uno se siguen aplicando, por lo tanto, la "herencia" efecto)

En un DAG, una confirmación representa toda la "herencia" que tendrá que llegar; no hay ninguna selección "acumulativo" de versiones. Sólo hay un camino en este gráfico para seleccionar todos los archivos que se pueden ver en este punto exacto (commit).
Una rama es sólo un nuevo camino en este gráfico.

Para aplicar, en Git, algunas otras versiones, usted debe:

funden en su sucursal de alguna otra confirmación (como en el git pull "mencionado por de stsquad respuesta ) o
rebase su sucursal (como se menciona Greg )

Pero desde Git es un SCM basadas en DAG, siempre dará lugar a un nuevo compromiso.

Lo que están "perdiendo" con Git es una especie de "composición" (al momento de seleccionar diferentes versiones con diferentes reglas de selección sucesivos), pero que no sería práctico en un D VCS ( como en "distribuida"): cuando presenta una rama con Git, es necesario hacerlo con un punto de partida y un contenido claramente definidos y fácilmente replicado a otros repositorios

En un VCS puramente central, se puede definir el espacio de trabajo (en ClearCase, su "vista", ya sea instantánea o dinámica) con cualquier regla que desea.

desconocida por Google añade en el comentario (y en su pregunta anterior):

Así que, una vez que vemos los dos modelos se pueden lograr cosas diferentes (lineal vs DAG), mi pregunta es: ¿cuáles son los escenarios de la vida real (sobre todo para las empresas más OSS), donde lineal puede hacer las cosas no es posible para DAG? ¿Son Merece la pena?

Cuando se trata de la "situación real" en términos de reglas de selección, lo que puede hacer en un modelo lineal es tener varios reglas de selección para el mismo conjunto de archivos .

Considere esto "spec config" (es decir, "especificación de la configuración" para reglas de selección con ClearCase):

element /aPath/... aLabel3 -mkbranch myNewBranch
element /aPath/... aLabel2 -mkbranch myNewBranch

Se selecciona todos los archivos etiquetados 'aLabel2' (y la rama de allí), a excepción de aquellos que estén etiquetados 'aLabel3' - y la rama de allí - (porque esa regla precede ºe uno de mención 'aLabel2').

¿Merece la pena?

No.

En realidad, el sabor de la UCM ClearCase (el " configuración unificada gestión " metodología incluye con el producto de ClearCase, y en representación de todos los 'mejores prácticas' deducidas de uso de ClearCase de base) no lo permite, por razones de simplificity . Un conjunto de archivos se llama un "componente", y si quieres sucursal de una etiqueta dada (conocido como "línea de base"), que se traduce como esta especificación de configuración siguiente:

element /aPath/... .../myNewBranch
element /aPath/... aLabel3 -mkbranch myNewBranch
element /aPath/... /main/0 -mkbranch myNewBranch

Usted tiene que escoger un punto de partida (en este caso, 'aLabel3') e ir de allí. Si quieres también los archivos de 'aLabel2', se hará una combinación de todos los archivos '' aLabel2 a los de 'myNewBranch'.

Esto es una "simplificación" que no tiene que hacer con un DAG, donde cada nodo del gráfico representa un "punto de partida" se define de forma única para una rama, lo que es el conjunto de archivos involucrados.

Combinar y rebase son suficientes para combinar ese punto de partida con otras versiones de un determinado conjunto de archivos, con el fin de lograr la "composición" deseada, manteniendo que la historia particular, aisladamente en una rama .

El objetivo general es a la razón en " coherente Las operaciones de control de versiones aplicado a un coherente componente". Un conjunto "coherente" de archivos es uno en un estado coherente, bien definido:

Si está etiquetado, todos sus archivos están etiquetados
Si ramificado, todos sus archivos se ramifican desde la misma único punto de partida

Esto se hace fácilmente en un sistema de DAG; puede ser más difícil en un sistema lineal (especialmente con "Base ClearCase" donde el "spec config" puede ser complicado), pero se aplica con la metodología UCM de ese mismo herramienta basada en lineal.

En lugar de lograr que "composición" a través de un "truco regla de selección privada" (con ClearCase, algunos de selección de orden de las reglas), se consigue sólo con las operaciones de control de versiones (rebase o fusionar), que dejan un rastro claro para todo el mundo a seguir (a diferencia de una especificación de configuración privado a un desarrollador, o comparte entre algunos, pero no todos los desarrolladores). Una vez más, se impone un sentido del coherencia , en lugar de una "flexibilidad dinámica", que puede tener un tiempo difícil de reproducir más tarde .

Esto le permite dejar el terreno de VCS (sistema de control de versiones) y entrar en el reino de la SCM (Software Configuration Management) , que se ocupa principalmente de " reproducibilidad ". Y que las características (SCM) se puede lograr con un lineal o basado en un VCS a base de DAG.

Otros consejos

Parece que lo que estás buscando puede ser git rebase . Rebase una rama conceptualmente lo separa de su punto de ramificación original y vuelve a unir en algún otro punto. (En realidad, el rebase se lleva a cabo mediante la aplicación de cada parche de la rama en secuencia para el nuevo punto de ramificación, la creación de un nuevo conjunto de parches.) En el ejemplo, se puede rebasar una rama a la punta actual de una rama superior, la cual será esencialmente "heredar" todos los cambios realizados en la otra rama.

No estoy totalmente claro en lo que su pidiendo pero suena como git de la semántica de seguimiento son los deseados. Cuando se ramifican a partir de la mañana origen usted puede hacer algo como:

git -t -b my_branch origen / master

Y entonces futuros s "git pull" se fusionarán automático origin / master en su rama de trabajo. A continuación, puede utilizar "git cereza -v origin / master" para ver cuál es la diferencia. Puede utilizar "git rebase" antes de publicar el cambios para limpiar la historia, pero no se debe utilizar una vez que rebase su historial es público (es decir, otras personas están siguiendo esa rama).

En cuanto al esquema de herencia utilizado por AccuRev: GIT usuarios probablemente "obtener" todo el asunto cuando la mirada en -flujo git (véase también: http://github.com/nvie/gitflow y http://jeffkreeftmeijer.com/2010/why-arent- que-usando-git-flow / )

Esta GIT ramificación modelo más o menos lo hace (manual / con la ayuda de la herramienta de flujo de GIT) lo AccuRev hace fuera de la caja automática y con gran apoyo interfaz gráfica de usuario.

Entonces que aparece GIT puede hacer lo que hace AccuRev. Desde que en realidad nunca utilicé git / git-flow del día a día que no puedo decir cómo funciona, pero que tiene un aspecto prometedor. (Menos de soporte GUI adecuada: -)

Voy a tratar de responder a la pregunta que usted. (Tengo que decir aquí que no he utilizado GIT de sólo lectura al respecto, así que si algo que menciono a continuación es incorrecto, por favor me corrija)

"¿Puede enumerar los escenarios en los que esta herencia es una necesidad?"

No voy a decir que es una necesidad, porque se puede resolver un problema con la herramienta que tiene, y puede ser que sea una solución válida para su entorno. Creo que es más una cuestión de los procesos que la propia herramienta. Asegurarse de que su proceso es coherente y también le permite retroceder en el tiempo para reproducir cualquier paso / estado intermedio es el objetivo, y la ventaja es que la herramienta le permite ejecutar su proceso y PGCS lo menos doloroso posible

El escenario que puede ver que es útil tener este 'herencia' comportamiento y utilizar el poder de la especificación de configuración, es cuando usted quiere que su conjunto de cambios " aislado " asignado a una tarea (devtask, CR, SR, o lo que define el propósito / alcance de su conjunto de cambios)

El uso de esta composición le permite tener su rama de desarrollo limpio y seguir utilizando diferentes combinaciones (usando la composición) del resto del código, y aún así tener sólo lo que es relevante para la tarea aisló en una rama durante el toda ciclo de vida de la tarea, sólo hasta la fase de integración.

Al ser purista tener que comprometerse / fusión / rebase sólo para tener un "punto de partida definido", supongo que sería ' contaminan ' su sucursal y el resultado final será con los cambios + Otros cambios en el el conjunto de la rama / cambio.

Cuando / Donde este aislamiento es útil? Los puntos abajo solamente puede tener sentido en el contexto de las empresas que persiguen CMM y algunas certificaciones ISO, y podrían ser de interés para otro tipo de empresas o OSS

Al ser muy exigente, es posible que desee contar con precisión las líneas de código (añadido / modificado / borrado) del conjunto de cambios que corresponde a un único promotor, que se utiliza después como una entrada para el código y esfuerzo estimaciones.
Puede ser más fácil de revisar el código en diferentes etapas, tener sólo el código de una sola rama (no pegados con otros cambios)

En grandes proyectos con varios equipos y +500 desarrolladores que trabajan de forma activa simultáneamente en el mismo código base, (donde gráficas versión árboles de elementos individuales se ve como una tela sucia enredada con varias líneas de carga, uno para cada cliente grande, o uno para cada tecnología ) grandes características de configuración utilizando composición de varios grados de profundidad hicieron esta cantidad de personas trabajan sin problemas para adaptar el sistema (código mismo producto / base) para diferentes propósitos. El uso de esta especificación de configuración, de forma dinámica dio a cada equipo o el equipo sub, una visión diferente a lo que necesitan y desde donde necesitan rama de, (en cascada en varios casos) sin la necesidad de crear ramas de integración intermedios, o constantemente la fusión y rebase todos los bits que necesita para empezar. Código de la misma tarea / propósito fue ramificando de etiquetas diferentes, pero tenía sentido. (Se puede discutir aquí la 'línea base conocida' como principio del SMC, sino simples etiquetas contempladas en un Plan de SMC escrita hizo el trabajo) Debe ser posible resolver esto con GIT (supongo que de una forma no dinámica) pero me resulta muy difícil de imaginar sin este comportamiento 'herencia'. Supongo que el punto mencionado por VonC "si ramificada, todos sus archivos se ramifican desde el mismo punto de partida único" fue roto aquí, pero al lado de él estaba bien documentado en la PGCS, recuerdo que había una fuerte razón comercial para hacerlo de esa manera.

Si la construcción de estas especificaciones de configuración que he mencionado anteriormente no era libre, en el que comienza ahí donde 4-5 personas bien pagados detrás del SMC, pero más tarde se redujeron en scripts automatizados que les pide lo que desea en términos de etiquetas / ramas / características y escribirán el CS para usted.

La reproducibilidad aquí se logró con sólo guardar la configuración de especificaciones, junto con la tarea en eldevTask sistema, por lo que cada tarea asignada a los requisitos arriba y aguas abajo asignan a una especificación de configuración, una de un conjunto de cambios (archivos de código, documentos de diseño, documentos de prueba, etc.)

Así que hasta aquí una conclusión aquí podría ser, sólo si su proyecto es grande / bastante complicado (y se lo puede permitir Administradores SC a lo largo de la vida del proyecto :)) entonces sólo empezar a pensar si necesita la 'herencia "comportamiento o una herramienta muy versátil, de lo contrario se irán directamente a AA herramienta que está libre y ya cuidar de la coherencia de que SMC ... pero podría haber otros factores en la herramienta de SMC que podrían hacer que usted se pega a uno o al otro ... sigue leyendo ..

Algunas notas al margen, que podría estar fuera de tema, pero supongo que en algunos casos como el mío necesitan ser considerados.

Tengo que añadir que usamos la "buena-ol CC" no UCM. Totalmente de acuerdo con VonC en el una buena metodología permite al "guía" la flexibilidad hacia una configuración más coherente . Lo bueno es que CC es bastante flexible y se puede encontrar (no sin esfuerzo) una buena manera de tener algo coherente, mientras que en otra SMC que pueda tener de forma gratuita. Pero por ejemplo aquí (y otros lugares que he trabajado con CC) para proyectos de C / C ++ que no podemos pagar el precio de no tener el winkin característica (la reutilización de los objetos emanan), que reducen varios X tiempos de compilación de tiempo. Se puede argumentar que el tener un mejor diseño, un código más disociadas, y la optimización de Makefile puede reducir la necesidad de recopilar toda la cosa, pero hay casos en que es necesario recopilar toda la bestia muchas veces al día, y compartir la DO ahorra un montón de tiempo / dinero. ¿Dónde estoy ahora tratamos de utilizar herramienta tanto libre como sea posible, y creo que vamos a deshacernos de CC si podemos encontrar una herramienta más barata o gratuita que implementa el winkin función.

Voy a terminar con algo que menciona Pablo, diferentes herramientas son mejores que otros para diferentes propósitos , pero voy a añadir que usted puede conseguir lejos de algunas limitaciones de la herramienta por tener un proceso coherente y sin sacrificar la reproducibilidad, los puntos clave de la SMC Al final supongo que la respuesta a vale la pena? depende de su "problema", el SDLC está ejecutando, sus procesos de SCM, y si hay alguna característica adicional (como winkin) que podrían ser útil en su entorno.

mis 2 centavos de dólar

Dejando a un lado la teoría, aquí hay una especie de visión práctica obvia de esto, desde mi perspectiva usando AccuRev en un entorno de producción comercial durante varios años:El modelo de herencia funciona muy bien siempre y cuando los flujos secundarios no se hayan diferenciado demasiado de los ancestros que todavía están en desarrollo.Se descompone cuando las corrientes hereditarias son demasiado diferentes.

La herencia (versiones posteriores como hijas de las anteriores) permite que los cambios en las secuencias ancestrales estén activos en las secuencias secundarias sin que nadie haga nada (a menos que se requiera una fusión, en cuyo caso se muestra como una superposición profunda, lo cual es bueno poder ver ).

Eso suena genial, y en la práctica lo es, cuando todas las corrientes involucradas son relativamente similares.Usamos ese modelo para transmisiones a nivel de hotfix y service pack por debajo de una versión de producción determinada.(En realidad, es un poco más complicado que eso para nosotros, pero esa es la idea general).

Las versiones de producción son paralelas, sin herencia, con esas revisiones y paquetes de servicio secundarios debajo de cada uno de ellos.Iniciar una nueva versión significa crear una nueva secuencia de nivel de versión e insertar manualmente todo, desde la secuencia de mantenimiento más reciente para la versión anterior.Después de eso, los cambios en las versiones anteriores que se aplican a las posteriores deben introducirse manualmente en cada una de ellas, lo que requiere más trabajo, pero permite un control mucho mayor.

Originalmente utilizamos el modelo de herencia en todas las versiones, donde las posteriores eran hijas de las anteriores.Eso funcionó bien por un tiempo, pero con el tiempo se volvió inmanejable.Las importantes diferencias arquitectónicas entre las versiones hicieron que heredar cambios inevitablemente fuera una mala idea.Sí, puede colocar una instantánea en el medio para bloquear la herencia, pero luego todos los cambios deben enviarse manualmente, y la única diferencia real entre las secuencias padre-instantánea-secundaria y las secuencias paralelas que no se heredan es que toda la vista gráfica de la secuencia se presiona hacia abajo continuamente. y a la derecha, que es un PITA.

Una cosa realmente buena de AccuRev es que tienes esta opción todo el tiempo.No es una restricción inherente a la arquitectura de su programa SCM.

¿Ha notado que usted puede pagar con las versiones de archivos specfific GIT también?

Sólo tiene que utilizar la siguiente:

git checkout [< tree-ish >] [--] < paths >

Al igual que por config spec cualquier versión existente de un archivo (caminos) se pueden cargar en el worktree. Presupuesto de documentos git-checkout:

La siguiente secuencia cabo controles de la rama principal, revierte el Makefile para dos revisiones de espalda, elimina hello.c por error, y obtiene de nuevo a partir del índice:

$ git checkout master             
$ git checkout master~2 Makefile             
$ rm -f hello.c            
$ git checkout hello.c

ClearCase, sin MultiSite, es un único repositorio pero Git se distribuye. ClearCase se compromete a nivel de archivo, pero Git se compromete a nivel repositorio. (Esta última diferencia significa la pregunta original se basa en un malentendido, como se señala en los demás puestos aquí.)

Si estas son las diferencias que estamos hablando entonces pienso 'lineal' frente a 'DAG' es una manera confusa para distinguir estos sistemas SCM. En ClearCase todas las versiones de un archivo se conocen como la versión "árbol" del archivo, pero en realidad es un gráfico acíclico dirigido! La verdadera diferencia para Git es que existen los DAG de ClearCase por archivo. Así que creo que es engañoso para referirse a ClearCase como no DAG y Git como DAG.

(Por cierto clearcase versiones de sus directorios de una manera similar a sus archivos -. Pero eso es otra historia)

No estoy seguro de si le está pidiendo nada, pero que están demostrando que las corrientes AccuRev son herramientas diferentes a Git (o SVN) ramas. (No sé Clearcase.)

Por ejemplo, con Accurev usted es forzada , como usted dice, para usar ciertos flujos de trabajo, lo que le da una historia auditable de cambios que no se admite en Git. la herencia de ciertos flujos de trabajo Accurev hace más eficiente y demás imposible.

Con Git se puede tener exploratoria de codificación segregados en repositorios locales o en las ramas de características, que no contaría con el apoyo muy bien por Accurev.

Las diferentes herramientas son buenas para distintos fines; que es útil preguntar lo que cada uno es bueno de .

Licenciado bajo: CC-BY-SA con atribución

No afiliado a StackOverflow