W dniu sobota, 1 grudnia 2012 13:17:23 UTC-5 użytkownik Borneq napisał:
> U�ytkownik "Sebastian Bia�y" <h...@p...onet.pl> napisa� w wiadomo�ci
> news:k9dh35$3ak$1@node2.news.atman.pl...
> > TortoiseSVN to za�atwia dla svn. Ponadto pami�taj, �e wyb�r systemu
> > rozproszonego niekoniecznie ma zalety je�li pracujesz z repo lokalnie.
>
> Na pocz�tek chyba lokalnie.

W git ogolnie pracuje sie lokalnie. To pozwala na wiele rzeczy,
ktore w klient-serwer nie sa mozliwe. Mozna m.in. robic swoje
branche, potem je bezpiecznie usuwac, czesto nawet tak sie
robi i to na 5 minut lub dzien. Ma sie tez lokalnie historie.

Trduno powiedziec, zeby bylo jedno narzedzie w git - co nie znaczy, ze
nie startuje sie jednego a potem klika.

> >>, w tym by� mo�e praca na trzech plikach: oryginale, zmianie
> >> jednego u�ytkownika i zmianie drugiego.
> > Hmm a po co coďż˝ takiego?
>
> Kiedy� programy takie jak SourceSafe Microsoftu dzia�a�y w ten spos�b �e
gdy
> jedna osoba edytowa�a plik, by� on blokowany i niedost�pny do edycji dla
> innych. Teraz zdaje si� �e kilka os�b mo�e edytowa� ten sam plik i
powstaje
> konflikt. Pobieram repozytorium na dysk, edytuj� wiele plik�w. Potem chc�
> wrzuciďż˝ zmiany do repozytorium, ale ktoďż˝ juďż˝ je zmodyfikowaďż˝.

Yyy.. to moze nie od razu git, bo doznasz szoku cywilizacyjnego...

Nie ma nic zlego w zmienianiu tych samych plikow przez wiele osob. Wiekszy
problem powstaje wtedy, gdy jedna zmiana dotyczaca wielu plikow wymaga
szukania, ktore pliki sie zmienily. Wazna jest zmiana kodu, a nie
jeden plik.

Jak przypadkiem kilka zmian trafi gdzies w te same linie, wymaga to recznego
dostosowania, ja uzywam meld - taki interaktywny edytor roznic,
zintegrowany z git. Robiac merge dwoch duzych branchy czesto mam
z 10 konfliktow, zabiera to w sumie ze 2-5 minut. Oczywicie, konflikt
to nie zmiany tego samego pliku, ale zmiany, ktorych narzedzie nie
potrafi polaczyc w bezpieczny sposob razem, czyli musza trafic w te same
5-10 linii.

--
Edek