3.5 Git branĉantaj - Foraj (Remote) Branĉoj

Fora referencoj estas referencoj (punteros) en via fora deponejoj, inter branĉoj, etikedoj, kaj tiel plu. Vi povas akiri kompletan liston de fora referencoj eksplicite kun git ls-remote [remote] , aŭ git remote show [remote] por foraj branĉoj tiel kiel pli informo. Tamen, pli komuna vojo estas utiligi fora-spurado branĉoj.
 
Fora-spurado brancxoj estas referencoj al la stato de foraj branĉoj. Ili estas lokaj referencoj ke vi povas movi; ili estas movita aŭtomate por vi kiam vi fari ajnan reto komunikado. Fora-spurado branĉoj agi kiel legosignojn memorigi vin kie la branĉoj en via fora deponejoj estis la lasta tempo vi konektis al ili.
Ili prenas la formon (remote)/(branch) . Ekzemple, se vi volas vidi kion la master branĉo sur via origin fora similis kiel de la lasta tempo vi komunikis kun ĝi, vi kontrolus la origin/master branĉo. Se vi laboras pri temo kun partnero kaj ili puŝis kontrauxulon iss53 branĉo, vi eble havos vian propran lokan iss53 branĉo; sed la branĉo sur la servilo notus al la commit de origin/iss53 .
 
Tio povas esti iom konfuza, do ni rigardu ekzemplon. Imagu ke vi havas Git servilo en via reto ĉe git.ourcompany.com . Se vi kloni el tiu, Git la clone komando aŭtomate nomoj origin por vi, tiras malsupren cxiujn liajn datumojn, kreas sagon al kie lia master brancxo, kaj nomoj ĝi origin/master loke. Git ankaŭ donas vin via propra loka master branĉo startanta je la sama loko kiel origino la master branĉo, do vi havas ion labori de.

noto: "Origino" estas ne speciala

Ĝuste kiel la branĉo nomo "majstro" ne havas neniun specialan signifon en Git, nek faras "origino". Dum "majstro" estas la defaŭlta nomo por startanta branĉo kiam vi kuros git init kiu estas la nura kialo ĝi estas vaste uzata, "origino" estas la defaŭlta nomo por fora kiam vi kuros git clone . Se vi kuras git clone -o booyah anstataŭe, tiam vi havos booyah/master kiel via defaŭlta fora branĉo.

Figuro 3-22. Servilo kaj lokaj deponejoj post klonado

Se vi fari iun laboron sur via loka master branĉo, kaj, intertempe, iu alia pelas git.ourcompany.com kaj ĝisdatigas lia master branĉo, tiam via historioj antaŭeniri malsame. Ankaŭ, kiel longe kiel vi restu ekster kontakto kun via origino servilo, via origin/master montrilon ne movas.

Figuro 3-23. Lokaj kaj fora laboro povas malkonverĝi

Sinkronigi vian laboron, vi kuri git fetch origin komando. Admono suprenrigardas kiu servilo "origino" estas (en tiu kazo, ĝi estas git.ourcompany.com ), akiras ajnan datumon de ĝi ke vi ankoraŭ ne havas, kaj ĝisdatigas via loka datumbazo, movanta via origin/master montrilon al lia nova, pli supren-ĝis-dato pozicio.

Figuro 3-24. git fetch ĝisdatigojn via fora referencoj

Pruvi havi multoblajn foraj serviloj kaj kion foraj branĉoj por tiuj foraj projektoj aspekti, ni supozu vi havas alian internan Git servilo kiu estas uzita nur por disvolviĝo per unu el viaj spurto teamoj. Tiu servilo estas ĉe git.team1.ourcompany.com . Vi povas aldoni ĝin kiel nova fora referenco al la projekto vi aktuale prilaboras per kurante la git remote add komandon kiel ni kovris en Git Bazaj . Nomu tiu fora teamone , kiu estos via shortname por ke tutaj URL.

Kalkuli 3-25. Aldonante alian servilo kiel fora

Nun vi povas kuri git fetch teamone venigi ĉiun la fora teamone servilo havas ke vi ne havas ankoraŭ. Ĉar tiu servilo havas subaro de la datumoj vian origin servilo havas nun, Git akiras datumoj sed metas fora-spurado branĉo nomita teamone/master atentigi al la commit ke teamone havas kiel master branĉo.

Figuro 3-26. Izolita sekvado branĉo por teamone/master

puŝante

Kiam vi volas dividi branĉo kun la mondo, vi bezonas puŝi ĝin al fora ke vi havas skribpermeson por. Lokalajn branĉoj ne aŭtomate sinkronigita al la Remotes vi skribu al - vi devas eksplicite puŝi la branĉoj ili volas dividi. KE vojo, Vi povas uzi privatajn branĉoj por laboro vi ne volas dividi, kaj puŝi supren nur la temo branĉoj vi volas kunlabori plu.
Se vi havas branĉon nomita serverfix ke vi deziras labori sur kun aliaj, vi povas puŝi ĝin la sama vojo vi puŝis vian unuan branĉon. Kuri git push <remote> <branch> :

  $ Git puŝo origino serverfix
Counting objects: 24, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (15/15), done.
Writing objects: 100% (24/24), 1.91 KiB | 0 bytes/s, done.
Total 24 (delta 2), reused 0 (delta 0)
To https://github.com/schacon/simplegit
 * [new branch] serverfix -> serverfix 

Tiu estas iom de ŝparvojo. Git aŭtomate vastigas la serverfix branchname al refs/heads/serverfix:refs/heads/serverfix , kio signifas "Prenu mian serverfix loka branĉo kaj puŝi ĝin al ĝisdatigi la fora la serverfix branĉo." Ni transiru la refs/heads/ parto detale en Git internals , sed vi povas ĝenerale forlasi ĝin. Vi povas ankaŭ fari git push origin serverfix:serverfix , kiuj faras la saman aferon - li diras, "Prenu mian serverfix kaj fari la fora la serverfix." Vi povas uzi tiun formaton por puŝi loka branĉo en fora branĉo nomata alimaniere . Se vi ne volas ĝin nomi serverfix sur la fora, vi povus anstataŭe kuras git push origin serverfix:awesomebranch puŝi vian lokan serverfix branĉo al la awesomebranch branĉo sur la fora projekto.

noto

Ne tajpas vian pasvorton ĉiufoje

Se vi uzas HTTPS URL puŝi super la Git-servilo petos vin pri via uzantnomo kaj pasvorto por aŭtentokontrolo. Defaŭlte ĝi instigos vin sur la fina stacio por tiu informo tiel la servilo povas diri se vi rajtas puŝi.
Se vi ne volas tajpi ĝin ĉiu ununura tempo vi puŝi, vi povas starigi "credencial kaŝmemoro". La plej simpla estas ĝuste konservi ĝin en memoro dum kelkaj minutoj, kiujn vi povas facile agordi per kurado git config --global credential.helper cache .
Por pli informo sur la diversaj credencial caching ebloj disponeblaj, vidi Credencial Tenado .

La venontan fojon unu el viaj kunlaborantoj akiras de la servilo, ili ricevos referenco al kie la servila versio de serverfix estas sub la fora branĉo origin/serverfix :

  $ Git venigu origino
remote: Counting objects: 7, done.
remote: Compressing objects: 100% (2/2), done.
remote: Total 3 (delta 0), reused 3 (delta 0)
Unpacking objects: 100% (3/3), done.
From https://github.com/schacon/simplegit
 * [new branch] serverfix -> origin/serverfix 

Estas grave noti, ke kiam vi faros venigi kiu alportas malsupren nova fora-spurado branĉoj, vi ne aŭtomate havas lokan, redakteblaj kopiojn de ili. Alivorte, en tiu kazo, vi ne havas novan serverfix branĉo - vi nur havas origin/serverfix puntero ke vi ne povas modifi.
Kunfandi ĉi laboro en via nuna laboro branĉo, vi povas kuri git merge origin/serverfix . Se vi volas vian propran serverfix brancxon vi povas labori sur, vi povas bazi vian fora-spurado branĉo:

  $ Git kaso -b serverfix origino / serverfix
Branch serverfix set up to track remote branch serverfix from origin.
Switched to a new branch 'serverfix' 

Tio donas al vi lokan filion ke vi povas labori sur kiu komenciĝas kie origin/serverfix estas.

Spuranta Branĉoj

Kontrolanta loka branĉo de fora-spurado branĉo aŭtomate kreas kio nomiĝas "sekvado branĉo" (kaj la branĉo ĝi spuras nomiĝas "kontraŭflue branĉo"). Spuranta branĉoj estas lokaj filioj kiuj havas rektan rilaton al fora branĉo. Se vi estas sur sekvado branĉo kaj tipon git pull , Git aŭtomate scias kion servilo por preni de kaj branĉo kunfandi en.
Kiam vi kloni deponejo, ĝi ĝenerale aŭtomate kreas master branĉo kiu spuras origin/master . Tamen, vi povas instali aliajn sekvado branĉoj se vi deziras - kiuj spuras branĉoj sur aliaj Remotes, aŭ ne spuri la master branĉo. La simpla kazo estas la ekzemplo vi ĵus vidis, kurante git checkout -b [branch] [remotename]/[branch] . Tiu estas komuna sufiĉe operacio kiu git provizas la --track stenografio:

  $ Git kaso --track origino / serverfix
Branch serverfix set up to track remote branch serverfix from origin.
Switched to a new branch 'serverfix' 

Fakte, tio estas tiel komuna, ke estas eĉ ŝparvojo por ŝparvojo. Se la branĉo nomo vi provas kaso (al) ne ekzistas kaj (b) ekzakte egalas nomon sur nur unu fora, Git kreos sekvado branĉo por vi:

  $ Git kaso serverfix
Branch serverfix set up to track remote branch serverfix from origin.
Switched to a new branch 'serverfix' 

Starigi lokan filion kun malsama nomo ol la izolita branĉo, vi povas facile uzi la unuan version kun malsama loka branĉo nomo:

  $ Git kaso -b sf origino / serverfix
Branch sf set up to track remote branch serverfix from origin.
Switched to a new branch 'sf' 

Nun, via loka branĉo sf aŭtomate tiri el origin/serverfix .
Se vi jam havas lokan branĉon kaj volas restarigi gxin al malproksima branĉo vi ĵus tirita malsupren, aŭ volas ŝanĝi la kontraŭflua branĉo vi sekvado, vi povas uzi la -u aŭ --set-upstream-to eblo git branch eksplicite metis ĝin ĉe ajna tempo.

  $ Git branĉo -u origino / serverfix
Branch serverfix set up to track remote branch serverfix from origin. 

noto

kontraŭflue stenografio

Kiam vi havas sekvado branĉo instalita, vi povas referenci ĝia kontraŭflua branĉo kun la @{upstream} aŭ @{u} stenografio. Sekve se vi estas sur la master branĉo kaj ĝi spuras origin/master , vi povas diri ion kiel git merge @{u} anstataŭ git merge origin/master se vi deziras.

Se vi deziras vidi kion sekvado branĉoj vi starigis, vi povas uzi la -vv eblon git branch . Ĉi listigos vian lokan branĉoj kun pli informo inkluzivanta kio ĉiu branĉo estas spurado kaj se via loka branĉo estas antaŭe, malantaŭe aŭ ambaŭ.

  $ Git branĉo -vv
 iss53 7e424c3 [origin/iss53: ahead 2] forgot the brackets
 master 1ae2a45 [origin/master] deploying index fix
* serverfix f8674d9 [teamone/server-fix-good: ahead 3, behind 1] this should do it
 testing 5ea463a trying something new 

Do jen ni vidas ke nia iss53 branĉo estas sekvado origin/iss53 kaj estas "antaŭen" per du, kio signifas ke ni havas du interna loke kiuj ne puŝita al la servilo. Ni ankaŭ povas vidi ke nia master branĉo estas sekvado origin/master kaj estas ĝisdata. Ni tuj povas vidi ke nia serverfix branĉo estas spuras la server-fix-good branĉo sur nia teamone servilo kaj estas antaŭeniras por tri kaj malantaŭe per unu, Signifanta ke la sama faris sur la servilo ni ne kunfalis en ankoraŭ tri interna loke ke ni ne puŝis. Ni fine povas vidi ke niaj testing branĉo ne sekvado ajna fora branĉo.
Estas grave noti, ke tiuj nombroj estas nur ekde la lasta tempo vi prenis el ĉiu servilo. Tiu komando ne atingi ekstere al la serviloj, ĝi estas diranta vin pri kio ĝi cached el tiuj serviloj loke. Se vi volas tute ĝisdata antaŭen kaj malantaŭ nombroj, vi bezonos por alporti de cxiuj viaj Remotes ĝuste antaŭ kuri ĉi. Vi povus fari tion tiel: git fetch --all; git branch -vv git fetch --all; git branch -vv

tirante

Dum la git fetch komando alportos malsupren ĉiujn ŝanĝojn sur la servilo, kiun vi ne havas ankoraŭ, ĝi ne modifas vian labordosierujon ajn. Ĝi simple akiras la datumojn por kaj vin kunfandi ĝin mem. Tamen, tie estas komando nomita git pull kiu estas esence git fetch tuj sekvata de git merge en plej kazoj. Se vi havas sekvado branĉo starigis kiel pruvis en la lasta sekcio, ĉu per eksplicite fiksante ĝin aŭ havi ĝin kreis por vi de la clone aŭ checkout komandojn, git pull mi atendas kion servilo kaj disbranĉigi viaj nunaj branĉo estas sekvado, venigi de tiu servilo kaj tiam provu kunfandi en tiu fora branĉo.
Ĝenerale estas pli bone simple uzi la fetch kaj merge komandojn eksplicite kiel la magio de git pull povas ofte esti konfuza.

Viŝante Izolita Branĉoj

Supozi vi faris kun fora branĉo - diru al vi kaj viaj kunlaborantoj estas finita kun esprimilo kaj kunfandis ĝin en via fora la master branĉo (aŭ ajna branĉo via stabila codeline estas). Vi povas forviŝi fora branĉo uzante la --delete eblon git push . Se vi volas forigi vian serverfix branĉo de la servilo, vi kuras la sekvaj:

  $ Git puŝo origino --delete serverfix
To https://github.com/schacon/simplegit
 - [deleted] serverfix 

Esence ĉiuj ĉi faras estas forigi la puntero de la servilo. La Git servilo ĝenerale konservi la datumojn tie por tempeto ĝis rubo kolekto kuras, do se oni hazarde forviŝita, ĝi estas ofte facile rekuperi.

prev | sekva