git

Václav Ovsík vaclav.ovsik na gmail.com
Středa Leden 7 10:11:12 CET 2015


On Wed, Jan 07, 2015 at 09:52:40AM +0100, David Belohrad wrote:
> Souhlasim s Vaclavem :)
> 
> dokud nesahnete na git push/git pull (fetch a jeste par dalsich),
> vsechny zmeny jsou lokalni.
> 
> Ja osobne bych Vas pripad resil tim, ze bych mel master branch, ktera je
> synchronizovana se serverem. Vytvoril bych si z master jinou _lokalni_
> branch (git checkout -b <nova>), na tuto novou vetev bych pak aplikoval
> sadu Vasich patchu.
> 
> Pak bych pracoval v teto vetvi. git pull by potom synchronizoval Vasi
> master vetev s vetvi na serveru. Tim, ze s masterem nikdy nepracujete,
> nedoslo by nikdy k zadnym konfliktum pri pull operaci.
>

ja si myslim, ze ani neni nutne si vytvaret dalsi kopii pouze pro cteni,
protoze to jiz udelal GIT sam. O aktualizaci kopie vzdaleneho branche se
postara prikaz
    git fetch
a na nej se lze odkazovat jako na origin.
Muj remote tracking branch po git clone je proste master. Mam-li tedy
"vycheckoutovany" branch master, tak se mohu podivat na rozdil proti
vzdalenemu masteru napriklad proste takto:
    git diff origin


Ale samozrejme lze to pojmout i tak, ze se tvarim, ze master (remote
tracking branch je read-only) a aktualizuji ho bez problemu pomoci git
pull (zadne konflikty nebudou). A hraju si pak na jinych branchich.

Podstatne je, ze branche jsou jenom odkazy na commity a neni treba
s nimy setrit. Proto pokud si nejste jist pred nejakou operaci co to
udela, klidne si udelejte novou branch a zkuste to napred nad tim.

> 
> Pak, kdyz prikazem git pull syncnete ty dva mastery, prepnete se do vasi
> vyvojove vetve a prikazem git merge master proste updatnete Vasi vetev
> se vsemi opruzy z toho vyplyvajicimi :)

jj, nebo ten rebase. Rebase by se dalo prirovnat k utrhnuti vetve
a naroubovani o kousek dal.

-- 
Zito


Další informace o konferenci Hw-list