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