segunda-feira, 13 de junho de 2016

3.2 Git branĉantaj - Bazaj branĉantaj kaj kunfando

3.2 Git branĉantaj - Bazaj branĉantaj kaj kunfando

Ni iru tra simpla ekzemplo de branĉantaj kaj kunfalado kun laborfluo ke vi povus uzi en la reala mondo. Vi sekvu tiujn paŝojn:
  1. Ĉu labori sur retejo.
  2. Krei branĉon por nova rakonto vi laboras plu.
  3. Fari iun laboron en tiu branĉo.
En tiu stadio, Vi ricevos alvokon ke alia afero estas maltrankviliga kaj vi bezonas hotfix. Vi faros la sekvajn:
  1. Ŝanĝi viajn produktado branĉo.
  2. Krei branĉon aldoni la hotfix.
  3. Post ĝi estas provita, kunfandi la hotfix branĉo kaj frapas al produktado.
  4. Ŝanĝi reen al via originala rakonto kaj daŭre labori.

baza branĉantaj

Unue, diru vi laboras en via projekto kaj havas paron de interna jam.
Simpla fari historion.
Figuro 3-10. Simpla commit historio
Vi decidis ke vi estas iranta labori sur temo numero 53 en ajna temo-sekvado sistemo via kompanio uzas. Krei branĉon kaj ŝanĝi al ĝi samtempe, vi povas kuri la git checkout komando kun la -b ŝaltilo:
  $ Git kaso -b iss53
Switched to a new branch "iss53" 
Tio estas stenografio por:
  $ Git branĉo iss53
 $ Git kaso iss53 
Kreante nova branĉo montrilo.
Figuro 3-11. Krei novan branĉon montrilon
Vi laboras en via retejo kaj fari iu interna. Farante tiel movas la iss53 branĉo antaŭen, ĉar vi havas ĝin Taksis (te viajn HEAD notas al tio):
  $ Vim index.html
 $ Git commit -a -m 'added a new footer [issue 53]' 
La iss53 branĉo movis antaŭen kun via laboro.
Figuro 3-12. La iss53 branĉo movis antaŭen kun via laboro
Nun vi ricevas la alvokon kiu estas temo kun la retejo, kaj necesas korekti ĝin tuj. Kun Git, vi ne devas disfaldi vian solvon kune kun la iss53 ŝanĝojn vi faris, kaj vi ne devas meti multe da penado en revertir tiuj ŝanĝoj antaux vi povas labori sur apliki solvon al kio estas en produktado. Ĉiuj vi devas fari estas reiri al via master branĉo.
Tamen, antaŭ ol fari tion, rimarku ke se via labordosierujon aŭ enscenigante areo havas uncommitted ŝanĝoj kiuj konfliktas kun la branĉo vi ekiras, Git ne permesos vin ŝanĝi branĉoj. Ĝi estas bona havi puran laborista stato kiam vi ŝanĝos branĉoj. Ekzistas manieroj por preni ĉirkaŭ ĉi (nome stashing farante amendi) kiu kovros poste, en Stashing kaj Pureco . Nuntempe, ni supozu vi faris ĉiujn viajn ŝanĝojn, do vi povas reiri al via master branĉo:
  $ Git kaso mastro
Switched to branch 'master' 
Ĉe tiu punkto, via projekto laboranta dosierujo estas ĝuste la vojo ĝi estis antaŭ vi komencis labori pri temo numero 53, kaj povas koncentri sur via hotfix. Tio estas grava punkto memori: kiam vi ŝanĝos branĉoj, Git restarigas vian labordosierujon rigardi kiel ĝi faris la lastan fojon vi faris en tiu branĉo. Ĝi aldonas, forigas, kaj modifas dosierojn aŭtomate certigi via laboranta kopio estas kion la branĉo rigardis kiel en via lasta faras al ĝi.
Sekva, Vi havas hotfix fari. Ni kreos hotfix branĉo sur kiu labori ĝis ĝi estas finita:
  $ Git kaso -b hotfix
Switched to a new branch 'hotfix'
 $ Vim index.html
 $ Git commit -a -m 'fixed the broken email address'
[hotfix 1fb7853] fixed the broken email address
 1 file changed, 2 insertions(+) 
Hotfix branĉo bazita sur `master`.
Figuro 3-13. Hotfix branĉo surbaze master
Vi povas kuri vian provoj, certigi la hotfix estas kion vi deziras, kaj kunfandi ĝin en vian master branĉo deploji al produktado. Vi faras tion per la git merge komando:
  $ Git kaso mastro
 $ Git merge hotfix
Updating f42c576..3a0874c
Fast-forward
 index.html | 2 ++
 1 file changed, 2 insertions(+) 
Vi rimarkos la frazo "rapida antaŭen" en tiu merge. Ĉar la commit C4 almontras la branĉo hotfix vi kunfalis en estis rekte antaŭ la commit C2 vi estas sur, Git simple movas la montrilon antaŭen. Al frazo kiu alia vojo, kiam vi provas kunfandi unu faras kun fari ke povas esti atingita sekvante la unua fari la historion, Git simpligas aferojn movante la montrilon antaŭen ĉar ne ekzistas diferencaj laboro por kunfandi kune - tio nomiĝas " rapida antaŭen. "
Via ŝanĝo estas nun en la instantánea de la commit pintaj al la master branĉo, kaj vi povas disfaldi la solvon.
`Master` estas rapida plusendita al` hotfix`.
Figuro 3-14. master estas rapida plusendita al hotfix
Post via super- grava fix estas deplojitaj, vi pretas reiri al la laboro vi faris antaux vi interrompis. Tamen, unue vi devos forigi la hotfix branĉo, ĉar vi ne plu bezonas ĝin - la master branĉo punktoj al la sama loko. Vi povas forigi ĝin per la -d elekto git branch :
  $ Git branĉo -d hotfix
Deleted branch hotfix (3a0874c). 
Nun vi povas reiri al via agado-en-progreso branĉo sur temo numero 53 kaj daŭre labori sur ĝi.
  $ Git kaso iss53
Switched to branch "iss53"
 $ Vim index.html
 $ Git commit -a -m 'finished the new footer [issue 53]'
[iss53 ad82d7a] finished the new footer [issue 53]
1 file changed, 1 insertion(+) 
Laboro daŭras sur `iss53`.
Kalkuli 3-15. Laboro daŭras sur iss53
Ĝi valoras notanta tie ke la laboro vi faris en via hotfix branĉo ne enhavita en la dosierojn en via iss53 branĉo. Se vi bezonas tiri ĝin, vi povas kunfandi viajn master branĉo en vian iss53 branĉo de kuranta git merge master , aŭ vi povas atendi integri tiujn ŝanĝojn ĝis vi decidas tiri la iss53 branĉo reen en master poste.

baza kunfando

Supozi vi decidis, ke via temo numero 53 laboro estas kompleta kaj preta esti kunfandita en via master branĉo. Por fari tion, vi kunfandi viajn iss53 branĉo en master , multe kiel vi kunfalis via hotfix branĉo antaŭe. Ĉiuj vi devi fari estas kontroli la branĉo vi volas kunfandi en kaj poste ekzekuti la git merge komando:
  $ Git kaso mastro
Switched to branch 'master'
 $ Git merge iss53
Merge made by the 'recursive' strategy.
index.html | 1 +
1 file changed, 1 insertion(+) 
Tio aspektas iom malsama ol la hotfix kunfandi vi faris antaŭe. Tiukaze, via evoluo historio diverĝis el kelkaj malnovaj punkto. Ĉar la commit de la branĉo vi estas sur ne estas rekta prapatro de la branĉo vi kunfalado en, Git devas fari iun laboron. Tiukaze, Git faras simplan tridirekta merge, uzante la du instantáneas almontras la branĉo konsiletoj kaj la komuna prapatro de la du.
Tri instantáneas uzita en tipa merge.
Kalkuli 3-16. Tri instantáneas uzita en tipa merge
Anstataŭ simple kopii la branĉo montrilon antaŭen, Git kreas novan instantánea kiu rezultas de tiu triopa merge kaj aŭtomate kreas novan fari ke punktoj al ĝi. Tio estas referita kiel merge fari, kaj estas speciala ĉar ĝi havas pli ol unu gepatro.
A merge fari.
Kalkuli 3-17. A merge commit
Ĝi valoras markante ke Git determinas la plej komuna praulo uzi por lia merge bazo; tiu estas malsama ol malnovaj iloj kiel CVS aŭ Subversion (antaŭ versio 1.5), kie la desarrollador faras la merge devis diveni la plej merge bazo por si. Tio igas kunfalado heck de multe pli facila en Git ol en tiuj aliaj sistemoj.
Nun ke via verko estas kunfanditaj en, vi ne plu bezonas la iss53 branĉo. Vi povas fermi la bileto en via bileto-sekvado sistemo kaj forigi la branĉo:
  $ Git branĉo -d iss53 

Baza Merge Konfliktoj

Foje, tiu procezo ne iras glate. Se vi ŝanĝis la sama parto de la sama dosiero malsame en la du branĉoj vi kunfandante kune, Git ne povos kunfandi ilin pure. Se via fix por temo numero 53 modifis la sama parto de dosiero la hotfix , vi ricevos merge konflikto kiu aspektas io tiamaniere:
  $ Git merge iss53
Auto-merging index.html
CONFLICT (content): Merge conflict in index.html
Automatic merge failed; fix conflicts and then commit the result. 
Git ne aŭtomate kreita nova merge fari. Ĝi paŭzis la procezo dum vi solvas la konflikton. Se vi volas vidi kio dosieroj unmerged ĉe ajna punkto post merge konflikto, vi povas kuri git status :
  $ Git statuso
On branch master
You have unmerged paths.
 (fix conflicts and run "git commit")

Unmerged paths:
 (use "git add <file>..." to mark resolution)

 both modified: index.html

no changes added to commit (use "git add" and/or "git commit -a") 
Io ajn kiu havas kunfandi konfliktoj kaj ne estis solvita estas listigita kiel unmerged. Git aldonas normo konfliktosolvado markiloj al la dosieroj, kiuj havas konfliktojn, do vi povas malfermi ilin permane kaj solvi tiujn konfliktojn. Via dosiero enhavas sekcion, kiu aspektas io tiamaniere:
  <<<<<<< KAPO: index.html
 < Div id = "footer" > kontakto: email.support@github.com < / div >
 =======
 < Div id = "footer" >
  bonvolu kontakti nin ĉe support@github.com
 < / Div >
 >>>>>>> Iss53: index.html 
Tio signifas la versio en HEAD (via master branĉo, ĉar tio estis kion vi Taksis kiam vi kuris via merge komando) estas la supera parto de tiu bloko (ĉio super la ======= ), dum la versio en via iss53 branĉo aspektas kiel ĉiu en la malsupran parton. Por solvi la konflikton, vi devas aŭ elektu unu flanko aŭ la alia aŭ kunfandi la enhavon mem. Ekzemple, vi povus solvi tiun konflikton anstataŭigante la tutan blokon kun ĉi:
  < Div id = "footer" >
 bonvolu kontakti nin ĉe email.support@github.com
 < / Div > 
Tiu rezolucio havas iom de ĉiu sekcio, kaj la <<<<<<< , ======= kaj >>>>>>> linioj estis tute forigita. Post vi malkomponita ĉiu de tiuj sekcioj en ĉiu konfliktis dosiero, kuri git add sur ĉiu dosiero por marki ĝin kiel solvitaj. Enscenigante la dosiero markas ĝin kiel malkomponita en Git.
Se vi volas uzi grafikan ilon por solvi tiujn problemojn, vi povas kuri git mergetool , kiu pafas supren taŭga vida merge ilo kaj piediras vin tra la konfliktoj:
  $ Git mergetool

This message is displayed because 'merge.tool' is not configured.
See 'git mergetool --tool-help' or 'git help config' for more details.
'git mergetool' will now attempt to use one of the following tools:
opendiff kdiff3 tkdiff xxdiff meld tortoisemerge gvimdiff diffuse diffmerge ecmerge p4merge araxis bc3 codecompare vimdiff emerge
Merging:
index.html

Normal merge conflict for 'index.html':
 {local}: modified file
 {remote}: modified file
Hit return to start merge resolution tool (opendiff): 
Se vi volas uzi merge ilo alia ol la defaŭlta (Git elektis opendiff en tiu kazo ĉar la komando estis prizorgita sur Mac), vi povas vidi ĉiujn apogis iloj listigitaj ĉe la supro post "unu el la sekvaj iloj." Ĝuste tajpi la nomon de la ilo vi preferus uzi.
noto
Se vi bezonas pli progresintaj iloj por solvi malfacila merge konfliktoj, ni kovras pli sur kunfalado en Altnivela kunfalado .
Post vi eliras la merge ilo, Git demandas vin se la merge sukcesis. Se vi diros la skripto kiu estis, ĝi enscenigas la dosieron por marki ĝin kiel decidis por vi. Vi povas kuri git status denove por kontroli ke ĉiuj konfliktoj estis solvitaj:
  $ Git statuso
On branch master
All conflicts fixed but you are still merging.
 (use "git commit" to conclude merge)

Changes to be committed:

 modified: index.html 
Se vi estas feliĉa kun tio, kaj vi kontrolos ke ĉiu kiu havis konfliktojn estis enscenigita, vi povas tajpi git commit fini la merge fari. La commit mesaĝon defaŭlte aspektas io tiamaniere:
 Merge branch 'iss53'

Conflicts:
 index.html
#
 # Aspektas kiel vi povas fari la merge.
 # Se tio ne ĝustas, bonvolu forigi la dosieron
 # .git / MERGE_HEAD
 # Kaj reprovu.


 # Bonvolu eniri la commit mesaĝon for viaj ŝanĝoj.  linioj komencante
 # Per '#' estos ignorata kaj malplenan mesaĝon abortas la commit.
 # La branĉo mastro
 # Ĉiuj konfliktoj fiksita sed vi ankoraŭ kunfalado.
#
 # Ŝanĝoj esti farita:
 # Modifita: index.html
# 
Vi povas modifi tiun mesaĝon kun detaloj pri kiel vi solvis la merge se vi pensas ke estus helpema al aliaj rigardi ĉi merge en la estonteco - kial vi faris kion vi faris, se ĝi ne estas evidenta.

Nenhum comentário:

Postar um comentário