Git တွင်အောင်မြင်သောအချိုးအစားပုံစံ

Git ကိုဘယ်လိုသုံးရမှန်းသိဖို့အရေးကြီးတယ်, ၎င်းတွင် ပူးပေါင်း၍ စီမံခန့်ခွဲနိုင်သောဆော့ဝဲလ်ဖွံ့ဖြိုးမှုပတ်ဝန်းကျင်ထိန်းသိမ်းခြင်းပါဝင်သည်.

ချေးငွေ

ဒီ post မူရင်း၏ပေါ်တူဂီဗားရှင်းဖြစ်ပါတယ်, အင်္ဂလိပ်ဘာသာဖြင့်, “အောင်မြင်သော Git ဌာနခွဲပုံစံ“, တရားဝင်စာရေးသူကလုပ်ပိုင်ခွင့်, ဗင်းဆင့် Driessen. ကျေးဇူးတင်ပါတယ်လူ!

နည်းပညာပိုင်းဆိုင်ရာအကြောင်းပြချက်များအတွက်, အချို့သော့ချက်စာလုံးများကိုရည်ရွယ်ချက်ရှိရှိဖြင့်အင်္ဂလိပ်ဘာသာဖြင့်ထိန်းသိမ်းထားသည်. ငါစာသား၏မူရင်းအာမခံဖို့ကြိုးစားခဲ့တယ်, ဒါပေမယ့်ငါတို့ဘာသာစကားနဲ့နားလည်မှုကိုလွယ်ကူချောမွေ့စေဖို့ပြုပြင်ပြောင်းလဲမှုတွေလုပ်ရမယ်ဆိုတာဝန်ခံပါတယ် (PT-BR). ဘာသာပြန်အတွက်တိုးတက်မှုအတွက်ပြင်ဆင်ခြင်းသို့မဟုတ်အကြံပေးခြင်းများကိုကြိုဆိုပါသည်.

နိဒါန်း

ဒါက Git ကိုဘယ်လိုသုံးရမလဲဆိုတာသင်ပေးနေတဲ့ Post မဟုတ်ပါဘူး. ဒီဟာကသင်လိုချင်တာပါ, ငါကြည့်ဖို့အကြံပြုအပ်ပါသည် လက်စွဲ Git လုပ်ပါ. ဆော့ဗ်ဝဲဗားရှင်းမည်သို့လုပ်ရမည်ကိုပြရန်ကျွန်ုပ်တို့ရည်မှန်းချက်လည်းမဟုတ်ပါ, ဤကိစ္စတွင်အတွက်, ကြည့် semantic versioning.

ဤနေရာတွင်အဆိုပြုလွှာသည်အသင်းအဖွဲ့ဆော့ဖ်ဝဲလ်ဗားရှင်းတွင်ပူးပေါင်းပါ ၀ င်မှုကိုစီမံခန့်ခွဲရန်ဖြစ်သည်. သင့်မှာပရိုဂရမ်မာတွေအများကြီးရှိတယ်ဆိုတာသိထားပါ “ရွေ့လျား” တူညီတဲ့အရင်းအမြစ်ကုဒ်၌တည်၏? ဤသည်ဖွံ့ဖြိုးတိုးတက်မှုအရှိန်မြှင့်ရန်အရေးကြီးပါသည်, သို့သော်၎င်းသည်ခေါင်းကိုက်ခြင်းများကိုဖြစ်စေနိုင်သည် (ဆုံးရှုံးမှုနှင့် rework) ထိန်းချုပ်မှုမရှိလျှင်. developer တစ်ယောက်အားအခြားသူ၏အလုပ်များကို overwrite လုပ်ခြင်းမှကာကွယ်ရန်နှင့်တိုးတက်သောနှင့်စနစ်တကျရှိသောဖွံ့ဖြိုးမှုကိုသေချာစေရန်, ပconflictsိပက္ခများလျော့နည်းစေခြင်းနှင့် software ဗားရှင်းများကိုစီမံခြင်း, ကျွန်တော် Git နဲ့သုံးတာပါပဲ အခက်များ နောက်ကိုလိုက်ရန်.

ဌာနခွဲပုံစံ

ဤစာမူ၌ကျွန်ုပ်၏အချို့သောစီမံကိန်းများတွင်အသုံးပြုခဲ့သောဖွံ့ဖြိုးတိုးတက်မှုပုံစံကိုတင်ပြသည် (အလုပ်နှင့်ပုဂ္ဂလိကနှစ် ဦး စလုံး) အနား 1 လွန်ခဲ့သောနှစ်ပေါင်းများစွာ, နှင့်အလွန်အောင်မြင်သောဖြစ်ခဲ့သည်. ငါကအကြောင်းကြာမြင့်စွာရေးသားချင်တယ်, ဒါပေမယ့်ငါမရရှိနိုင်အချိန်တွေ့ရှိခဲ့ဘူး, သေး. ငါစီမံကိန်းအသေးစိတ်ကိုအကြောင်းပြောဆိုလိမ့်မည်မဟုတ်ပါ, အဘို့အရုံမဟာဗျူဟာများ အခက်များ နှင့်စီမံခန့်ခွဲမှု ထုတ်ပြန်ခဲ့သည်.

ဒီတံဆိပ်ခတ်မော်ဒယ်သီးသန့်မထားဘူး Git ကျွန်တော်တို့ရဲ့အရင်းအမြစ်ကုဒ်အားလုံး versioning များအတွက် tool အဖြစ်. (ရည်ရွယ်ချက်မှာ, သငျသညျ Git စိတ်ဝင်စားလျှင်, ကျွန်တော်တို့ရဲ့ကုမ္ပဏီ GoPrime ထောက်ပံ့, Real-time, ဆော့ဖ်ဝဲအင်ဂျင်နီယာ optimization အချို့မယုံကြည်နိုင်လောက်အောင်ဒေတာခွဲခြမ်းစိတ်ဖြာ)

ဘာကြောင့် git??

ဗဟိုအရင်းအမြစ်ထိန်းချုပ်စနစ်များနှင့်နှိုင်းယှဉ်လျှင် Git ၏ကောင်းကျိုးနှင့်ဆိုးကျိုးများကိုစေ့စေ့စပ်စပ်ဆွေးနွေးရန်, ကြည့် တစ်ဦး ဝဘ်. အဲဒီမှာကြီးမားတဲ့ရှိပါတယ် “စစ်” ပတ်ပတ်လည်. တစ် ဦး developer အဖြစ်, ငါ Git ကိုယနေ့တည်ရှိနေသောအခြားကိရိယာများအားလုံးထက်ပိုနှစ်သက်သည်. Git သည် developer များစဉ်းစားပုံကိုပြောင်းလဲခဲ့သည်မှာသေချာသည် ပေါင်းစည်းသည် သို့မဟုတ်တစ်ခုဖန်တီးပါ ဌာနခွဲ. ငါ၏ဂန္ကမ္ဘာမှလာသည် CVS / အဖျက်သမား, ဘယ်မှာ ပေါင်းစည်း / အကိုင်းအခက် ၎င်းသည်သင်ခဏတစ်ကြိမ်သာလုပ်သောအရာဖြစ်ပြီးအမြဲတမ်းအနည်းငယ်တော့ကြောက်စရာကောင်းသည် (“အကျိုးစီးပွားပconflictsိပက္ခများကိုသတိပြုပါ ပေါင်းစည်းသည်, သင့်ကိုကိုက်တယ်!”).

Git နှင့်အတူဤလုပ်ရပ်များ [ပေါင်းစည်း / အကိုင်းအခက်] အလွန်ရိုးရှင်းပြီးကျွန်ုပ်တို့၏လုပ်ငန်းခွင်လုပ်ရိုးလုပ်စဉ်၏အဓိကအစိတ်အပိုင်းတစ်ခုဖြစ်သည်ကိုကိုယ်စားပြုသည်, ယုံတယ်. ဥပမာအား, အဘယ်သူမျှမ စာအုပ် CSV / အဖျက်သမား, အကို အီး ပေါင်းစည်း ပထမ ဦး ဆုံးအကြိမ်နောက်ပိုင်းအခန်းများတွင်သာဖော်ပြထားသည် (အဆင့်မြင့်အသုံးပြုသူများသည်), မည်သည့်နေချိန်မှာ Git အပေါ်စာအုပ်, ဒီအခနျးတှငျတှေ့မွငျရသညျ 3 (အခြေခံ).

၎င်း၏ရိုးရှင်းခြင်းနှင့်ထပ်တလဲလဲသဘောသဘာဝ၏အကျိုးဆက်အဖြစ်, အကို အီး ပေါင်းစည်း ကြောက်စရာအကြောင်းမရှိတော့. အမှန်, ဗားရှင်းထိန်းချုပ်ကိရိယာများကကူညီသင့်ပါတယ်ပေါင်းစည်းသည် ဖန်တီးပါ ဌာနခွဲ အခြားအရာအားလုံးထက်ပိုပါတယ်.

ဟောပြောရန်လုံလောက်, ဖွံ့ဖြိုးတိုးတက်မှုပုံစံကိုသွားကြစို့. ဤနေရာတွင်ကျွန်ုပ်တင်ပြမည့်ပုံစံသည်အခြေခံအားဖြင့်စီမံခန့်ခွဲထားသောဆော့ဝဲလ်ဖွံ့ဖြိုးတိုးတက်မှုလုပ်ငန်းစဉ်ကိုရောက်ရှိရန်အဖွဲ့ ၀ င်တစ် ဦး စီလိုက်နာရမည့်လုပ်ထုံးလုပ်နည်းများသာဖြစ်သည်။.

ဗဟိုချုပ်ကိုင်မှုလျှော့ချ, ဒါပေမယ့်ဗဟို

ကျွန်ုပ်တို့အသုံးပြုသော repository ၏ဖွဲ့စည်းပုံနှင့်၎င်းသည်ဤမော်ဒယ်နှင့်အလွန်ကောင်းစွာအလုပ်လုပ်သည် အကို ဗဟို repository ကိုပါဝင်သည်. ဒီ repository ကသာကြောင်းသတိပြုပါ “အဖြစ်ယူခဲ့ပါတယ်” ဗဟို (ဘာလို့လဲဆိုတော့ Git ဟာ DVCS ပါ [ဖြန့်ဝေဗားရှင်းထိန်းချုပ်ရေးစနစ်များ], အခြားစကား, နည်းပညာဆိုင်ရာအဆင့်မှာဗဟို repository ကဲ့သို့ဘာမှမရှိဘူး). ကျနော်တို့အဖြစ်ဒီ repository ကိုရည်ညွှန်းပါလိမ့်မယ် မူလ, ဒီနာမကိုအမှီအားလုံး Git အသုံးပြုသူများအကျွမ်းတဝင်ဖြစ်ပါတယ်ကတည်းက.

တစ်ခုချင်းစီကို developer ပါဘူး ဆွဲငင် အီး တွန်း ရန် မူလ. ဒါပေမယ့်ဆက်ဆံရေးကိုကျော်လွန်ပြီး push-pull ဗဟိုအဘို့ [မူလ], developer တစ်ယောက်ချင်းစီလည်းကောက်ယူနိုင်သည် [ဆွဲပါ] အခြားစွမ်းကနေအပြောင်းအလဲ subteams ဖွဲ့စည်းရန်. ဥပမာအား, ၎င်းသည် developer နှစ် ဦး သို့မဟုတ်ထိုထက်ပိုသောကြီးမားသောအင်္ဂါရပ်တစ်ခုကိုအတူတကွလုပ်ဆောင်ခြင်းအတွက်အသုံးဝင်သည်, ယခင်ပေးပို့ခြင်း [တွန်း] အဘို့အတိုးတက်မှုအတွက်အလုပ်လုပ်ကြသည် မူလ. အပေါ်ကပုံမှာ, Alice နဲ့ Bob ရဲ့ subteams တွေရှိတယ်, အဲလစ်အီးဒေးဗစ်, Clair နှင့် David တို့.

နည်းပညာပိုင်း, ဆိုလိုသည်မှာ Alice သည် Bob ဟုခေါ်သောဝေးလံသော Git ဟုသတ်မှတ်ခြင်းထက် ပို၍ အဓိပ္ပာယ်မရှိပါ, Bob ၏ repository ကိုညွှန်ပြ, နှင့်အပြန်အလှန်.

အဓိကအကိုင်းအခက်

နောက်ကွယ်မှာ, ဒီဖွံ့ဖြိုးမှုမော်ဒယ်အတော်လေးထွက်ရှိတည်ဆဲမော်ဒယ်များအားဖြင့်မှုတ်သွင်းသည်. ဗဟို repository ကိုနှစ်ခုအကိုင်းအခက်ရှိပါတယ် [အခက်များ] အဆုံးမဲ့ဘဝနှင့်အတူကျောင်းအုပ်ကြီး:

  • ဆရာ
  • ဖွံ့ဖြိုးတိုးတက်

အဆိုပါ ဌာနခွဲဆရာ တွင် မူလ Git အသုံးပြုသူတိုင်းနှင့်ရင်းနှီးသင့်သည်. စင်ပြိုင် ဌာနခွဲဆရာ, နောက်တစ်ခုရှိသေးတယ် ဌာနခွဲ ခေါ်ခဲ့သည် ဖွံ့ဖြိုးတိုးတက်.

ကျနော်တို့စဉ်းစားပါ မူရင်း / မာစတာ como sendo o branch principal onde o código fonte de HEAD sempre reflete um estado production-ready [pronto para produção].

ကျနော်တို့စဉ်းစားပါ origin/develop como sendo o ဌာနခွဲ 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 deဌာနခွဲ 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 ဌာနခွဲဆရာ e depois marcados com um número de versão [လွှတ်ပေးရန်]. Como isso é feito em detalhes, será discutido mais adiante.

ထိုကွောငျ့, cada vez que as alterações são incorporadas [merged] de volta ao ဆရာ, é gerada uma nova versão [released], por definição. Nós procuramos ser bastante rigorosos nisso, ထိုအခါ, 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 အဘယ်သူမျှမ ဆရာ.

Branches auxiliares

Ao lado das အခက်များ principais, ဆရာ အီး ဖွံ့ဖြိုးတိုးတက်, nosso modelo de desenvolvimento usa uma variedade de အခက်များ de apoio para auxiliar o desenvolvimento simultâneo entre os integrantes da equipe, အဘယ်အရာကို 1) facilita o rastreamento de novas funcionalidades [features], 2) prepara para entrega de uma nova versão [လွှတ်ပေးရန်] အီး 3) ajuda a rapidamente corrigir falhas em produção [hotfix]. Diferentemente dos အခက်များ principais, estes အခက်များ tem um tempo de vida curto, já que eventualmente serão removidos.

Os diferentes tipos de အခက်များ [auxiliares] que podemos usar, သူတို့ဖြစ်ကြသည်:

  • Feature branches
  • Release branches
  • Hotfix branches

Cada um desses အခက်များ tem um propósito específico e está vinculado à regras rígidas, de modo que, အခက်များ podem dar origem a ဌာနခွဲ e que အခက်များ devem ser mesclados [merged] a seus alvos. Nós veremos cada um deles [အခက်များ] em um instante.

Sob uma perspectiva técnica, esses အခက်များ não são consideradosespeciais”. Cada tipo de ဌာနခွဲ é categorizado pela forma como os usamos. နောက်ဆုံးမှာ, são apenas simples အခက်များ do velho e bom Git.

Feature branches

[Features = recursos/funcionalidades]

Pode se ramificar [ဌာနခွဲ] a partir de:
ဖွံ့ဖြိုးတိုးတက်
Deve mesclar-se [ပေါင်းစည်းသည်] novamente a:
ဖွံ့ဖြိုးတိုးတက်
Convenção de nomeação do ဌာနခွဲ:
Qualquer coisa, exceto ဆရာ, ဖွံ့ဖြိုးတိုးတက်, release-*, ဒါမှမဟုတ် 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 ဖွံ့ဖြိုးတိုးတက် (para adicionar definitivamente a nova feature ao próximo လွှတ်ပေးရန်) ou descartado (no caso de uma experiência mal sucedida).

Feature branches tipicamente existem apenas no repositório ဖွံ့ဖြိုးတိုးတက်, não em မူလ.

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 လွှတ်ပေးရန်.

$ git checkout develop
# Switched to branch 'develop'
$ git merge --အဘယ်သူမျှမ-ff myfeature
# Updating ea1b82a..05e9557
# (Summary of changes)
# $ git branch -d myfeature
# Deleted branch myfeature (was 05e9557).
$ git push origin develop

A flag no-ff faz com que a mesclagem [ပေါင်းစည်းသည်] sempre crie um novo objeto de commit, ainda que a mesclagem pudesse ser executada com um fast-forward [ff]. Isso evita que se perca informações sobre o histórico da existência de uma feature branch, agrupando todos os commits que foram adicionados à feature. Compare:

No último caso [da figura acima], é impossível ver a partir do histórico do Git quais dos commits foram implementados dentro de uma feature; você teria que ler manualmente todas as mensagens de log. Reverter uma feature inteira (အခြားစကား, um grupo de commits), é uma verdadeira dor de cabeça na última situação, enquanto que é facilmente feito se a flag no-ff tiver sido usada.

sim, isso criará mais alguns objetos de commits (vazios), mas o ganho é muito maior do que o custo.

Release branches

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

Pode se ramificar [ဌာနခွဲ] a partir de:
ဖွံ့ဖြိုးတိုးတက်
Deve mesclar-se [ပေါင်းစည်းသည်] novamente a:
ဖွံ့ဖြိုးတိုးတက် အီး ဆရာ
Convenção de nomeação do ဌာနခွဲ:
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. ထိုမှတပါး, eles permitem pequenas correções de bugs e definição de meta-dados para uma လွှတ်ပေးရန် (número de versão, datas de compilação, စသည်တို့ကို). Ao fazer todo esse trabalho em um release branch, အ develop branch fica limpo para receber features da próxima grande လွှတ်ပေးရန် [ဗားရှင်း].

O momento chave para se criar uma nova release branch ramificando de ဖွံ့ဖြိုးတိုးတက် é quando o ဖွံ့ဖြိုးတိုးတက် já está (နီးပါး) refletindo o estado desejado da nova လွှတ်ပေးရန် [ဗားရှင်း]. Todas as features candidatas ao လွှတ်ပေးရန် a ser construído devem ser incorporados [ပေါင်းစည်းသည်] သို့ ဖွံ့ဖြိုးတိုးတက် neste momento. Já os features voltados para ထုတ်ပြန်ခဲ့သည် futuros devem esperar uma próxima လွှတ်ပေးရန် [ဗားရှင်း].

É exatamente no início de um release branch que o próximo လွှတ်ပေးရန် recebe um número de versãonão antes. Até esse momento, အ 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 သို့မဟုတ် 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 sobresemantic versioning“].

Criando um release branch

Os releases branches são criados a partir do develop branch. ဥပမာအား, digamos que a versão 1.1.5 é a atual versão de produção e temos uma grande လွှတ်ပေးရန် chegando. O estado de ဖွံ့ဖြိုးတိုးတက် 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 သို့မဟုတ် 2.0). ထိုအခါ, 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 ဖွံ့ဖြိုးတိုးတက်
# Switched to a new branch "release-1.2"
$ ./bump-ဗားရှင်း.sh 1.2
# Files modified successfully, version bumped to 1.2.
$ git commit -တစ်ဦး -မီတာ "Bumped version number to 1.2"
# [release-1.2 74d9424] Bumped version number to 1.2
# 1 files changed, 1 insertions(+), 1 deletions(-)

Depois de criar um novo ဌာနခွဲ e acessá-lo, nos esbarramos no número da versão. Aqui, bump-version.sh é um script shell que altera alguns arquivos da cópia de trabalho para refletir a nova versão. (Isso pode, ရှင်းလင်းသော, ser uma mudança manualo ponto é que alguns arquivos mudam.) ထိုအခါ, é feito o commit do número da versão modificada.

Este novo ဌာနခွဲ pode existir lá por um tempo, até que a လွှတ်ပေးရန် seja lançada definitivamente. Durante esse período, correções de erros podem ser aplicadas neste ဌာနခွဲ (em vez do develop branch). A adição de novos e grandes features aqui é estritamente proibida. Eles devem ser mesclados [merged] တွင် ဖွံ့ဖြိုးတိုးတက် အီး, ဒါကြောင့်, aguardar o próximo grande လွှတ်ပေးရန်.

Finalizando um release branch

Quando o release branch está pronto para se tornar uma versão real, algumas ações precisam ser realizadas. Primeiro, အ release branch é mesclado em ဆရာ (uma vez que cada commit အဘယ်သူမျှမ ဆရာ é uma nova versão por definição, lembre-se). Em seguida, esse commit အဘယ်သူမျှမ ဆရာ deve ser marcado para facilitar uma futura referência a este histórico de versões. နောက်ဆုံး, as mudanças feitas no release branch precisam ser mescladas [merged] novamente para ဖွံ့ဖြိုးတိုးတက်, de modo que os ထုတ်ပြန်ခဲ့သည် futuros também contenham essas correções de bugs.

As duas primeiras etapas no Git:

$ git checkout master
# Switched to branch 'master'
$ git merge --အဘယ်သူမျှမ-ff release-1.2
# Merge made by recursive.
# (Summary of changes)
$ git tag -တစ်ဦး 1.2

အဆိုပါ လွှတ်ပေးရန် agora está concluído e marcado para futura referência.

ပွောဆို: 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 ဖွံ့ဖြိုးတိုးတက်. No Git:

$ git checkout develop
# Switched to branch 'develop'
$ git merge --အဘယ်သူမျှမ-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.

ယခု, que realmente terminamos, အ 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 [ဌာနခွဲ] a partir de:
ဆရာ
Deve mesclar-se [ပေါင်းစည်းသည်] novamente a:
ဖွံ့ဖြိုးတိုးတက် အီး ဆရာ
Convenção de nomeação do ဌာနခွဲ:
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 pode ser derivado da tag que marca a versão de produção existente no master branch.

A essência é que o trabalho dos membros da equipe (အဘယ်သူမျှမ develop branch) pode continuar, enquanto outra pessoa está preparando uma rápida correção da falha em produção.

Criando o hotfix branch

Os hotfix branches são criados a partir do master branch. ဥပမာအား, supondo que a versão 1.2 é a versão atual da release de produção rodando e apresenta problemas devido a um erro grave. Mudanças no ဖွံ့ဖြိုးတိုးတက် deixam o ainda instável. Nós podemos então ramificar um hotfix branch e começar a solucionar o problema:

$ git checkout -b hotfix-1.2.1 ဆရာ
# Switched to a new branch "hotfix-1.2.1"
$ ./bump-ဗားရှင်း.sh 1.2.1
# Files modified successfully, version bumped to 1.2.1.
$ git commit -တစ်ဦး -မီတာ "Bumped version number to 1.2.1"
# [hotfix-1.2.1 41e61bb] Bumped version number to 1.2.1
# 1 files changed, 1 insertions(+), 1 deletions(-)

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 -မီတာ "Fixed severe production problem"
# [hotfix-1.2.1 abbe5d6] Fixed severe production problem
# 5 files changed, 32 insertions(+), 17 deletions(-)

Finalizando um hotfix branch

Quando terminado, အ bugfix precisa ser mesclado de volta ao ဆရာ, mas também precisa ser incorporado novamente para ဖွံ့ဖြိုးတိုးတက်, 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 ဆရာ e tag a လွှတ်ပေးရန် [marque a verão]:

$ git checkout master
# Switched to branch 'master'
$ git merge --အဘယ်သူမျှမ-ff hotfix-1.2.1
# Merge made by recursive.
# (Summary of changes)
$ git tag -တစ်ဦး 1.2.1

ပွောဆို: você também pode usar as flags -s ou -u para assinar sua tag criptograficamente.

Em seguida, inclua o bugfix အဘယ်သူမျှမ ဖွံ့ဖြိုးတိုးတက် လည်း:

$ git checkout develop
# Switched to branch 'develop'
$ git merge --အဘယ်သူမျှမ-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 ဖွံ့ဖြိုးတိုးတက်. Mesclar o bugfix အဘယ်သူမျှမ release branch irá fazer com que o bugfix seja mesclado no ဖွံ့ဖြိုးတိုးတက် လည်း, quando o release branch for concluído. (Se o trabalho no ဖွံ့ဖြိုးတိုးတက် requer imediatamente esse bugfix e não puder esperar até que o release branch seja concluído, você pode seguramente mesclar o bugfix အတွက် deveolp também.)

နောက်ဆုံး, remova a ဌာနခွဲ temporária:

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

စိတ္တဇ

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 အကို အီး 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.

စုစုပေါင်း access: 10292

တစ်ဦးကသုံးသပ်မှုအပေါ် “Git တွင်အောင်မြင်သောအချိုးအစားပုံစံ

  1. Deivson မွေးဖွားခြင်း ကပြောပါတယ်:

    ကောင်းသောနေ့လည်ခင်း, သယ်ဆောင်ရလွယ်ကူအကြောင်းပြောနေတာသောအခါငါ Git ပိုင်းတွင် Linux တို့အတွက်တီထွင်ခဲ့ကွောငျးကိုသိပေမယ့်, Git POSIX MSIS နှင့်ပြတင်းပေါက်များပေါ်တွင်အလုပ်လုပ်မယ်ဆိုရင်ငါတွေးမိ??

တစ်ဦးစာပြန်ရန် Leave

သင့်အီးမေးလ်လိပ်စာပုံနှိပ်ထုတ်ဝေမည်မဟုတ်ပါ. တောင်းဆိုနေတဲ့လယ်ယာနှင့်အတူမှတ်သားထားတဲ့ *