Git - pull in branchi

Zanima me kako pullam iz github, tako da imam lokalno več branchev (torej več verzij iste aplikacije) in ko switcham med njimi se požene samo tista verzija?
Torej, da ne pride do merge conflicts, ko pullam drugo verzijo. Hvala.

Ne vem, če te pravilno razumem. Npr. da narediš

git pull origin branch_1

Pa potem takoj za tem (v istem direktoriju):

git pull origin branch_2

Potem ti bo, če sta dve različni verziji istega projekta, prišlo do merge conflicts. Lahko bi imel tudi dva direktorija, pa v vsakem svojo verzijo programa. Ampak mislim, da se to ne dela.
Razen, če preden pullaš branch_2, narediš:

git checkout -b branch_2

Torej kreiraš branch_2 pa pullaš z istega brancha. Potem pa lahko switchaš med različnimi branchi. Samo zanima me, kako se to pravilno dela. Ker zagotovo noben nima za en projekt 5 map in v vsaki mapi ena različica programa.

Hvala.

Kot vedno, Google in RTFM...

No saj, zato je dobro da se pogovorimo. Načeloma sta ta dva stavka kontradiktorna:

Pull/push se naceloma dela za dolocen branch neodvisno od ostalih.

Ti si pulal iz brancha ki ima različno ime kot branch v katerem si trenutno kar se razen v izjemih okoliščiniah ne dela.

marjan_h je 31. okt 2020 ob 17:23 izjavil:

No saj, zato je dobro da se pogovorimo. Načeloma sta ta dva stavka kontradiktorna:

Pull/push se naceloma dela za dolocen branch neodvisno od ostalih.

Ti si pulal iz brancha ki ima različno ime kot branch v katerem si trenutno kar se razen v izjemih okoliščiniah ne dela.

Pomoje je mislil isto kot jaz sam da je pač povedal bolj tehnično pravilno "neodvisna" jaz pa sem povedal laično "isto imenovana". Striktno gledano morda ni čisto enako ker v teoriji lahko nastaviš da lokalni branch tracka remote branch kljub različnem imenu, ampak spet to je scenarij ki se ga načeloma ne počne. Pa začetnikom pri git ponavadi sploh ne greš razlagat o local/remote trackanju branchov ampak jih raje naučiš da vedno povezujejo po imenih.

Git-a si se ti lotil iz napačne strani (spoznal si določene detajle gita še predno ti je git prišel v kri). Jaz sem šele po večmesečni uporabi git izvedel za hacke kot je tvoj primer, torej da je sploh možno pull komando zagnati na remote branch ki je drugače imenovan kot lokalni branch (nepovezan). Preveč znanja o git komandah predno git zastopiš škoduje. Zdaj ne vem zakaj ti je taka ideja sploh prišla na pamet, al si napačne vodiče bral al te je pa nek preveč advanced uporabnik učil ki ne zna začetnikom razlagat. Namreč res obstaja valid use case za take stvari počet, samo ne za vsakodnevno uporabo gita.

Skratka še enkrat, pull in push komandi uporabljaj brez argumentov in vse bo ok, tudi GUI Git orodja tako delujejo, vedno (za obično rabo) se najprej switcha na nek branch in potem šele dela pull/push/merge komande ki modificirajo trenutno switchani branch. Drži se tega tudi če si v command line.

A ni najbolj simpl takole:

git checkout branch_1
git pull

ko hočeš drugo vejo pa ponoviš vajo

git checkout branch_2
git pull


če preklapljaš samo med dvema vejama, lahko uporabiš "git checkout -" (ta preklaplja med zadnjima dvema)

Drugače se tega sranja najlažje rešiš, če imaš samo en branch, to je MAIN.

Vedno, ko kaj prčkaš na enem branchu, ga na koncu zmergaš v MAIN.

OP, vse branche dobis z

git pull

, med njimi se premikas z

git checkout

. Tukaj je nek caveat zakaj raje uporabiti

git fetch

namesto

git pull

, vendar so to v tem trenutku ze podrobnosti.

Vsekakot se ti splaca it skozi https://git-scm.com/book/en/v2

Seveda sem in ne vidim smisla zgoraj napisanega početja. Saj to ni SVN.

darkolord je 1. nov 2020 ob 11:54 izjavil:

Seveda sem in ne vidim smisla zgoraj napisanega početja. Saj to ni SVN.

Gre se preprosto zato, da je vzdrževanje različnih branchov časovno potratno. Ponavadi gre pa samo za lenobo programerjev, ki se jim ne da mergat sprememb v MAIN vejo.

Ko 1x določiš pravila, pač to ni problem. Začnejo tudi lepše programirati, tako da vsak nova koda ne zaserje vse ostale.

Par mojih bivših sodelavcev je dobilo nalogo v novih zaposlitvah, da vse veje združijo v eno samo.

Vse razulične opcije, ki jih imaš zaradi strank, se pa rešuje v build procesu.

Master je le master, kaki main... Če imaš dirty delo, ga lahko pred switchem tudi stash-aš.