Úspěšný model větve v systému Git

Chcete-li použít Git je důležité, a to včetně zachování společné vývojové prostředí pro software zvládnutelné.

Kredity

Tento příspěvek je portugalská verze původního, V angličtině, “Úspěšný model větvení Git“, řádně autorem, Vincent Driessen. Děkuji vám muž!

Z technických důvodů, některá klíčová slova byla záměrně uchovávána v angličtině. Snažil jsem se zajistit originalitu textu, ale přiznávám, že jsem musel provést úpravy, abych usnadnil porozumění v našem jazyce (EN-BR). Jakákoli oprava nebo návrh na zlepšení překladu je vítán.

Úvod

Toto není post výuky, jak používat Git. Pokud je to to, co potřebujete, navrhnout, aby se podíval na Ruční dělat Git. Také není naším cílem ukázat, jak vytvořit verzi softwaru, v tomto případě, viz Sémantické správy verzí.

Zde je návrh řídit spolupráci týmu v oblasti správy verzí softwaru. Víte, když máte více programátorů “Míchání” ve stejném zdrojovém kódu? To je důležité pro urychlení rozvoje, ale to může generovat hodně bolesti hlavy (zranění a přepracování) pokud není k dispozici žádná kontrola. Aby se zabránilo přepsání práce jiného uživatele a zajištění progresivního a organizovaného vývoje, minimalizace konfliktů a správa verzí softwaru, je, že používáme Git a Poboček pak.

Model poboček

V tomto příspěvku jsem představit vývojový model jsem použil v některých mých projektech (jak v práci, tak v soukromí) O 1 Lety, a to bylo velmi úspěšné. Chtěl jsem o tom psát už dlouho., mas nunca encontrava um horário disponível, até agora. Não vou falar sobre detalhes de projeto, apenas sobre estratégias de Poboček e gerenciamento de releases.

Este modelo foca exclusivamente no Git como ferramenta para versionamento de todo nosso código-fonte. (A propósito, se você está interessado no Git, nossa empresa GitPrime fornece, v reálném čase, algumas incríveis análises de dados para otimização da engenharia de software)

Por que git?

Para uma minuciosa discussão sobre os prós e contras do Git comparado aos sistemas de controles de código-fonte centralizado, viz v web. Há uma tremendaguerraem torno disso. Como desenvolvedor, prefiro o Git em relação a todas outras ferramentas existentes hoje. O Git sem dúvida mudou a forma dos desenvolvedores pensarem em fazer um Sloučit ou criar uma větev. Eu venho do clássico mundo do CVS/Subversion, kde merging/branching é algo que você só faz de vez em quando e sempre parece um pouco assustador (“Cuidado com os conflitos de Sloučit, eles te mordem!”).

Já com o Git estas ações [merging/branching] são extremamente simples e representam uma das principais partes da nossa rotina de trabalho, acredite. Například, v livro CSV/Subversion, branching a merging são abordados pela primeira vez apenas nos capítulos posteriores (para usuários avançados), enquanto em qualquer livro sobre Git, isso é visto no capítulo 3 (básico).

Como consequência de sua simplicidade e natureza repetitiva, branching a merging não são mais algo para se ter receio. Ve skutečnosti, as ferramentas de controle de versão deveriam ajudar a fazerSloučit e criar větev mais do que qualquer outra coisa.

Chega de conversa, Pojďme na vývojový model. Model, který zde představím, není v podstatě nic jiného než soubor postupů, které musí každý člen týmu dodržovat, aby přišel s procesem vývoje spravovaného softwaru..

Decentralizované, ale centralizované

Konfigurace úložiště, které používáme a který funguje velmi dobře s tímto modelem branching se skládá z centrálního úložiště. Všimněte si, že toto úložiště je pouze “Považován za” Centrální (protože Git je DVCS [Distribuované systémy správy verzí], IE, neexistuje nic jako centrální úložiště na technické úrovni). Na toto úložiště budeme odkazovat jako na Původu, protože tento název je známý všem uživatelům Gitu.

Každý vývojář Táhne a Tlačí pro Původu. Mas além da relação push-pull para o centralizado [Původu], cada desenvolvedor pode também pegar [pull] as mudanças de outros pares para formar subequipes. Například, isto pode ser útil para trabalhar junto com dois ou mais desenvolvedores em uma nova grande funcionalidade, previamente enviando [pushing] o trabalho em progresso para o Původu. Na figura acima, existem as subequipes de Alice e Bob, Alice e David, e Clair and David.

Tecnicamente, isto significa nada mais que Alice definiu um Git remoto chamado Bob, apontando para o repositório de Bob, e vice-versa.

As principais branches

No fundo, este modelo de desenvolvimento é bastante inspirado por modelos existentes por aí. O repositório central possui dois ramos [Poboček] principais com uma vida infinita:

  • mistr
  • vyvinout

V branch master v Původu deve ser familiar a todo usuário Git. Paralelo a branch master, existe um outro větev chamado vyvinout.

Consideramos origin/master como sendo o branch principal onde o código fonte de HEAD sempre reflete um estado production-ready [pronto para produção].

Consideramos origin/develop como sendo o větev principal onde o código fonte de HEAD sempre reflete um estado com as mais recentes mudanças de desenvolvimento a serem entregues na próxima versão. Alguns chamariam isso devětev de integração”. Aí é onde as mais sinistras construções acontecem.

Quando o código fonte no branch develop alcança um ponto estável e está pronto para ser lançado [released], todas as mudanças devem ser mescladas [merged] de volta para o branch master e depois marcados com um número de versão [vydání]. Como isso é feito em detalhes, será discutido mais adiante.

Tak, cada vez que as alterações são incorporadas [merged] de volta ao mistr, é gerada uma nova versão [released], por definição. Nós procuramos ser bastante rigorosos nisso, Tak, teoricamente, poderíamos até usar um script hook do Git para criar e enviar automaticamente nossa aplicação para os servidores de produção sempre que houver um commit v mistr.

Branches auxiliares

Ao lado das Poboček principais, mistr a vyvinout, nosso modelo de desenvolvimento usa uma variedade de Poboček de apoio para auxiliar o desenvolvimento simultâneo entre os integrantes da equipe, o que 1) facilita o rastreamento de novas funcionalidades [features], 2) prepara para entrega de uma nova versão [vydání] a 3) ajuda a rapidamente corrigir falhas em produção [hotfix]. Diferentemente dos Poboček principais, estes Poboček tem um tempo de vida curto, já que eventualmente serão removidos.

Os diferentes tipos de Poboček [auxiliares] que podemos usar, são:

  • Feature branches
  • Release branches
  • Hotfix branches

Cada um desses Poboček tem um propósito específico e está vinculado à regras rígidas, de modo que, Poboček podem dar origem a větev e que Poboček devem ser mesclados [merged] a seus alvos. Nós veremos cada um deles [Poboček] em um instante.

Sob uma perspectiva técnica, esses Poboček não são consideradosespeciais”. Cada tipo de větev é categorizado pela forma como os usamos. Každopádně, são apenas simples Poboček do velho e bom Git.

Feature branches

[Features = recursos/funcionalidades]

Pode se ramificar [větev] a partir de:
vyvinout
Deve mesclar-se [Sloučit] novamente a:
vyvinout
Convenção de nomeação do větev:
Qualquer coisa, exceto mistr, vyvinout, release-*, or hotfix-*

Os feature branches (ou às vezes chamados de topic branches) são usados para desenvolver novos recursos/funcionalidades para uma versão próxima ou futura. Ao iniciar o desenvolvimento de uma feature, a versão alvo em que esse recurso será incorporado pode muito bem ser desconhecida nesse ponto.

A essência de um feature branches é que ele existe enquanto a feature estiver em desenvolvimento, mas eventualmente será incorporado [merged] de volta ao vyvinout (para adicionar definitivamente a nova feature ao próximo vydání) ou descartado (no caso de uma experiência mal sucedida).

Feature branches tipicamente existem apenas no repositório vyvinout, não em Původu.

Criando uma feature branches

$ git checkout -b myfeature develop
# Switched to a new branch "myfeature"

Incorporando uma feature finalizada no develop

Features finalizadas podem ser mescladas[merged] com a branch develop para adicioná-las definitivamente ao próximo vydání.

$ git checkout develop
# Switched to branch 'develop'
$ git merge --v-ff myfeature
# Updating ea1b82a..05e9557
# (Summary of changes)
# $ git branch -d myfeature
# Deleted branch myfeature (was 05e9557).
$ git push původ rozvíjet

Vlajka –ne-ff způsobí sloučení [Sloučit] vždy vytvořit nový objekt commit, i když sloučení by mohlo být provedeno rychlé převícení vpřed [Ff]. Tím se zabrání tomu, aby byly ztraceny informace o historii existence větev funkcí, seskupení všech Potvrdí které byly přidány do feature. Porovnat:

V posledně uvedeném případě [z výše uvedeného obrázku], z historie gitu není možné vidět, který z Potvrdí byly provedeny v rámci feature; budete muset ručně číst všechny zprávy protokolu. Obrátit a feature Celý (IE, skupina Potvrdí), je to skutečná bolest hlavy v poslední situaci, zatímco je to snadné, pokud vlajka –ne-ff byl použit.

Ano, tím vzniknou několik dalších objektů Potvrdí (Prázdné), ale zisk je mnohem vyšší než náklady.

Release branches

[Release = lançamento/entrega/versão]

Pode se ramificar [větev] a partir de:
vyvinout
Deve mesclar-se [Sloučit] novamente a:
vyvinout a mistr
Convenção de nomeação do větev:
release-*

Os releases branches ajudam na preparação de uma nova versão de produção [production release]. Eles permitem colocar os pingos nos i’s de última hora. Navíc, eles permitem pequenas correções de bugs e definição de meta-dados para uma vydání (número de versão, datas de compilação, atd). Ao fazer todo esse trabalho em um release branch, v develop branch fica limpo para receber features da próxima grande vydání [verze].

O momento chave para se criar uma nova release branch ramificando de vyvinout é quando o vyvinout já está (quase) refletindo o estado desejado da nova vydání [verze]. Todas as features candidatas ao vydání a ser construído devem ser incorporados [Sloučit] v vyvinout neste momento. Já os features voltados para releases futuros devem esperar uma próxima vydání [verze].

É exatamente no início de um release branch que o próximo vydání recebe um número de versãonão antes. Até esse momento, v develop branch refletiu alterações para onext release” [próxima versão], mas não está claro se essapróxima versãoacabará por ser 0.3 nebo 1.0, até que o release branch seja iniciado. Essa decisão é tomada no início do release branch e é realizada pelas regras do projeto sobre versionamento [sugiro ver sobreSémantické správy verzí“].

Criando um release branch

Os releases branches são criados a partir do develop branch. Například, digamos que a versão 1.1.5 é a atual versão de produção e temos uma grande vydání chegando. O estado de vyvinout está pronto para apróxima versão” [next release] e decidimos que isso se tornaria a versão 1.2 (em vez de 1.1.6 nebo 2.0). Tak, nós nos ramificamos e damos ao release branch um nome refletindo o novo número de versão:

$ git checkout -b release-1.2 vyvinout
# Switched to a new branch "release-1.2"
$ ./bump-version.sh 1.2
# Files modified successfully, version bumped to 1.2.
$ git commit -v -m "Bumped version number to 1.2"
# [release-1.2 74d9424] Číslo bumped verze 1.2
# 1 Změněné soubory, 1 Vložení(+), 1 Odstranění(-)

Po vytvoření nového větev a přistupovat k němu, jsme narazili na číslo verze. Tady, bump-version.sh je skript prostředí, který mění některé soubory pracovní kopie tak, aby odrážely novou verzi. (To může, Samozřejmě, být ruční změna – Jde o to, že některé soubory se mění.) Tak, se provádí commit upraveného čísla verze.

Tento nový větev může existovat tam na chvíli, dokud nebude vydání být spuštěna trvale. Během tohoto období, opravy chyb mohou být použity v tomto větev (místo develop branch). Přidání nových a velkých features zde je přísně zakázáno. Musí být sloučeny [merged] v vyvinout a, Nějak tak, čekat na další velký vydání.

Dokončení větve vydání

Když se release branch está pronto para se tornar uma versão real, algumas ações precisam ser realizadas. Primeiro, v release branch é mesclado em mistr (uma vez que cada commit v mistr é uma nova versão por definição, lembre-se). Em seguida, esse commit v mistr deve ser marcado para facilitar uma futura referência a este histórico de versões. Nakonec, as mudanças feitas no release branch precisam ser mescladas [merged] novamente para vyvinout, de modo que os releases futuros também contenham essas correções de bugs.

As duas primeiras etapas no Git:

$ git checkout master
# Switched to branch 'master'
$ git merge --v-ff release-1.2
# Merge made by recursive.
# (Summary of changes)
$ git tag -v 1.2

V vydání agora está concluído e marcado para futura referência.

Poznámka:: você também pode usar as flags -s ou -u para assinar sua tag criptograficamente.

Para manter as mudanças feitas no release branch, precisamos juntá-las de volta ao vyvinout. No Git:

$ git checkout develop
# Switched to branch 'develop'
$ git merge --v-ff release-1.2
# Merge made by recursive.
# (Summary of changes)

Este passo pode levar a um conflito de mesclagem (provavelmente vá, uma vez que mudamos o número da versão). Em caso afirmativo, conserte e faça o commit.

Teď, que realmente terminamos, v release branch pode ser removido, já que não precisaremos mais dele:

$ git branch -d release-1.2
# Deleted branch release-1.2 (was ff452fe).

Hotfix branches

Pode se ramificar [větev] a partir de:
mistr
Deve mesclar-se [Sloučit] novamente a:
vyvinout a mistr
Convenção de nomeação do větev:
hotfix-*

Os Hotfix branches são muito parecidos com os release branches, pois eles também se destinam a preparar uma nova versão de produção, embora não planejada. Eles surgem da necessidade de agir imediatamente após um estado não desejado de uma versão de produção [em uso]. Quando ocorre um erro crítico em uma versão de produção, deve ser resolvido imediatamente, então um hotfix branch lze odvodit ze značky, která označuje stávající výrobní verzi v hlavní větev.

Podstatou je, že práce členů týmu (v develop branch) může pokračovat, zatímco někdo jiný připravuje rychlou opravu selhání výroby.

Vytvoření větve opravy hotfix

Os větve oprav hotfix são criados a partir do hlavní větev. Například, za předpokladu, že verze 1.2 je aktuální verze produkční verze spuštěna a představuje problémy z důvodu vážné chyby. Změny v vyvinout ponechejte stále nestabilní. Poté můžeme větev hotfix branch a začít řešit problém:

$ git checkout -b oprava hotfix-1.2.1 mistr
# Switched to a new branch "hotfix-1.2.1"
$ ./bump-version.sh 1.2.1
# Files modified successfully, version bumped to 1.2.1.
$ git commit -v -m "Bumped version number to 1.2.1"
# [oprava hotfix-1.2.1 41e61bb] Číslo bumped verze 1.2.1
# 1 Změněné soubory, 1 Vložení(+), 1 Odstranění(-)

Não esqueça de trocar o número da versão após a ramificação!

Em seguida, corrija o erro e faça o commit da correção em um ou mais commit separados.

$ git commit -m "Fixed severe production problem"
# [hotfix-1.2.1 abbe5d6] Fixed severe production problem
# 5 Změněné soubory, 32 Vložení(+), 17 Odstranění(-)

Finalizando um hotfix branch

Quando terminado, v bugfix precisa ser mesclado de volta ao mistr, mas também precisa ser incorporado novamente para vyvinout, a fim de garantir que o bugfix também esteja incluído na próxima versão. Isso é bastante semelhante ao modo como as release branches são finalizadas.

Primeiro, atualize o mistr e tag a vydání [marque a verão]:

$ git checkout master
# Switched to branch 'master'
$ git merge --v-ff hotfix-1.2.1
# Merge made by recursive.
# (Summary of changes)
$ git tag -v 1.2.1

Poznámka:: você também pode usar as flags -s ou -u para assinar sua tag criptograficamente.

Em seguida, inclua o bugfix v vyvinout rovněž:

$ git checkout develop
# Switched to branch 'develop'
$ git merge --v-ff hotfix-1.2.1
# Merge made by recursive.
# (Summary of changes)

A única exceção à regra aqui é que, quando existir um release branch em andamento, as mudanças de hotfix precisam ser mescladas para esse release branch, ao invés de vyvinout. Mesclar o bugfix v release branch irá fazer com que o bugfix seja mesclado no vyvinout rovněž, quando o release branch for concluído. (Se o trabalho no vyvinout requer imediatamente esse bugfix e não puder esperar até que o release branch seja concluído, você pode seguramente mesclar o bugfix pro deveolp também.)

Nakonec, remova a větev temporária:

$ git branch -d hotfix-1.2.1
# Deleted branch hotfix-1.2.1 (was abbe5d6).

Resumo

Embora não haja nada realmente extraordinário neste modelo de ramificação, a figura no início do Post pode ser muito útil em nossos projetos. Ela mostra um modelo mental fácil de compreender e permite aos membros da equipe desenvolver um entendimento comum dos processos de branching a releasing.

Uma versão em PDF de alta qualidade da figura é fornecida no blog do post original: http://nvie.com/posts/a-successful-git-branching-model/ [ou no link de Download abaixo]. Vá em frente e coloque-o na parede para obter uma rápida referência a qualquer momento.

Celkový počet přístupů: 8843

Komentář k “Úspěšný model větve v systému Git

  1. Deivson Nascimento řekl:

    Dobré odpoledne, sei que o Git foi desenvolvido inicialmente pelo sistema Linux mas ao se falar em portabilidade, gostaria de saber se o Git roda no windows MSIS e POSIX??

Zanech odpověď

Vaše e-mailová adresa nebude zveřejněna. Povinná pole jsou označena *