¿Cómo debo controlar las versiones de mi proyecto en GitHub?

12

Estoy tratando de pasar todo el tiempo que pueda en GitHub hoy en día (incluso yo soy la única persona en el equipo en el trabajo) para sentir realmente cómo será una aplicación corporativa del mundo real.

Una pregunta que tengo es controlar la versión . Digamos que empezamos un proyecto. Luego, los miembros del equipo crearon algunas ramas y se desarrollaron allí. Cuando estemos listos para la producción, fusionamos todas las sucursales con master . Al final, vamos a vivir con la versión 1.0 .

Ahora que la versión 1.0 está activa y tenemos algunos problemas archivados para esa versión de ese software. Nos gustaría comenzar a desarrollar la versión 1.1 para solucionar los problemas que habíamos introducido al acelerar el proyecto.

Ahora, la pregunta es esta:

¿Cómo deberíamos controlar el control de versiones aquí?

¿Deberíamos crear una nueva sucursal para v1.0 y mantener la versión 1.0 del software allí y desarrollarla en algunas sucursales (o no), fusionarlas con master y comenzar con la versión 1.1 ?

¿Hay convenciones por ahí para ese tipo de situaciones?

    
pregunta tugberk 08.01.2012 - 10:15

2 respuestas

18

Encontré (y comencé a adoptar) el siguiente modelo de rama :

(imagendelartículo)

Haymuchasprácticasexcelentesyreglasestrictasdescritaseneseartículo,lorecomiendoaltamente.

Puntosdeinterés:

  • Laramamaestraesdondeetiquetasusversiones.Aquínohaydesarrollo.Encasodequesehayaimplementadounerrorenlaproducción,arregleelerrorenunaramaderevisión,vuelvaafusionaryetiqueteunanuevaversión.
  • Eldesarrolloocurreenlasramasdedesarrolloycaracterísticas.Personalmente,hagocorreccionesdeerroresenlaramadedesarrolloycaracterísticasenlasramasdecaracterísticas.
  • Cuandoelsoftwarecomienzaaalcanzarunlanzamiento,mebifurcoparaliberarunarama.Laramadelanzamientoesdondehagolostoquesfinales.Bumpnúmerosdeversión,cambiarmetadatos,etc.Ycorreccionesdeerroresmenores.Cuandotermina,lofusionoconelmaestro,loetiquetaylollamounaversión.
  • Lasdosramasprincipales:maestroesla"rama santa"; Su HEAD es siempre el último código de producción, y el desarrollo es la rama nocturna; su HEAD siempre refleja las últimas adiciones (pero posibles inestables) al código.

En su caso específico, los pasos dependerían de cuán apresurada fuera esa versión. Si se trata de características que quedaron fuera, volvería a la versión de desarrollo y haría todo de nuevo. Si hay errores en la versión implementada, me dirijo a una rama de revisión, corregiré los errores, fusionaré y etiquetaré v1.1. Si es a la vez, primero solucionaría los errores y luego agregaría las funciones como se describe.

    
respondido por el Tamás Szelei 08.01.2012 - 12:00
1

Lo que he presenciado la mayor parte del tiempo es:

  • Maestro es para ti producto. Eventualmente, toda su futura versión x.0 estará en master.
  • Crea una etiqueta / rama para cada versión en producción, por lo que aún puede admitirlas para cualquier cliente que lo requiera.
  • La fusión de arreglos de uno u otro es para negociar caso por caso.
respondido por el xsace 08.01.2012 - 10:41

Lea otras preguntas en las etiquetas