» »

Git - pull in branchi

Git - pull in branchi

marjan_h ::

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.

Lonsarg ::

Če uporabljaš zgolj osnovne git komande se itak delajo 1na1 povezave med istoimenskimi branchi lokalno/remote ob pull/push komandah (če boš lokalno naredil branch kiremote ne obstaja in boš rekel pull bo javilo dare,ote tega brancha ni) torej kar želiš dela out of the box.

Take stvari se najlažje razume tako da se sproba.

Zgodovina sprememb…

  • spremenil: Lonsarg ()

marjan_h ::

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.

uniman ::

Do merge conflitov ti lahko pride ce hočeš brancha mergat. Pull/push se naceloma dela za dolocen branch neodvisno od ostalih.

Predlagam, da se malo spoznas z osnovami in preberes malo dokumentacije.
Za zacetek in lazjo predstavo mogoče bolje da uporabis kaksen UI za git, npr. sourcetree.

Invictus ::

Kot vedno, Google in RTFM...
"Life is hard; it's even harder when you're stupid."

http://goo.gl/2YuS2x

Lonsarg ::

@marjan_h, primere ki si jih dal so točno to, advanced komande s katerimi če ne znaš dobro lahko pride do problemov. 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. Začetnikom jaz priporočam UI git orodja ravno zato da se uporablja zgolj osnovne operacije. TortoiseGit je moja osebna preferenca (jaz grem v commande line zgolj ko delam advanced zadeve, ne pa za vsakdanje delo).

Skratka če že vztrajaš v command line potem striktno ko hočeš dobiti nov branch ki ga še nimaš:
- git checkout -b branch_2

In striktno ko delaš pull push vedno najprej checkouti na branch kjer to hočeš delat in nato preprosto brez argumentov da bo komanda vedno upoštevala povezave ki so se ustvarile ob prejšnih operacijah:
- git pull
- git push

Zgodovina sprememb…

  • spremenil: Lonsarg ()

marjan_h ::

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.

Greg91 ::

Načeloma marsikaj drži, hudič je v detajlih. To si že predelal?

Lonsarg ::

marjan_h je 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.

Zgodovina sprememb…

  • spremenil: Lonsarg ()

darkolord ::

Kar on pomoje išče je "git fetch", ki potegne dol vse spremembe, brez da naredi merge.

DamijanD ::

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)

mr_chai ::

git pull te mede zato, ker git pull v bistvu naredi dve stvari, najprej git fetch in git merge v current branch. Zato je boljš se izogibati uporabi git pull.

Če si recimo v branch A in bi rad samo potegnu dol iz origina branch B, nardiš samo: git fetch origin B, tako boš še vedno v branch A. Ampak če boš naredil: git branch, boš videl da imaš še branch B lokalno, tako da potem lahko narediš: git checkout B

Invictus ::

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.
"Life is hard; it's even harder when you're stupid."

http://goo.gl/2YuS2x

darkolord ::

Lolwat?

napsy ::

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
"If you die, you die. But when you live you live. There is no time to waste."

Invictus ::

darkolord je izjavil:

Lolwat?

Kaj what?

Se nisi delal v pravem razvoju, zgleda ;).
"Life is hard; it's even harder when you're stupid."

http://goo.gl/2YuS2x

darkolord ::

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

Zgodovina sprememb…

Lonsarg ::

@Invictus, predvsem si šel offtopic ker o branching flowu nismo tle govorili. Pa tudi ne glede na branching flow ki ga izbereš je moderni razvoj preko git tak da se v long-lived branche piše zgolj preko web vmesnika in in pull requestov (in potem na to vežeš devops proces), lokalno se pa dela zgolj v feature/hotfix branchih. Torej ne glede na branching flow (bodisi samo en master kar ratuje popularno zadnje čase, bodisi develop/master) se ne izogneš temu da lokalno spamaš branche ker je to the way to go, je pa dobra praksa jih brisat takoj ko je zadeva integrirana v nek stalni branch ja.

Zgodovina sprememb…

  • spremenil: Lonsarg ()

Invictus ::

darkolord je 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.
"Life is hard; it's even harder when you're stupid."

http://goo.gl/2YuS2x

Lonsarg ::

In kje v tej temi vidiš da smo govorili o tem da bi bil več kot en stalni branch? Točno nikjer. To o čemer ti govoriš je takoimenovani trunk-based development kjer je zgolj en stalni branch iz katerega se deploya in to je res sodobni best-practice (ki sicer NI 100% aplicable na vse sisteme oziroma zahteva rewrite določenih sistemov da bi bil možen). Ampak spet, mešaš dve različni zadevi ker nismo govorili o flowih ampak o lokalnem delu z git komandami ki so iste pa če imaš en stalni branch ali pa 10! Namreč v obeh primerih imaš na tone short-lived branchov, tudi v trunk-based development.

Zgodovina sprememb…

  • spremenil: Lonsarg ()

c3p0 ::

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


Vredno ogleda ...

TemaSporočilaOglediZadnje sporočilo
TemaSporočilaOglediZadnje sporočilo
»

GitHub Pomoč

Oddelek: Programska oprema
6902 (608) St753
»

GitHub Pomoč

Oddelek: Pomoč in nasveti
455195 (3457) BivšiUser2
»

git true merge

Oddelek: Programiranje
9902 (610) xordie
»

Git vaje

Oddelek: Programiranje
71159 (910) tomazic89
»

Facebook aplikacje - uploadanje na heroku

Oddelek: Programiranje
71000 (856) lambda

Več podobnih tem