Un modelo exitoso de branches no Git

Saber utilizar o Git é importante, e isto inclúe manter un ambiente de colaboración de desenvolvemento de software gerenciável.

Créditos

Este post é unha versión en portugués do orixinal, en Inglés, “Un modelo de ramificación GIT éxito“, debidamente autorizado polo autor, Vincent Driessen. Grazas home!

Por cuestións técnicas, algunhas palabras clave foron propositalmente mantidas en inglés. Tente garantir a orixinalidade do texto, pero confeso que precisei facer axustes para facilitar a comprensión no noso idioma (Gl). Calquera corrección ou suxestión de mellora na tradución é benvida.

introdución

Este non é un post ensinando a usar o Git. Se isto é o que ten que, suxiro dar un ollo no Manual do Git. Tampouco é o noso obxectivo mostrar como se fai un versionamento de software, neste caso, vexa versionamento semántico.

Aquí a proposta é xestionar a colaboración do equipo no versionamento de software. Sabe cando ten varios programadores “mexendo” nun mesmo código fonte? Isto é importante para axilizar o desenvolvemento, pero pode xerar inmensa dor de cabeza (prexuízo e retraballados) se non hai un control. Para evitar que un creador sobrescreva o traballo de outro e garantir un desenvolvemento progresivo e organizado, minimizando os conflitos e xestionado versións do software, é que utilizamos o Git e o modelo de ramos a continuación.

Modelo de branches

Neste post presento o modelo de desenvolvemento que utilicei en algúns dos meus proxectos (tanto no traballo como particular) preto 1 anos, e que foi moi exitoso. Fai tempo que quería escribir sobre iso, pero nunca encontraba un horario dispoñible, ata agora. Non vou falar detalles de deseño, só sobre estratexias de ramos e xestión de lanzamentos.

Este modelo non só selo GIT como ferramenta para versionamento de todo o noso código fonte. (A propósito, Se che interesa na Git, A nosa empresa GitPrime ofrece, en tempo real, algunhas incribles análise de datos para optimización da enxeñaría de software)

que git?

Para unha minuciosa discusión sobre os pros e contras do Git comparado aos sistemas de control de código fonte central, vexa un tea. Hai unha tremenda “guerra” en torno a iso. como creador, Prefiro o Git en relación a todas outras ferramentas existentes hoxe. O Git sen dúbida cambiou a forma dos desenvolvedores pensaren en facer un fundir ou crear unha sector. Eu veño do clásico mundo do CVS / Subversion, onde fusión / ramificación é algo que só fai de cando en vez e sempre parece un pouco asustado (“Coidado cos conflitos de fundir, te morden!”).

Xa co Git estas accións [fusión / ramificación] son moi simples e representan unha das principais partes da nosa rutina de traballo, crea. por exemplo, non libro CSV / Subversion, ramificados e fusión son abordados por primeira vez só nos capítulos posteriores (para usuarios avanzados), mentres que en calquera libro sobre Git, isto é visto no capítulo 3 (básico).

Como consecuencia da súa sinxeleza e natureza repetitiva, ramificados e fusión non son máis algo para ter medo. en realidade, as ferramentas de control de versións deberían axudar a facerfundir e crear sector máis do que calquera outra cousa.

Chega de conversa, imos ao modelo de desenvolvemento. O modelo que irei presentar aquí é esencialmente nada máis que un conxunto de procedementos que cada membro do equipo debe seguir a fin de chegar a un proceso de desenvolvemento de software xestionado.

descentralizada, máis centralizado

A configuración do repositorio que utilizamos e que funciona moi ben con este modelo de ramificados está composta por un repositorio central. Teña en conta que este repositorio é só “tido como” central (pois o Git é un DVCS [Sistemas de control de versións distribuído], é dicir, non hai nada como un repositorio central a nivel técnico). Nós iremos referenciar este repositorio como orixe, xa que este nome é familiar a todos os usuarios Git.

Cada desenvolvedor fai tira e empurra ao orixe. Pero ademais da relación push-pull ao Central [orixe], cada desenvolvedor pode incorporarse [tirar] os cambios de outros compañeiros para formar subequipes. por exemplo, Isto pode ser útil para traballar xunto con dous ou máis desenvolvedores nunha nova gran función, anteriormente o envío [empurrando] o traballo en progreso ao orixe. Na figura anterior, existen as subequipes de Alicia e Bob, Alicia e David, e Clair e David.

tecnicamente, Isto significa nada máis que Alicia definiu un Git remoto chamado Bob, apuntando para o depósito de Bob, e viceversa.

As principais branches

no fondo, este modelo de desenvolvemento é moi inspirado por modelos existentes por aí. O repositorio central posúe dúas ramas [ramos] principais cunha vida infinita:

  • mestre
  • desenvolver

O mestre sector en orixe debe ser familiar a todo usuario Git. paralelo ao mestre sector, hai outro sector chamado desenvolver.

consideramos Origin / Master como sendo o branch principal onde o código fonte de CABEZA sempre reflicte un estado listo para produción [listo para produción].

consideramos orixe / desenvolver como o sector principal onde o código fonte de CABEZA sempre reflicte un estado coas recentes cambios de desenvolvemento a seren entregadas na próxima versión. Algúns chamarían tanto de “sector de integración”. Aí é onde os máis sinistras construcións acontecen.

Cando o código fonte no rama desenvolver alcanza un punto estable e está listo para ser lanzado [lanzado], todos os cambios deben ser mescladas [fundiu] ao seu mestre sector e despois marcados cun número de versión [lanzamento]. Como iso é facer en detalle, será discutido máis adiante.

Polo tanto, cada vez que os cambios son incorporadas [fundiu] de volta ao mestre, xérase unha nova versión [lanzado], por definición. Nós buscamos ser moi rigorosos niso, entón, teoricamente, poderiamos ata usar un script gancho do Git para crear e enviar automaticamente nosa aplicación para os servidores de produción cando haxa un cometer non mestre.

ramos auxiliares

Á beira das ramos principais, mestre e desenvolver, noso modelo de desenvolvemento usa unha variedade de ramos de apoio para auxiliar o desenvolvemento simultáneo entre os integrantes do equipo, o que 1) facilita o seguimento de novas [características], 2) prepárase para entrega dunha nova versión [lanzamento] e 3) axuda a rapidamente corrixir fallos en produción [hotfix]. A diferenza dos ramos principais, estes ramos ten un tempo de vida curto, xa que finalmente serán eliminados.

Os distintos tipos de ramos [auxiliar] que podemos utilizar