Ú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., ale nikdy nenašel dostupný čas, dosud. Nebudu mluvit o detailech projektu., jen o strategiích Poboček a řízení Uvolňuje.

Tento model se zaměřuje výhradně na Lotr jako nástroj pro správu verzí všech našich zdrojových kódů. (Mimochodem, Pokud máte zájem o git, naše společnost Gitprime Poskytuje, v reálném čase, některé úžasné analýzy dat pro optimalizaci softwarového inženýrství)

Proč git?

Pro důkladnou diskusi o výhodách a nevýhodách Gitu ve srovnání s centralizovanými systémy správy zdrojového kódu, viz v web. Je tu ohromná “válka” kolem toho. Jako vývojář, Dávám dnes přednost Gitu před všemi ostatními existujícími nástroji. Git nepochybně změnil způsob, jakým vývojáři uvažují o vytvoření Sloučit nebo vytvořit větev. Pocházím z klasického světa CVS/Podvracení, kde sloučení/větvení je to něco, co děláte jen jednou za čas a vždy se zdáte trochu děsiví (“Dejte si pozor na konflikty Sloučit, kousnou vás!”).

S Gitem tyto akce [sloučení/větvení] jsou velmi jednoduché a představují jednu z hlavních částí naší pracovní rutiny, Věřit. Například, v kniha CSV/Podvracení, větvení a Slučování jsou poprvé řešeny pouze v pozdějších kapitolách (pro pokročilé uživatele), zatímco v jakémkoli rezervovat na Gitu, to je vidět v kapitole 3 (základní).

V důsledku své jednoduchosti a opakující se povahy, větvení a Slučování už nejsou něco, čeho by se měli bát. Ve skutečnosti, nástroje pro správu verzí by měly pomociSloučit a vytvářet větev více než cokoli jiného.

Už žádné mluvení, 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 větvení 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, cílová verze, do které bude tato funkce začleněna, nemusí být v tomto okamžiku známa.

Podstata feature branches je, že existuje, pokud feature je ve vývoji, ale nakonec bude začleněna [merged] de volta ao vyvinout (definitivně přidat nové feature na další vydání) nebo vyřazeny (v případě neúspěšného pokusu).

Feature branches obvykle existují pouze v úložišti vyvinout, ne v Původu.

Vytvoření větví funkcí

$ git checkout -b rozvíjet myfeature
# Switched to a new branch "myfeature"

Začlenění hotové funkce do vývoje

Rysy dokončené lze sloučit[merged] s branch develop určitě je přidat do dalšího vydání.

$ git checkout rozvíjet
# Převedeno na větev "rozvíjet"
$ git merge --v-ff myfeature
# Aktualizace ea1b82a.. 05e9557
# (Shrnutí změn)
# $ git branch -d myfeature
# Odstraněná větev myfeature (byl 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á (Téměř) 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 Uvolňuje 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. první, 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 Uvolňuje 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.
# (Shrnutí změn)
$ 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.

Aby byly změny provedené v release branch, Musíme je dát zase dohromady. vyvinout. Ve společnosti Git:

$ git checkout rozvíjet
# Převedeno na větev "rozvíjet"
$ git merge --v-ff release-1.2
# Merge made by recursive.
# (Shrnutí změn)

Tento krok může vést ke konfliktu sloučení (pravděpodobně jít, jakmile změníme číslo verze). Pokud ano,, opravit a provést commit.

Teď, že jsme opravdu skončili, v release branch lze odstranit, protože už to nebudeme potřebovat:

$ git větev -d uvolnění-1.2
# Odstraněná verze větve-1.2 (byl 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 jsou velmi podobné uvolněte pobočky, protože jsou také určeny k přípravě nové produkční verze, i když neplánované. Vyplývají z potřeby jednat bezprostředně po nežádoucím stavu produkční verze [používaný]. Když dojde k kritické chybě v produkční verzi, by měly být okamžitě vyřešeny, pak Větev opravy hotfix 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 Větev opravy hotfix 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 uvolněte pobočky são finalizadas.

první, 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.
# (Shrnutí změn)
$ 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 rozvíjet
# Převedeno na větev "rozvíjet"
$ git merge --v-ff hotfix-1.2.1
# Merge made by recursive.
# (Shrnutí změn)

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 větev -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 větvení a releasing.

Vysoce kvalitní PDF verze obrázku je uvedena na blogu původního příspěvku: http://nvie.com/posts/a-successful-git-branching-model/ [nebo v odkazu Ke stažení níže]. Jděte do toho a posažte ji na zeď, abyste získali rychlou referenci kdykoli.

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

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

  1. Narození Deivsona řekl:

    Dobré odpoledne, Vím, že Git byl původně vyvinut linuxovým systémem, ale když mluvíme o přenositelnosti, Zajímalo by mě, jestli Git běží na windows MSIS a POSIX??

Zanech odpověď

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