Git filialas, šakutė, parsisiuntimas, sujungimas, atkūrimas ir klonas, kokie yra skirtumai?

Ar kas nors gali man padėti suprasti skirtumą tarp šakos, šakutės ir klono Gite?

Panašiai, ką tai reiškia, kai aš git fetch , o ne git pull ?

Be to, ką reiškia „ rebase palyginti su merge ?

Kaip aš galiu sutraiškyti asmenį kartu?

Kaip jie naudojami, kodėl jie naudojami ir ką jie atstovauja?

Kaip atrodo github?

460
25 июля '10 в 19:14 2010-07-25 19:14 Jackiekazil paklausė liepos 25 d. 10 val. 19:14 2010-07-25 19:14
@ 5 atsakymai

Klonas yra tik kapinyno kopija. Iš pirmo žvilgsnio jo rezultatas yra lygiavertis svn checkout , kuriame atsisiunčiate šaltinio kodą iš kitos saugyklos. Skirtumas tarp centralizuotos VCS, pvz., „Subversion“ ir „DVCS“, pvz., „Git“, yra tas, kad „Git“ klonuojant jūs iš tikrųjų nukopijuojate visą šaltinio saugyklą, įskaitant visą istoriją ir filialus. Dabar jūsų kompiuteryje yra nauja saugykla, ir visi jūsų padaryti įsipareigojimai yra įtraukti į šią saugyklą. Niekas nematys jokių pakeitimų, kol nepaspaudžiate šių įvykių kitoje saugykloje (ar originalo) arba kol kažkas nustos vykdyti savo saugyklą, jei ji yra viešai prieinama.

Filialas yra kažkas saugykloje. Konceptualiai tai reiškia vystymosi srautą. Paprastai turite pagrindinį filialą, bet jūs taip pat galite turėti filialą, kuriame dirbate su kai kuria funkcija xyz, o kitą - koreguoti klaidą abc. Kai patikrinote filialą, visi jūsų prisiimti įsipareigojimai liks toje šakoje ir nebus bendrinami su kitais filialais tol, kol juos sujungsite ar pakeisite atitinkamu filialu. Žinoma, „Git“ atrodo šiek tiek keista, kai kalbama apie filialus, kol pamatysite pagrindinį filialų įgyvendinimo modelį. Vietoj to, kad tai paaiškintumėte (aš jau sakiau per daug, sakoma), aš susisieksiu su „kompiuterių mokslu“, paaiškindamas, kaip „Git“ modeliuoja filialus ir įsipareigoja iš „Git“ svetainės:

http://eagain.net/articles/git-for-computer-scientists/

Šakė nėra „Git“ sąvoka, o politinė / socialinė idėja. Tai yra, jei kai kurie žmonės nepatenkina, kaip projektas vyksta, jie gali paimti šaltinį ir dirbti patys atskirai nuo originalių kūrėjų. Tai bus laikoma šakute. „Git“ leidžia lengvai ieškoti, nes kiekvienas jau turi savo „kodą“, todėl taip paprasta, kaip nukirpti nuorodas į pradinius projekto kūrėjus ir nereikia eksportuoti istorijos iš bendros saugyklos, kaip jums gali tekti su SVN.

EDIT: Kadangi aš nežinojau apie modernią „GitHub“ svetainių naudojamą šakutės apibrėžtį, prašome pažvelgti į komentarus, taip pat Michael Durrant atsakymą žemiau mano, kad gautumėte daugiau informacijos.

346
25 июля '10 в 19:27 2010-07-25 19:27 atsakymas pateikiamas sirido liepos 25 d., 10 val., 19:27, 2010-07-25 19:27

Git

Mano atsakymas apima „github“, kurį taip pat paklausė daugelis žmonių.

Vietos saugyklos

„git“ (lokaliai) turi katalogą (.git), prie kurio pridedate failus, ir tai yra „vietinė saugykla“. Tai skiriasi nuo sistemų, tokių kaip svn, kur jūs iškart pridedate ir priskirtumėte nuotolinį saugyklą.

„git“ saugo kiekvieną failo versiją, modifikuotą išsaugant visą failą. Tai taip pat skiriasi nuo svn šiuo atžvilgiu, nes galite pereiti prie bet kurios konkrečios versijos, nesukuriant per delta pakeitimų.

„git“ neužblokuoja failų ir tokiu būdu neleidžia redaguoti „išskirtinio užrakto“ funkcionalumo (vyresnio amžiaus sistemos, pvz., PVC, atsimena), todėl visi failai visada gali būti redaguojami, net jei jie yra savarankiški. failo pakeitimai (per tą patį failą!) Kartu per ekstruzijas arba ištraukimą / spaudimą į nuotolinį saugyklą, pvz., „github“. Vienintelis laikas, kai reikia atlikti rankinius pakeitimus (faktiškai redaguojant failą) yra tas, kad dviejuose pakeitimuose naudojamos tos pačios kodo eilutės.


border=0

Filialai

Filialai leidžia išsaugoti pagrindinį kodą (filialo „meistras“), sukurti kopiją (naują filialą) ir tada dirbti šiame naujame skyriuje. Jei darbas trunka šiek tiek laiko, arba kapitonas gauna daug naujinimų, nes filialas buvo sukurtas, turite sujungti arba perkrauti (dažniausiai pageidaujate geresnės istorijos ir lengviau išspręsti konfliktus) dirbti su pagrindiniu filialu. Kai baigsite, sujungsite filialo pakeitimus į pagrindinę saugyklą. Daugelis organizacijų naudoja filialus kiekvienai darbo daliai, neatsižvelgiant į tai, ar tai yra funkcija, klaida, ar darbo objektas. Kitos organizacijos filialus naudoja tik svarbiems pakeitimams, pvz., Versijų atnaujinimui. Šakė: su filialu, jūs valdote ir valdote šaką, o su šakute, kažkas valdo kodo priėmimą atgal.
Apskritai, yra du pagrindiniai filialų priežiūros būdai. Pirmasis - išsaugoti didžiausią pagrindinio filialo pakeitimų dalį, naudojant tik filialus didesnėms ir ilgesnėms operacijoms, pvz., Versijų pakeitimus, kuriuose norite turėti dvi šakas skirtingiems poreikiams. Antra, jūs iš esmės išskiriate kiekvieną funkcijų užklausą, ištaisote klaidas arba atlikite užduotis ir tada rankiniu būdu nuspręsite, kada faktiškai sujungti šiuos filialus į pagrindinį pagrindinį filialą. Nors tai skamba varginantis, tai yra bendras požiūris, kurį dabar naudoja ir rekomenduoju, nes jis padeda išvalyti pagrindinį filialą, ir tai yra kapitonas, kurį skatiname gaminti, todėl norime tik pilną, patvirtintą kodą perkeliant ir sujungiant šakos.

Standartas, kaip susieti filialą „in“ su kapitonu, yra merge . Filialai taip pat gali būti rebase d, kad „išvalytumėte“ istoriją. Tai neturi įtakos dabartinei būklei ir yra daroma siekiant suteikti „švarią“ istoriją. Iš esmės, idėja yra ta, kad jūs sukietėjote iš tam tikro taško (paprastai iš šeimininko). Kadangi jūs esate platus „šeimininkas“, jis pats persikėlė į priekį. Taigi būtų aiškiau, jei visi pokyčiai, kuriuos padarėte filiale, būtų atliekami su naujausiais meistrais su visais jo pakeitimais. Taigi procesas: išsaugokite pakeitimus; gaukite „naują“ vedlį ir dar kartą pritaikykite pakeitimus. Atminkite, kad, pavyzdžiui, sujungimas, gali sukelti konfliktus, kuriuos turite išspręsti rankiniu būdu (redaguoti).

Vienas „orientyras“, į kurį reikia atkreipti dėmesį: tik perkelkite, jei filialas yra vietinis ir dar nepaspaudėte nuotolinio valdymo pulto. . Taip yra daugiausia dėl to, kad perkrovimas gali pakeisti istoriją, kurią mato kiti žmonės.

Stebėjimo šakos

Tai yra filialai, pavadinti kilme / filialo pavadinimu (o ne filialo vardas). Kai paspaudžiate ir traukiate kodą į / iš nuotolinių saugyklų, tai iš tikrųjų yra mechanizmas, per kurį tai vyksta. Pvz., Jei git push filialą, vadinamą „building_groups“, jūsų filialas pirmą kartą prasideda nuo kilmės / pastato_grupių, o tada eina į nuotolinį saugyklą (iš tikrųjų tai yra pernelyg supaprastinta, bet šiuo metu pakankamai gera). Panašiai, jei darote „ git fetch building_groups , tada gautas failas yra įdėtas į kilmės / pastato_grupių filialą. Tada galite susieti šį filialą su vietine kopija. Mūsų praktika yra visada atlikti „git fetch“ ir „manual“ susijungimą, o ne tik „git pull“ (kurios abi atliekamos vienu žingsniu).

Fetch naujų filialų.

Naujų šakų gavimas: pradžioje klonas turėsite visas šakas. Tačiau, jei kiti kūrėjai prideda filialus ir spustelės nuotolinio valdymo pultą, turi būti būdų „žinoti“ apie šiuos filialus ir jų pavadinimus, kad būtų galima juos ištraukti vietoje. Tai daroma per git fetch , kuris gaus visus naujus ir modifikuotus filialus į vietinę saugyklą, naudodamas stebėjimo šakas (pvz., Kilmę /). Po „ Fetch ed“ galite git branch --remote sąraše stebėjimo šakas ir „ git checkout [branch] kad iš tikrųjų pereitumėte prie bet kokio konkretaus.

Susijungimas

Sujungimas yra kodų pakeitimų sujungimo iš skirtingų šakų ar skirtingų tos pačios šakos versijų procesas (pvz., Kai vietinis filialas ir nuotolinis kompiuteris nėra sinchronizuojami). Jei sukūrėte filialo darbą, o darbas yra baigtas, pasiruošęs ir išbandytas, jis gali būti sujungtas į master filialą. Tai daroma naudojant „ git checkout master kad pereitumėte į master filialą, o tada git merge your_branch . Sujungimas sujungs visus skirtingus failus ir netgi skirtingus pakeitimus į tuos pačius failus. Tai reiškia, kad jis iš tikrųjų pakeis failų kodą ir sujungs visus pakeitimus. Atliekant checkout master pat rekomenduojama atlikti „ git pull origin master , kad galėtumėte gauti naujausią nuotolinio valdiklio versiją kartu su vietiniu magistru. Jei nuotolinis valdiklis pasikeitė, ty į moved forward , matysite informaciją, kuri atspindi šį git pull metu. Jei taip yra (kapitonas keičiamas), rekomenduojame git checkout your_branch ir tada jį rebase kad galėtumėte valdyti, kad pakeitimai iš tikrųjų „pakartotų“ per „naują“ kapitoną. Tada tęskite naujinimo vedlį, kaip parodyta kitoje pastraipoje.

Jei konflikto nėra, vedlys pridės naujų pakeitimų. Jei yra konfliktų, tai reiškia, kad tie patys failai keičiasi panašių kodų eilutėse, kurių jis negali automatiškai sujungti. Tokiu atveju „ git merge new_branch “ praneša, kad konfliktas buvo išspręstas. „Leisite“ juos redaguodami failus (kurie turės abu pakeitimus), pasirinkdami reikiamus pakeitimus, tiesiogine tvarka ištrindami tų pakeitimų eilutes, kurių nenorite, ir išsaugokite failą. Pakeitimai pažymėti ribotuvais, pvz., ======== ir <<<<<<<<

Kai išspręsite bet kokius konfliktus, jūs vėl git add ir git commit šiuos pakeitimus, kad tęstumėte susijungimą (per šį procesą git bus gauta atsiliepimų apie gitą). Kai procesas neveikia, pastebėsite, kad „ git merge --abort labai patogus dalykų git merge --abort .

Interaktyvus perkrovimas ir paskirstymas / pertvarkymas / ištrynimas

Jei, pavyzdžiui, atlikote darbą su mažais žingsniais. Jei kiekvieną dieną įvesite kodą kaip „nebaigtą darbą“, galbūt norėsite „skvošti“ tuos mažus mažus įsipareigojimus keliems dideliems įsipareigojimams. Tai gali būti ypač naudinga, jei norite su kolegomis peržiūrėti kodų peržiūrą. Jūs nenorite atkurti visų „žingsnių“, kuriuos atlikote (per įsipareigojimus), tiesiog norėtumėte pasakyti, kad tai yra visų mano atliktų pakeitimų galutinis efektas (dif) viename įvykyje. Svarbiausias veiksnys, į kurį reikia atsižvelgti svarstant, ar tai padaryti, yra tai, kad kelios įsipareigoja prieš tą patį failą ar failus daugiau nei vieną kartą (šiuo atveju skvošas yra geriau). Tai daroma naudojant interaktyvų atkūrimo įrankį. Šis įrankis leidžia jums pereiti per įsipareigojimus, ištrinti įsipareigojimus, perrašyti pranešimus ir tt Pavyzdžiui, git rebase -i HEAD~10 Atkreipkite dėmesį, kad ~ NOT a - sukelia:
2019

502
09 февр. Michael Durrant atsakymas 09 vasaris 2012-02-09 05:09 '12 at 5:09 2012-02-09 05:09

Čia yra Oliver Steele įvaizdis, kaip visa tai tinka:

2019

134
22 янв. Atsakymas pateikiamas Contango sausio 22 d 2013-01-22 20:12 '13, 08:12 pm 2013-01-22 20:12

Tiesiog pridėti prie kitų, pastabų, susijusių su šakėmis.

Gerai suprantama, kad techniškai repo klonavimas ir repo dislokavimas yra vienas ir tas pats. Tuo:

 git clone $some_other_repo 

ir jūs galite paliesti save iš užpakalinės pusės - jūs tiesiog sumušė kitą repo.

„Git“, kaip ir VCS, faktiškai klonuoja žymėjimą. Be „paprasto naršymo“, naudojant nuotolinę vartotojo sąsają, pvz., „Cgit“, yra labai mažai bendro su „git repos“, kuri neapima šakinio , klonavimo repo.

Tačiau

  • kai kas nors sako, kad aš atrakinau repo X , jie reiškia, kad jie sukūrė repo kloną kitur, siekdami atskleisti kitus, pavyzdžiui, rodyti kai kuriuos eksperimentus arba naudoti skirtingus prieigos kontrolės mechanizmus (pvz., žmones, kurie neturi prieigos prie „Github“, su jūsų įmonės vidaus sąskaitą).

    Факты, которые: репо, скорее всего, создано с другой командой, чем git clone , что он, скорее всего, размещен где-то на сервере, как против кого-то ноутбука, и, скорее всего, немного отличается формат (это "голый репо", т.е. без рабочего дерева) все просто технические детали.