379 votos

¿Qué ramificaciones Git modelos de trabajo para usted?

Nuestra empresa se encuentra actualmente el uso de un simple tronco/release/revisiones de ramificación modelo y quisiera un consejo sobre qué modelos de ramificación es el mejor para su empresa o proceso de desarrollo.

  1. Los flujos de trabajo / modelos de ramificación

    A continuación están las tres principales descripciones de esto he visto, pero son parcialmente contradictorias unos a otros, o no va lo suficientemente lejos para ordenar las sucesivas ediciones nos hemos encontrado en (como se describe a continuación). Por lo tanto nuestro equipo hasta ahora por defecto no tan grandes soluciones. Estás haciendo algo mejor?

  2. La fusión vs reajuste (tangled vs secuencial de la historia)

    Debo pull --rebase o esperar con la fusión de espalda a la línea principal hasta que su tarea está terminada? Personalmente me inclino por la fusión ya que esta conserva una ilustración visual de que la base de una tarea que comenzó y terminó, y yo incluso prefiero merge --no-ff para este propósito. Tiene otros inconvenientes, sin embargo. También muchos no se han dado cuenta de la propiedad útil de la fusión - que no es conmutativa (fusión de una rama en master no significa la fusión de maestro en el tema de la rama).

  3. Estoy en busca de un flujo de trabajo natural

    A veces, los errores ocurren porque nuestros procedimientos no capturar una situación específica con reglas simples. Por ejemplo, una corrección necesaria para versiones anteriores deben de estar basados suficientemente abajo a ser posible combinar aguas arriba en todas las ramas necesario (como es el uso de estos términos lo suficientemente claro?). Sin embargo sucede que una solución se convierte en el maestro antes de que el desarrollador se da cuenta de que debería haber sido colocado más abajo, y si que ya es empujado (aún peor, se haya fusionado o algo basado en él), a continuación, la opción restante es cherry-picking, con sus peligros asociados. ¿Qué reglas simples, como tales, se utilizan? También en esto se incluye la incomodidad de una rama necesariamente excluyente de un tema ramas (asumiendo que son ramificadas a partir de una base de referencia común). Los desarrolladores no quieren terminar una función para comenzar otra la sensación de que el código que acabo de escribir ya no está más allí

  4. Cómo evitar la creación de conflictos (debido a cherry-pick)?

    Lo que parece ser una manera segura de crear un conflicto de combinación es cherry-pick entre las ramas, nunca pueden ser combinadas de nuevo? ¿La aplicación de la misma cometer en volver (¿cómo hacerlo?) en cualquiera de las sucursales, posiblemente, resolver esta situación? Esta es la razón por la que no se atreven a impulsar una gran parte de combinación basada en el flujo de trabajo.

  5. ¿Cómo descomponer en tópicos ramas?

    Nos damos cuenta de que sería estupendo para montar un acabado integración de tema ramas, pero a menudo trabajan por nuestros desarrolladores no está claramente definida (a veces tan simple como "hurgando") y si el código ya ha entrado en una "misc" tema, no puede ser sacado de allí de nuevo, de acuerdo a la pregunta anterior? ¿Cómo trabajan con la definición/aprobar/graduarse/de la liberación de su tema ramas?

  6. Los procedimientos apropiados, como la revisión del código y de graduarse , por supuesto, ser encantadora.

    Pero simplemente no podemos mantener las cosas destrabó suficiente para gestionar este - alguna sugerencia? la integración de las ramas, las ilustraciones?

A continuación se muestra una lista de preguntas relacionadas:

También echa un vistazo a lo Plástico SCM escribe en la tarea de desarrollo impulsado, y si el Plástico no es su elección, estudio nvie de la ramificación de la modelo y su apoyo a los scripts.

91voto

VonC Puntos 414372

La más preocupante característica de los nuevos desarrolladores para DVCS hay que darse cuenta es sobre el proceso de publicación:

  • usted puede importar (fetch/pull) lo remoto repo que usted necesita
  • puede publicar (push) para cualquier (desnudo) repo desea

A partir de eso, se puede respetar una serie de reglas para hacer tu pregunta más fácil:

  • sólo un reajuste de la rama, si no ha sido empujado (no se insertan desde el último reajuste)
  • sólo de empujar a un desnudo de repo (obligatorio desde Git1.7)
  • siga Linus los consejos de rebase y se funde

Ahora:

Los flujos de trabajo / modelos de ramificación:

cada flujo de trabajo está allí para apoyar un proceso de administración de versiones, y es que a medida para cada proyecto.
Lo que puedo añadir a flujo de trabajo que usted menciona es: cada desarrollador no debería crear una entidad de la rama, sólo una corriente "dev" de la rama, porque la verdad es que el desarrollador a menudo no sabe qué es exactamente su rama va a producir: una característica, varios (porque terminó siendo demasiado complejo característica), ninguno (porque no está listo a tiempo para la liberación), otra característica (ya que el original se había "transformado"),...

Sólo un "integrador" debe establecido oficial característica de las ramas, en una "central" repo, que luego pueden ser recuperados por los desarrolladores reajuste/fusionar la parte de su trabajo que se ajusta a esa característica.

La fusión vs reajuste (tangled vs secuencial de la historia):

Me gusta mi respuesta que usted menciona ("descripción del Flujo de trabajo para uso de git para el desarrollo in house")

Estoy en busca de un flujo de trabajo natural:

para las correcciones, puede ayudar a asociar a cada arreglar con un billete de un error de seguimiento, que ayuda al desarrollador a recordar de donde (ej. en la rama, es decir. un dedicado rama "revisiones"), él/ella debe cometer tales modificaciones.
A continuación, los ganchos pueden ayudar a proteger una central repo contra empuja de no validadas, correcciones o de sucursales de las que uno no debería empujar. (no específicos de la solución aquí, todo esto necesita ser adaptado a su entorno)

Cómo evitar la creación de conflictos (debido a cherry-pick)?

Como dijo Jakub Narębski en su respuesta, el cherry picking debe ser reservada para los raros casos en los que sea necesario.
Si su instalación implica un montón de cherry-picking (p. ej., "no es raro"), entonces algo está apagado.

¿La aplicación de la misma cometer en volver (¿cómo hacerlo?)

git revert debe tener cuidado de que, pero eso no es lo ideal.

¿Cómo descomponer en tópicos ramas?

Tan largo como el de una rama como no ha sido empujado en todas partes, un desarrollador debe reorganizar su historial de commits (una vez que él/ella ver finalmente que el desarrollo se lleva a una más definitiva y estable de forma) en:

  • varias ramas, si es necesario (una clara característica identificada)
  • un conjunto coherente de cometa dentro de una rama (ver Recorte de Git Confirmaciones)

Los procedimientos apropiados, como la revisión del código y graduarse ?

Integración de sucursales (en un dedicado de integración) repo puede ayudar al desarrollador:

  • reajuste de su desarrollo en la parte superior de ese remoto integración de la rama (pull --rebase)
  • resolver localmente
  • fomentar el desarrollo a que repo
  • consulte con el integrador que no resulte en un lío ;)

21voto

Ninefingers Puntos 18767

Creo, y puedo estar equivocado, que una de las cosas que más mal entendido acerca de git es su naturaleza distribuida. Esto hace que sea muy diferente a decir que la subversión en las maneras en que usted puede trabajar aunque puede imitar a la SVN comportamiento debe usted desea. El problema es que prácticamente cualquier flujo de trabajo se hacen, que es grande, pero también engañosa.

Si tengo mi comprensión de núcleo de desarrollo (voy a centrar en eso) a la derecha, cada uno tiene su propio repositorio git para el desarrollo del kernel. Hay un repositorio de linux-2.6.git, atendidos por Torvalds, que actúa como la versión del repositorio. La gente clon a partir de aquí si desean iniciar el desarrollo de una función en contra de la "liberación" de la rama.

Otros repositorios de hacer un poco de desarrollo. La idea es clonar de linux-2.6, rama tantas veces como quieras hasta un punto como el que tienes un trabajo "nuevo". Luego, cuando esté listo, usted puede hacer que esté disponible para alguien considerado de confianza, que saque a esta rama del repositorio en la suya y la de combinar en la corriente principal. En el kernel de linux esto ocurre en varios niveles (de confianza tenientes) hasta que se llega a linux-2.6.git punto en que se convierte en "el núcleo".

Ahora aquí es donde se pone confuso. Rama nombres no deben ser consistentes a través de los repositorios. Para que yo pueda git pull origin master:vanilla-code y conseguir una rama de la origin's principal en una sucursal en mi repositorio llamado vanilla-code. Proporcionar sé lo que está pasando, realmente no importa - se distribuye en el sentido de que todos los repositorios son iguales el uno al otro y no acaba de compartir entre varios equipos como el SVN.

Así que, con todo esto en mente:

  1. Creo que depende de cada programador cómo hacer su ramificación. Todo lo que usted necesita es un repositorio central para la gestión de versiones, etc. Maletero podría ser head. De las versiones puede ser etiquetas de las ramas y las revisiones son probablemente las ramas en sí mismos. De hecho, probablemente me lo hacen versiones como las ramas de modo que usted puede mantener aplicación de parches.
  2. Me gustaría combinar y no rebase. Por ejemplo, si usted toma un repositorio, clon, rama y hacer algunas dev, a continuación, tire de su origin debe, en su repositorio, probablemente haga otra rama y la combinación de la última master a yourbranch , de modo que alguien puede tirar de sus cambios con tan poco esfuerzo como sea posible. Hay muy rara vez necesitan realmente rebase, en mi experiencia.
  3. Creo que es un caso de la comprensión de la manera de Git que funciona y lo que puede hacer. Tarda un rato y un montón de buena comunicación - solo estoy realmente comenzó a entender lo que está pasando cuando comencé a usar git con otros desarrolladores, e incluso ahora, algunas cosas no estoy seguro.
  4. Conflictos de combinación son útiles. Yo sé, yo sé, que quieres que todo el trabajo, pero la realidad es que los cambios de código y necesita combinar los resultados en algo que funcione. Conflictos de combinación son, de hecho, más de la programación. Nunca he encontrado una explicación fácil para qué hacer acerca de ellos, así que aquí está: nota : los archivos que tienen conflictos, ir y cambiar a lo que debe ser, git add . y, a continuación, git commit.
  5. Sin embargo conviene. Como he dicho, cada uno de los usuarios del repositorio de git es la de su propia jugar y rama nombres no necesita ser el mismo. Si usted tuvo una puesta en escena de repositorio, por ejemplo, puede aplicar un esquema de nomenclatura, pero no es necesario para que cada desarrollador, sólo en la versión de repos.
  6. Esta es la mezcla de la etapa. Sólo se funden en la liberación de las ramas, etc cuando usted considera que el código de revisar/aprobar las pruebas de calidad.

Espero que le ayude. Me doy cuenta de VonC como acaba de publicar un muy similares explicación... no puedo escribir lo suficientemente rápido!

Editar algunas reflexiones sobre cómo utilizar git en un establecimiento comercial, ya que este parece relevante a la OP a partir de los comentarios:

  • La versión del repositorio, vamos a llamar a product.git, es accesible por un número de expertos programadores / técnicos a la gente responsable de la realidad buscando después de que el producto en sí. Son análogas a el papel de mantenedores en OSS.
  • Estos programadores, probablemente, también en parte principal de desarrollo de nuevas versiones, por lo que también podría código de sí mismos y mantener varios repositorios. Se puede gestionar repositorios de ensayo para la realidad de las nuevas características y también pueden tener sus propios repositorios.
  • Debajo de ellos están los programadores responsables para el desarrollo de cada uno de los bits. Por ejemplo, alguien podría ser responsable de la interfaz de usuario de trabajo. Por lo tanto, administrar la UI.git repositorio.
  • Debajo de ellos son los auténticos programadores que desarrollan las características como su plena día a día de trabajo.

Entonces, ¿qué pasa? Bueno, todo el mundo tira en el inicio de cada día de las "aguas arriba" de la fuente, es decir. la versión del repositorio (que también contienen probablemente el más reciente material de los anteriores días de desarrollo). Todo el mundo lo hace, directamente. Esto va a ir en una rama en su repositorio, probablemente llamado "maestro" o tal vez si eres me llamaban el "más reciente". El programador, a continuación, hacer algo de trabajo. Este trabajo podría ser algo que no es seguro, así que hacer un branch, hacer el trabajo. Si no funciona, se puede eliminar de la rama y volver. Si lo hace, tendrá que combinar en la rama principal que estamos trabajando actualmente. Vamos a decir que esta es una interfaz de usuario programador trabajando en latest-ui así lo hace git checkout latest-ui seguido por git merge abc-ui-mywhizzynewfeature. Él entonces le dice a su jefe técnico (la interfaz de usuario de plomo) hey, he completado esta tarea, tire de mí. Por lo que la interfaz de usuario de plomo git pull user-repo lastest-ui:lastest-ui-suchafeature-abc. La interfaz de usuario de plomo, a continuación, mira en esa rama y dice que, en realidad, es muy bueno, voy a combinar en ui-latest. Él podría decirle a todo el mundo por debajo de él para tirar de él en su ui-latest sucursales o cualquier nombre que he dado a ellos, y así la característica obtiene explorado por los desarrolladores. Si el equipo está feliz, la interfaz de usuario de plomo pueden hacer las pruebas de plomo para tirar de él y combinar los cambios. Esto se propaga a todo el mundo (aguas abajo de el cambio), que la evalúa y presenta informes de errores, etc. Por último, si la característica de los pases de pruebas, etc, uno de los mejores técnicos conduce podría combinar en la copia de trabajo actual del programa, momento en el que todos los cambios se propagan hacia abajo. Y así sucesivamente.

No es una forma "tradicional" de trabajo y está diseñado para ser "iguales" basadas en lugar de "jerárquica" como SVN/CVS. En esencia, todo el mundo tiene acceso commit, pero sólo a nivel local. Es el acceso al repositorio y que repositorio que designe como la liberación de la repo que te permite usar la jerarquía.

9voto

John Nilsson Puntos 4650

Un modelo que he utilizado con buenos resultados son los siguientes.

Un "bendito" repo todo el mundo de inserción y extracción (básicamente un cliente-servidor en la topología)

No hay ninguna rama master, por lo que ningún desarrollador puede introducir ningún código en "renombre"

Todos los acontecimientos ocurren en el tema de las ramas. Hemos nombres de espacios de nombres para descubrir fácilmente quién es el responsable de: jn/newFeature o jn/tema-1234

También hay una cerca de 1-a-1 asignación entre las ramas y kanban/scrum tarjetas en la pizarra.

Para liberar una rama que es empujada a la santísima repo y el kanban-tarjetas se trasladó a listo para su revisión.

Si la rama es aceptado por la revisión es un candidato para un lanzamiento.

Un releae ocurre cuando un conjunto de aceptado las ramas se fusionan y etiquetado con un número de versión.

Empujando la nueva etiqueta a la santísima repos que hay una nueva base para las nuevas características.

Para evitar conflictos de los desarrolladores se ruega a actualizar (mezcla) de sus inéditos ramas a la versión más reciente de la etiqueta.

3voto

Gaurav Kumar Puntos 173

Echa un vistazo a este increíble artículo en profundidad lo que explica el Git de ramificación modelo muy acertadamente.

La presentación de un breve resumen aquí: Básicamente, usted tiene 2 ramas principales- master y develop y spin-off de nuevas sucursales, como y cuando sea necesario, para diversos fines, como Feature, Release y Hotfix sucursales. El artículo también explica el origen de cada rama, y donde cada rama debe ser incluido de nuevo en.

También encontrará algunas de las mejores prácticas, tales como el etiquetado de la producción de prensa y el -no-ff opción para conservar la rama de la historia local.

Referencia:

  1. Git Bracnhing Modelo

Git branching model

2voto

xero Puntos 1449

personalmente, yo trato de mantener sólo código listo del lanzamiento en la rama principal. Cuando trabajo en una nueva característica o corrección hago en una rama. Yo también prueba unitaria en la rama. Si todo sale bien, entonces fusión/rebase en maestro.

Yo trato de usar convenciones de nomenclatura de rama común, tales como

  • corrección de errores/recursive_loop
  • corrección de errores/sql_timeout
  • característica/new_layout
  • característica/enhanced_search

Iteramos.com

Iteramos es una comunidad de desarrolladores que busca expandir el conocimiento de la programación mas allá del inglés.
Tenemos una gran cantidad de contenido, y también puedes hacer tus propias preguntas o resolver las de los demás.

Powered by:

X