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, son:

  • ramas especiais
  • ramos de liberación
  • ramos de hotfix

Cada un destes ramos ten un propósito específico e está vinculado á regras ríxidas, de xeito que, ramos poden dar orixe a sector e que ramos deben mesclados [fundiu] a os seus obxectivos. Nós imos ver cada un deles [ramos] nun instante.

Baixo unha perspectiva técnica, estes ramos non se consideran “especiais”. Cada tipo de sector é categorizado por como os utilizamos. En fin, son só simples ramos do vello e bo Git.

ramas especiais

[Features = recursos/funcionalidades]

– Pode ramifican [sector] de:
desenvolver
– Debe mesturar-se [fundir] de novo a:
desenvolver
– Convención de nomeamento do sector:
algo, excepto mestre, desenvolver, release- *, ou hotfix- *

os ramos de novas características (ou ás veces chamados de ramos tema) son usados ​​para desenvolver novas características / funcionalidades a unha versión próxima ou futura. Ao iniciar o desenvolvemento dunha característica, a versión obxectivo no que este recurso será incorporado pode moi ben ser descoñecida nese punto.

A esencia dun ramos de novas características é que existe mentres a característica está en desenvolvemento, pero acabará por ser incorporados [fundiu] de volta ao desenvolver (para engadir definitivamente o novo característica ao seguinte lanzamento) ou descartado (no caso dunha experiencia mal sucedida).

ramas especiais tipicamente hai só no repositorio desenvolver, non en orixe.

Creando unha feature branches

$ GIT checkout -b MyFeature desenvolver
# Switched to a new branch "myfeature"

Incorporando unha feature finalizada no DEVELOP

características finalizadas poden mescladas[fundiu] coa rama desenvolver para engadila los definitivamente ao seguinte lanzamento.

$ GIT checkout desenvolver
# Conmutada en rama 'desenvolver'
$ GIT go --non-MyFeature ff
# Actualizando ea1b82a..05e9557
# (Resumo dos cambios)
# $ MyFeature GIT branch -d
# Excluídos MyFeature sector (foi 05e9557).
$ GIT push origin desenvolver

unha bandeira –no-FF fai que a combinación [fundir] sempre cree un novo obxecto de cometer, aínda que a combinación puidese ser executada cunha Fast-forward [ff]. Isto evita que se perda información acerca do historial da existencia dunha ramo de recurso, agrupando as comprométese que foron engadidos á característica. comparar:

No último caso [da figura anterior], é imposible ver a partir do historial do Git cales dos comprométese foron aplicados dentro dunha característica; que tería que ler manualmente todas as mensaxes de log. reverter unha característica enteira (é dicir, un grupo de comprométese), é unha verdadeira dor de cabeza na última situación, mentres que é facilmente feito a flag –no-FF ten sido usada.

Si, isto creará uns obxectos de comprométese (baleiros), pero a ganancia é moito maior que o custo.

ramos de liberación

[Release = lanzamento / entrega / versión]

– Pode ramifican [sector] de:
desenvolver
– Debe mesturar-se [fundir] de novo a:
desenvolver e mestre
– Convención de nomeamento do sector:
release- *

os libera ramas axudan na preparación dunha nova versión de produción [versión de produción]. Eles permiten poñer os pingos nos i 's de última hora. ademais, Permiten pequenas correccións de erros e definición de metadatos para unha lanzamento (número de versión, Datas de compilación, etc). Ao facer todo este traballo nun rama release, o desenvolver sector queda limpo para recibir características da próxima gran lanzamento [versión].

O momento clave para crear unha rama release ramificación de desenvolver é cando o desenvolver xa está (case) que era o estado desexado da nova lanzamento [versión]. todas as características candidatas ao lanzamento a ser construído deben ser incorporados [fundir] ao desenvolver Actualmente. xa os características dirixidos a lanzamentos futuros deben esperar unha próxima lanzamento [versión].

É exactamente o inicio dun rama release que o seguinte lanzamento recibe un número de versión – non antes. Ata ese momento, o desenvolver sector reflectiu cambios ao “próximo lanzamento” [seguinte versión], pero non está claro se esta “seguinte versión” acabará por ser 0.3 ou 1.0, ata que o rama release se inicie. Esta decisión é tomada a principios do rama release e é realizada polas regras do proxecto sobre versionamento [suxiro ver sobre “versionamento semántico“].

Creando un release branch

os libera ramas son creados a partir do desenvolver sector. por exemplo, digamos que a versión 1.1.5 é a actual versión de produción e temos unha gran lanzamento chegando. O estado de desenvolver Está preparado para a “seguinte versión” [próximo lanzamento] e decidimos que iso se tornaría a versión 1.2 (no canto de 1.1.6 ou 2.0). entón, Nós nos ramificamos e damos ao rama release un nome que era o novo número de versión:

$ GIT checkout -liberación b-1.2 desenvolver
# Switched to a new branch "release-1.2"
$ ./chocar-versión.sh 1.2
# Arquivos modificados con éxito, versión adiado para 1.2.
$ GIT commit -un -m "Bumped version number to 1.2"
# [liberarse 1,2 74d9424] número de versión adiado para 1.2
# 1 arquivos modificados, 1 insercións(+), 1 eliminacións(-)

Despois de crear un novo sector e acceder a ela, nos esbarramos no número de versión. aquí, bump-version.sh é un script shell Visto algúns arquivos da copia de traballo para reflectir a nova versión. (isto pode, claro, ser un cambio manual – A cuestión é que algúns arquivos cambian.) entón, faise o cometer do número de versión modificada.

este novo sector pode existir alí por un tempo, ata que a lanzamento sexa lanzada definitivamente. Durante este período, correccións de erros poden aplicar neste sector (no canto do desenvolver sector). A adición de novos e grandes características aquí é estrictamente prohibida. Deben ser mezclado [fundiu] en desenvolver e, así, agardar o próximo gran lanzamento.

Finalizando un release branch

cando o rama release Está preparado para facer unha versión real, algunhas accións teñen que ser realizadas. primeiro, o rama release é mezclado en mestre (xa que cada cometer non mestre é unha nova versión por definición, Teña en conta que). axiña, este cometer non mestre debe ser marcado para facilitar unha futura referencia a este historial de versións. finalmente, os cambios realizados no rama release teñen que ser mescladas [fundiu] de novo para desenvolver, de xeito que os lanzamentos futuros tamén conteñen estas correccións de erros.

As dúas primeiras etapas no Git:

$ mestre GIT checkout
# Conmutada para ramifican 'Master'
$ GIT go --non-liberación ff-1.2
# Fusión tomada polos recursiva.
# (Resumo dos cambios)
$ tag GIT -un 1.2

O lanzamento agora está concluído e marcado para futura referencia.

observación: Tamén pode usar as flags -s ou -u para asinar a súa etiqueta criptograficamente.

Para manter os cambios realizados no rama release, necesitamos xuntalas de volta ao desenvolver. non Git:

$ GIT checkout desenvolver
# Conmutada en rama 'desenvolver'
$ GIT go --non-liberación ff-1.2
# Fusión tomada polos recursiva.
# (Resumo dos cambios)

Este paso pode levar a un conflito de mesclagem (probablemente vaia, xa que cambiamos o número de versión). En caso afirmativo, repare e faga o cometer.

agora, realmente acabamos, o rama release pode ser eliminado, xa que non necesitaremos máis del:

$ GIT branch -liberación d-1.2
# Excluídos liberación-1,2 sector (foi ff452fe).

ramos de hotfix

– Pode ramifican [sector] de:
mestre
– Debe mesturar-se [fundir] de novo a:
desenvolver e mestre
– Convención de nomeamento do sector:
hotfix- *

os ramos de hotfix son moi parecidos os ramos de liberación, xa que tamén se destina a preparar unha nova versión de produción, aínda que non planificada. Xorden da necesidade de actuar inmediatamente despois dun estado non desexado dunha versión de produción [en uso]. Cando ocorre un erro crítico nunha versión de produción, debe ser resolto inmediatamente, entón un branch hotfix pode ser derivado da etiqueta que marca a versión de produción existente no branch master.

A esencia é que o traballo dos membros do equipo (non desenvolver sector) pode continuar, mentres outra persoa está a preparar unha rápida corrección do fallo en produción.

Creando o hotfix branch

os ramos de hotfix son creados a partir do branch master. por exemplo, supoñendo que a versión 1.2 é a versión actual da release de produción rodando e presenta problemas debido a un erro grave. cambios no desenvolver deixan o aínda inestable. Podemos entón ramifican un branch hotfix e comezar a solucionar o problema:

$ GIT checkout -hotfix b-1.2.1 mestre
# Switched to a new branch "hotfix-1.2.1"
$ ./chocar-versión.sh 1.2.1
# Arquivos modificados con éxito, versión adiado para 1.2.1.
$ GIT commit -un -m "Bumped version number to 1.2.1"
# [hotfix-1.2.1 41e61bb] número de versión adiado para 1.2.1
# 1 arquivos modificados, 1 insercións(+), 1 eliminacións(-)

Non esqueza de cambiar o número de versión trala ramificación!

axiña, corrixa o erro e faga o cometer da corrección nunha ou máis cometer separado.

$ GIT commit -m "Fixed severe production problem"
# [hotfix-1.2.1 abbe5d6] Corrixido problema de produción grave
# 5 arquivos modificados, 32 insercións(+), 17 eliminacións(-)

Finalizando un hotfix branch

cando termine, o bugfix Debe ser mezclado de volta ao mestre, pero tamén ten que ser incorporado de novo para desenvolver, a fin de garantir que o bugfix Tamén está incluído na próxima versión. Isto é moi semellante a como as ramos de liberación son finalizadas.

primeiro, Actualiza o mestre e etiqueta lanzamento [Seleccione a verán]:

$ mestre GIT checkout
# Conmutada para ramifican 'Master'
$ GIT go --non-hotfix ff-1.2.1
# Fusión tomada polos recursiva.
# (Resumo dos cambios)
$ tag GIT -un 1.2.1

observación: Tamén pode usar as flags -s ou -u para asinar a súa etiqueta criptograficamente.

axiña, inclúa o bugfix non desenvolver tamén:

$ GIT checkout desenvolver
# Conmutada en rama 'desenvolver'
$ GIT go --non-hotfix ff-1.2.1
# Fusión tomada polos recursiva.
# (Resumo dos cambios)

A única excepción á regra aquí é que, cando exista un rama release en marcha, os cambios de hotfix teñen que ser mescladas para ese rama release, ao contrario de desenvolver. mesturar o bugfix non rama release ha facer que o bugfix sexa mesclado no desenvolver tamén, cando o rama release remate. (Se o traballo no desenvolver require inmediatamente ese bugfix e non pode esperar a que o rama release sexa completado, pode seguramente mesturar o bugfix para deveolp tamén.)

finalmente, retire a sector temporal:

$ GIT branch -hotfix d-1.2.1
# rama eliminado corrección-1.2.1 (foi abbe5d6).

resumo

Aínda que non haxa nada realmente extraordinario neste modelo de ramificación, a figura ao comezo do post pode ser moi útil nos nosos proxectos. Ela mostra un modelo mental doado de entender e permite aos membros do equipo desenvolver un entendemento común dos procesos de ramificados e liberando.

Unha versión en PDF de alta calidade da figura é proporcionada no blog do post orixinal: http://nvie.com/posts/a-successful-git-branching-model/ [ou na ligazón de descarga a continuación]. Dalle coloque o na parede para obter unha rápida referencia en calquera momento.

Total de accesos: 8921

Un comentario sobre “Un modelo exitoso de branches no Git

  1. Deivson Nacemento dixo:

    boa tarde, sei que o Git foi desenvolvido inicialmente polo sistema Linux pero ao falar en portabilidade, Quere saber se o Git roda en Windows MSIS e POSIX??

Deixe unha resposta

O seu enderezo de correo-e non será publicado. Os campos obrigatorios están marcados con *