Veiksmīgo modeli, filiāļu Git

Lai izmantotu Git ir svarīgi, un kas ietver sadarbības attīstības vides programmatūras uzturēšanas pārvaldāmu.

Kredīti

Šajā amatā ir Portugāles sākotnējā versija, angļu valodā, “Veiksmīga Git sazarojuma modelis“, attiecīgi pilnvarojusi autoru, Vincent Driessen. Paldies. vīrietis!

Par tehniskiem jautājumiem, Dažiem atslēgvārdiem ar nolūku tur angļu valodā. Es centos, lai nodrošinātu teksta oriģinalitāti, bet jāatzīstas, ka man nācās veikt pielāgojumus, lai veicinātu izpratni mūsu valodā (LV). Jebkuru labojumu vai ierosinājumu tulkojuma uzlabošanai ir apsveicami.

Ievads

Tas nav Post teaching kā izmantot Git. Ja tas ir tas, ko jums vajag, Es ierosinu, ņemot apskatīt Git rokasgrāmata. Arī mūsu mērķis ir parādīt, kā darīt programmatūras versiju, Šajā gadījumā, sk. Semantiskās versiju.

Priekšlikums ir vadīt komandu sadarbību ar programmatūras versiju. Jūs zināt, kad jums ir vairākas programmētāji “maisot” paša avota koda? Ir svarīgi, lai paātrinātu attīstību, bet var radīt milzīgas galvassāpes (aizspriedumus un pārstrādāt) Ja ir vadīkla. Liegt pārrakstīt katrs izstrādātājs citu darbu un nodrošinātu pakāpenisku attīstību un organizēta, samazinot konfliktu un pārvaldīt programmatūras versijas, ir tas, ka mēs izmantot Git un modeli filiāles pēc tam.

Tukšas veidnes

Šajā amatā es klāt attīstības modelis, kas izmanto, daži no maniem projektiem (strādāt kā īpaši) par gada 1 gadiem, un tas ir bijis ļoti veiksmīgs. Tas ir bijis ilgu laiku es gribēju rakstīt par to, bet nekad atrada grafiks pieejams, līdz šim. Es neesmu gatavojas apspriest projektu detaļas, tikai par stratēģijas filiāles un apsaimniekošanu izlaidumi.

Šis modelis ir vērsta vienīgi uz Git kā instruments, lai versiju, visas avota koda. (starp citu, Ja jūs interesē Git, mūsu kompānija GitPrime nodrošina, reālā laikā, dažas apbrīnojamo datu analīzes programmatūras inženierijas optimizāciju)

Kāpēc git?

Par sīku iztirzājumu par plusi un mīnusi Git salīdzinājumā ar sistēmas centralizēta avota koda vadīklas, sk. uz Web. Tur ir briesmīga “karš” ap to. Kā attīstītājs, Es gribētu Git attiecībā pret citiem esošajiem rīkiem, šodien. Git šaubu mainīts veids, kā attīstītājiem domāt par veicot Sapludināt vai izveidot filiāle. Es nāku no klasiskās pasaules CVS/Subversion, kur apvienošanās vai zaru Tas ir kaut kas jums darīt tikai vienu reizi brītiņa un vienmēr izskatās mazliet biedējoši (“Uzmanieties no konfliktiem Sapludināt, viņi tev iekost!”).

Ar Git šīs darbības [apvienošanās vai zaru] ir ļoti vienkāršs un pārstāv vienu no lielas daļas no mūsu darba kārtība, tici man. Piemēram, programmā Grāmatas CSV/Subversion, sazarojuma un sapludinot attiecas tikai pirmo reizi vēlāk nodaļās (pieredzējušiem lietotājiem), Tajā pašā laikā jebkurā grāmata par Git, Tas ir redzams nodaļā 3 (pamati).

Vienkāršība un atkārtojas, sazarojuma un sapludinot vairs nav ko baidīties. Faktiski, versiju kontroles instrumenti palīdzēs veiktSapludināt un izveidojiet filiāle vairāk nekā jebkas cits.

Vairs runāt, Let ' s go to attīstības modeli. Modelis, ko es esmu gatavojas klāt šeit būtībā nav nekas vairāk kā procesus, kas katram darba grupas dalībniekam jāievēro, lai sasniegtu pārvaldītās programmatūras izstrādes procesu kopumu.

Decentralizēto, bet centrā

Krātuvi, ko mēs izmantošanu, un ka darbojas ļoti labi ar šī modeļa konfigurācija sazarojuma sastāvā ir centrālā krātuve. Ņemiet vērā, ka šī krātuve ir tikai “uzskatīta par” Centrālā (jo Git DVCS [Izplatīti versiju kontroles sistēmas], IE, Nav nekā, piemēram, kā centrālajā repozitārijā tehniskā līmenī). Mums būs atsauce šajā repozitorijā, piemēram izcelsmes, Jo šis vārds ir pazīstams visiem Git lietotājiem.

Katru attīstītājs padara atvelk un ceļojumi par izcelsmes. Bet tālāk attiecības push-pull par centralizētu [izcelsmes], arī katrs izstrādātājs var uzņemt [pavelciet] izmaiņas citās pāros, lai veidlapas apakšgrupas. Piemēram, Tas var būt noderīga, strādājot ar diviem vai vairāk izstrādātāji jaunu lielisku funkcionalitāti, iepriekš, nosūtot [stumšana] darbs par izcelsmes. Attēlā iepriekš, Tur ir apakšgrupas Alise un Bobs, Alise un David, un Clair, un David.

Tehniski, Tas nozīmē, ka nekas vairāk kā Alise ir definējis attālās Git nosaukts Bob, norādot uz Bob repozitorijs, un otrādi.

Bronhu atzarojumus

Izmantošana fonā, Šis attīstības modelis ir diezgan iedvesmojuši esošie modeļi, kas tur. Centrālajai repozitorijam ir divas filiāles [filiāles] ar bezgalīgu dzīvi:

  • Šablonu
  • Attīstīt

Uz Master Branch Collas izcelsmes jābūt pazīstamiem katram git lietotājam. Paralēli Master Branch, tur ir vēl viens filiāle Sauc Attīstīt.

Apsvērt izcelsmes/Master kā galvenā filiāle, kur pirmkodu Galvu vienmēr atspoguļo valsts gatavība ražošanai [gatavs ražošanai].

Apsvērt izcelsmes/attīstībasfiliāle galveno, kur avota kods Galvu vienmēr atspoguļo valsti ar jaunākajām attīstības izmaiņām, kas jāpiegādā nākamajā laidienā. Daži to sauc par “filiāle Integrācijas”. Tur notiek visdraudīgāko konstrukciju.

Ja avota kods filiāle attīstīt sasniegt stabilu punktu un ir gatavi atbrīvot [atbrīvots], jāapvieno visas izmaiņas [sapludinātas] atpakaļ uz Master Branch un tad atzīmējis ar versijas numuru [presei]. Kā tas tiek darīts, detalizēti, tiks apspriests vēlāk.

Tātad, katru reizi veikto izmaiņu iekļaušanas [sapludinātas] atpakaļ uz Šablonu, Tā ir radījusi jaunu versiju [atbrīvots], pēc definīcijas. Mēs cenšamies būt diezgan rūpīgi par to, Tātad, teorētiski, Mēs pat varētu izmantot skriptu āķis Git izveidot un automātiski nosūtīt savu pieteikumu uz ražošanas serveri ikreiz, kad tiek izpilde programmā Šablonu.

Palīgierīces zari

Blakus filiāles galvenais, Šablonu un Attīstīt, mūsu attīstības modelis izmanto dažādas filiāles lai palīdzētu atbalstīt vienlaicīga attīstība starp komandas locekļiem, kā 1) veicina jauno līdzekļu izsekošana [funkcijas], 2) sagatavot jaunu versiju piegādes [presei] un 3) palīdz ātri noteikt trūkumus ražošanas [labojumfailu]. Atšķirībā no filiāles galvenais, Šie filiāles ir īss derīguma termiņš, tagad tas beidzot tiks noņemti.

Dažādu veidu filiāles [palīgi] Mēs varam izmantot, ir:

  • Iezīme zari
  • Atlaist filiāles
  • Labojumfailu zari

Katrs no šiem filiāles ir konkrētam mērķim un ir saistīta ar stingriem noteikumiem, tā, ka, filiāles var izraisīt filiāle un ka filiāles ir jāsapludina [sapludinātas] jūsu mērķiem. Mēs redzēsim, katrā [filiāles] tajā pašā mirklī.

Saskaņā ar tehniskā perspektīvas, Šie filiāles netiek uzskatītas par “Īpaša”. Katra veida filiāle Tā tiek iedalīta pēc kā mēs tos izmantot. Jebkurā gadījumā, ir tikai vienkārša filiāles labs vecs Git.

Iezīme zari

[Funkcijas = līdzekļu/funkcionalitāte]

– Filiāles var [filiāle] no:
Attīstīt
– Vajadzētu apvienot-ja [Sapludināt] vēlreiz:
Attīstīt
– Konvencija par iecelšanu filiāle:
Kaut ko, Izņemot Šablonu, Attīstīt, Release-*, Vai labojumfails-*

Uz funkciju zari (vai dažreiz sauc par Tematiskie zari) tiek izmantoti, lai izstrādātu jaunus līdzekļus/funkcionalitāti nākamajam vai nākamajiem laidienam. Sākot izstrādāt Līdzeklis, mērķa versija, kurā šis līdzeklis tiks iegults var būt nezināms šajā brīdī.

Būtība funkciju zari ir tāda, ka tā pastāv, Līdzeklis ir izstrādes, bet galu galā tā tiks iekļauta [sapludinātas] atpakaļ uz Attīstīt (lai noteikti pievienotu jauno Līdzeklis uz nākamo presei) vai atmesti (neveiksmīga eksperimenta gadījumā).

Iezīme zari parasti pastāv tikai repozitorijā Attīstīt, neatrodas izcelsmes.

Funkciju zaru izveide

$ git Checkout -B myfeature attīstīt
# Switched to a new branch "myfeature"

Pabeigta līdzekļa iegulšana izstrādāšanas

Funkcijas, jaunais gads pabeigts, var sapludināt[sapludinātas] ar to, ka filiāle attīstīt , lai tos noteikti pievienotu nākamajam presei.

$ git Checkout izstrādāt
# Pārgāja uz filiāli "attīstīt"
$ git sapludināšanas --programmā-myfeature FF
# Notiek atjaunināšana ea1b82a.. 05e9557
# (Izmaiņu kopsavilkums)
# $ git filiāle-d myfeature
# Svītrots filiāle myfeature (bija 05e9557).
$ git push izcelsme attīstīt

Karoga –no-FF izraisa sajaukšanu [Sapludināt] vienmēr izveidot jaunu izpilde, kaut arī sapludināšanu var veikt ar Patītu [Ff]. Tas neļauj informāciju par vēsturi esamību iezīme filiāle, grupējot visus Izdara , kas ir pievienoti Līdzeklis. Salīdzināt:

Pēdējā gadījumā [no iepriekš minētā skaitļa], nav iespējams saskatīt no git vēstures, kuru Izdara ir īstenoti saskaņā ar Līdzeklis; jums būtu manuāli lasīt visus žurnāla ziņojumus. Apgrieztu Līdzeklis viengabala (IE, grupa Izdara), Tas ir reālā galvassāpes pēdējā situācijā, Kaut kas ir viegli izdarīt, ja karoga –no-FF ir izmantots.

jā, Tas radīs dažas vairāk objektu Izdara (tukšs), bet peļņa ir daudz lielāka nekā izmaksas.

Atlaist filiāles

[Atbrīvot = piegādes/versija]

– Filiāles var [filiāle] no:
Attīstīt
– Vajadzētu apvienot-ja [Sapludināt] vēlreiz:
Attīstīt un Šablonu
– Konvencija par iecelšanu filiāle:
Release-*

Uz Izlaidumi zari palīdzēt sagatavot jaunu ražošanas atbrīvošanu [ražošanas atbrīvošanu]. Tās ļauj jums dot pēdējās stundas laikā varat. turklāt, Tie ļauj nelielu kļūdu labojumi bugs un definīcija meta-dati par presei (versijas numurs, veidot datumi, u.c.). Darīt visu šo darbu atbrīvot filiāle, uz attīstīt filiāle palikt tīrs, lai saņemtu funkcijas nākamais lielais presei [versija].

Galvenais brīdis, lai izveidotu jaunu atbrīvot filiāle sazarojums no Attīstīt ir tad, kad Attīstīt jau ir (Gandrīz) atspoguļojot vēlamo stāvokli jaunajā presei [versija]. Visas funkcijas kandidātus presei , kas ir jābūvē, ir jāiestrādā [Sapludināt] Lai Attīstīt Šajā brīdī. No otras puses funkcijas Mērķis izlaidumi nākotnes līgumiem ir jārēķinās ar nākamo presei [versija].

Tas ir labi sākumā atbrīvot filiāle , ka nākamais presei saņem versijas numuru – ne agrāk. Līdz tam brīdim, uz attīstīt filiāle atspoguļotas izmaiņas “Nākamais laidiens” [nākamā versija], bet nav skaidrs, vai tas “nākamā versija” galu galā tiks 0.3 vai 1.0, līdz brīdim, kad atbrīvot filiāle jāsāk. Šis lēmums ir pieņemts atbrīvot filiāle un to veic ar projekta noteikumiem par versiju [ieteikt redzēt par “Semantiskās versiju“].

Izveidojot release Branch

Uz Izlaidumi zari tiek veidotas no attīstīt filiāle. Piemēram, Pieņemsim, ka versija 1.1.5 ir pašreizējā ražošanas versija, un mums ir ļoti daudz presei Nāk. Valsts Attīstīt ir gatavs “nākamā versija” [Nākamais laidiens] un mēs nolēmām, ka tas kļūtu par 1.2 (tā vietā 1.1.6 vai 2.0). Tātad, mēs sazarosim un dodam atbrīvot filiāle nosaukums, kas atspoguļo jaunās versijas numuru:

$ git Checkout -B release-1.2 Attīstīt
# Switched to a new branch "release-1.2"
$ ./Sasist-Versija.Sh 1.2
# Veiksmīgi modificēti faili, Version bumped uz 1.2.
$ git izpilde -uz -M "Bumped version number to 1.2"
# [atbrīvošana-1,2 74d9424] Bumped versijas numuru, lai 1.2
# 1 mainītos failus, 1 Iespraudumi(+), 1 Dzēsumi(-)

Kad ir izveidots jauns filiāle un piekļūstiet tam, mēs sasist versijas numuru. šeit, bump-version.sh ir čaulas skripts, kas maina dažus darba kopiju failus, lai atspoguļotu jauno versiju. (Tas var, protams, būt manuāla izmaiņa – punkts ir tas, ka daži faili mainās.) Tātad, ir izgatavots izpilde modificēto versijas numuru.

Šī jaunā filiāle kādu laiku var pastāvēt, līdz brīdim, kad presei noteikti ir uzsākta. Šajā periodā, kļūdu labojumus var lietot šajā filiāle (tā vietā, lai attīstīt filiāle). Pievienojot jaunus un lielus funkcijas šeit ir stingri aizliegta. Tie ir jāapvieno [sapludinātas] Collas Attīstīt un, šādi, sagaidiet nākamo lielo presei.

Laidiena filiāles Pabeigšana

, Kad atbrīvot filiāle ir gatava kļūt par reālu versiju, dažas darbības jāveic. Pirmo, uz atbrīvot filiāle tiek sapludināta Šablonu (jo katra izpilde programmā Šablonu ir jauna versija pēc definīcijas, Atcerēties). Pēc tam, Šo izpilde programmā Šablonu būtu jāatzīmē, lai veicinātu turpmāku atsauci uz šo versiju vēsture. Beidzot, veiktās izmaiņas atbrīvot filiāle ir jāapvieno [sapludinātas] atkal par Attīstīt, tā, lai izlaidumi Futures ietver arī šos kļūdu labojumus.

Pirmie divi soļi git:

$ git Checkout Master
# Pārslēgts uz zara "Master"
$ git sapludināšanas --programmā-FF release-1.2
# Sapludināšana veikta, izmantojot rekursīvu.
# (Izmaiņu kopsavilkums)
$ git tagu -uz 1.2

Uz presei tagad ir aizpildīta un atzīmēta turpmākai atsaucei.

Piezīme: var izmantot arī-s vai-u karodziņus lai parakstītu tagu ar šifrēšanu.

, Lai paturētu izmaiņas, kas veiktas atbrīvot filiāle, mums tās jāsaliek kopā Attīstīt. Nr git:

$ git Checkout izstrādāt
# Pārgāja uz filiāli "attīstīt"
$ git sapludināšanas --programmā-FF release-1.2
# Sapludināšana veikta, izmantojot rekursīvu.
# (Izmaiņu kopsavilkums)

Šī darbība var izraisīt sapludināšanas konfliktu (iespējams, iet, kad mēs mainām versijas numuru). Ja tā, noteikt un darīt izpilde.

Tagad, , ka mēs patiešām izšķīrāmies, uz atbrīvot filiāle var izņemt, tā kā mums tas vairs nebūs vajadzīgs:

$ git Branch -d release-1.2
# Dzēsta zara izlaišana-1,2 (bija ff452fe).

Labojumfailu zari

– Filiāles var [filiāle] no:
Šablonu
– Vajadzētu apvienot-ja [Sapludināt] vēlreiz:
Attīstīt un Šablonu
– Konvencija par iecelšanu filiāle:
labojumfails-*

Uz Labojumfailu zari ir ļoti līdzīgi izlaiduma filiāles, jo tie ir paredzēti arī, lai sagatavotu jaunu ražošanas versiju, lai gan neplānoti. 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 (programmā attīstīt filiāle) pode continuar, enquanto outra pessoa está preparando uma rápida correção da falha em produção.

Criando o hotfix branch

Uz hotfix branches tiek veidotas no master branch. Piemēram, 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 Attīstīt deixam o ainda instável. Nós podemos então ramificar um hotfix branch un sākt risināt problēmu:

$ git Checkout -(b) labojumfailu-1.2.1 Šablonu
# Switched to a new branch "hotfix-1.2.1"
$ ./Sasist-Versija.Sh 1.2.1
# Veiksmīgi modificēti faili, Version bumped uz 1.2.1.
$ git izpilde -uz -M "Bumped version number to 1.2.1"
# [labojumfailu 1.2.1 41e61bb] Bumped versijas numuru, lai 1.2.1
# 1 mainītos failus, 1 Iespraudumi(+), 1 Dzēsumi(-)

Neaizmirstiet pēc zaru Izmainiet versijas numuru!

Pēc tam, labot kļūdas un veikt izpilde labojumu vienā vai vairākās izpilde atdalot tos.

$ git izpilde -M "Fixed severe production problem"
# [labojumfailu 1.2.1 abbe5d6] Smagas fiksētās ražošanas problēmu
# 5 mainītos failus, 32 Iespraudumi(+), 17 Dzēsumi(-)

Apdares labojumfailu filiāle

Kad esat pabeidzis, uz labojums vajadzībām tiks sapludināti atpakaļ uz Šablonu, bet arī tai vajadzētu atkal iekļaut, lai Attīstīt, lai nodrošinātu, ka labojums arī tiks iekļautas nākamajā versijā. Tas ir diezgan līdzīgi kā izlaiduma filiāles ir pabeigta.

Pirmo, atjaunināt Šablonu to un piestipriniet birku presei [iezīmēt vasaru]:

$ git Checkout Master
# Pārslēgts uz zara "Master"
$ git sapludināšanas --programmā-labojumfailu FF-1.2.1
# Sapludināšana veikta, izmantojot rekursīvu.
# (Izmaiņu kopsavilkums)
$ git tagu -uz 1.2.1

Piezīme: var izmantot arī-s vai-u karodziņus lai parakstītu tagu ar šifrēšanu.

Pēc tam, ietver labojums programmā Attīstīt Arī:

$ git Checkout izstrādāt
# Pārgāja uz filiāli "attīstīt"
$ git sapludināšanas --programmā-labojumfailu FF-1.2.1
# Sapludināšana veikta, izmantojot rekursīvu.
# (Izmaiņu kopsavilkums)

Vienīgais izņēmums no noteikuma šeit ir tas, ka, Ja ir atbrīvot filiāle notiek, izmaiņas labojumfailu ir jāapvieno šī atbrīvot filiāle, Nevis Attīstīt. Sapludināt labojums programmā atbrīvot filiāle izraisīs labojums sapludinātas ar Attīstīt Arī, , kad atbrīvot filiāle ir pabeigta. (Ja darbs Attīstīt nekavējoties pieprasa šo labojums un nevar gaidīt, kamēr atbrīvot filiāle ir pabeigta, var droši sapludināt labojums par deveolp Arī.)

Beidzot, izņemiet filiāle Pagaidu:

$ git Branch -labojumfailu d-1.2.1
# Svītrots filiāle labojumfails-1.2.1 (bija abbe5d6).

Kopsavilkuma

Lai gan nekas patiešām ārkārtas šajā filiāles modelis, sākumā pastu skaitlis var būt ļoti noderīga mūsu projektos. Viņa rāda garīgās modelis viegli saprotama un ļauj darba grupas dalībniekiem, lai izstrādātu vienotu izpratni par procesiem sazarojuma un atbrīvojot.

Augstas kvalitātes PDF versijā šis skaitlis ir sniegta sākotnējā pastu blog: http://nvie.com/posts/a-successful-git-branching-model/ [vai Download saites]. Iet uz priekšu un nodot to pie sienas ātrai pārskatīšanai, lai jebkurā laikā.

Kopā hits: 8810

Komentāru par “Veiksmīgo modeli, filiāļu Git

  1. Deivson dzimšanas teica:

    labdien, Zinu, ka Git sākotnēji izstrādāja Linux sistēmu, bet runājot pārnesamība, Brīnums, ja Git operētājsistēmā windows un POSIX MSIS??

atstāt atbildi

E-pasta adrese netiks publicēta. Obligātie lauki ir atzīmēti ar *