Byłem tam, gdzie teraz jesteście, sceptycznie nastawiony do wykorzystania rozproszonej kontroli wersji. Przeczytałem wszystkie artykuły i znałem teoretyczne argumenty, ale nie byłem przekonany.

Aż pewnego dnia wpisałem git init i nagle znalazłem się w repozytorium git.

Jestem programistą Mercurial i pracowałem jako konsultant Mercurial. Więc uważam Twoje pytania za bardzo interesujące i mam nadzieję, że na nie odpowiem:

• Jaka jest zaleta lub wartość zaangażowania lokalnie? [...]

Masz rację, że IDE mogą śledzić lokalne zmiany poza prostym cofaniem/ponawianiem w dzisiejszych czasach. Jednak nadal istnieje luka w funkcjonalności między tymi migawkami plików a pełnym systemem kontroli wersji.

Lokalne commity dają masz możliwość przygotowania swojej" historii " lokalnie przed przesłaniem jej do recenzji. Często pracuję nad zmianami obejmującymi 2-5 commitów. Po dokonaniu commit 4, mogę wrócić i nieco zmienić commit 2 (Być może zobaczyłem błąd w commit 2 po dokonaniu commit 4). W ten sposób będę pracował nie tylko nad najnowszym kodem, ale nad kilkoma ostatnimi commitami. Jest to trywialnie możliwe, gdy wszystko jest lokalne, ale staje się trudniejsze, jeśli potrzebujesz synchronizacji z centralnym serwerem.

Co jeśli rozwalę dysk twardy? [...] więc jak to jest fajne w porównaniu do meldowania się w centralnym repo?

Wcale nie fajne! :-)

Jednak, nawet w przypadku centralnego repo, nadal musisz martwić się o niezarejestrowane dane W kopii roboczej. W związku z tym twierdzę, że i tak powinieneś mieć rozwiązanie zapasowe.

Z mojego doświadczenia wynika, że ludzie często mają większe porcje niezarejestrowanych danych w swoich kopiach roboczych z scentralizowany system. Klienci powiedzieli mi, jak starali się przekonać deweloperów do zaangażowania co najmniej raz w tygodniu.

Zmiany są często pozostawiane niezatwierdzone, ponieważ:

1. Nie są jeszcze skończone. W kodzie mogą być instrukcje debug print, mogą być niekompletne funkcje itp.

2. Popełnienie trafiłoby do trunk i to jest niebezpieczne z scentralizowanym systemem, ponieważ wpływa na wszystkich else.

3. Zatwierdzenie wymagałoby najpierw połączenia z centralnym repozytorium. To scalanie może być onieśmielające, jeśli wiesz, że w kodzie zaszły inne sprzeczne zmiany. Scalanie może być po prostu irytujące, ponieważ może nie być wszystko zrobione ze zmianami i wolisz pracować ze znanego-dobrego stanu.

4. Zatwierdzanie może być powolne, gdy trzeba rozmawiać z przeciążonym serwerem centralnym. Jeśli znajdujesz się w lokalizacji offshore, są jeszcze wolniejsze.

Jesteś absolutną poprawnością jeśli uważasz, że powyższe nie jest tak naprawdę kwestią scentralizowanej kontroli wersji kontra dystrybuowanej. Z CVCS, ludzie mogą pracować w oddzielnych oddziałach, a tym samym trywialnie uniknąć 2 i 3 powyżej. Z oddzielną gałęzią throw-away, mogę również commit tyle, ile chcę, ponieważ mogę utworzyć inną gałąź, w której zatwierdzam bardziej dopracowane zmiany(rozwiązując 1). Commity mogą być jednak powolne, więc 4 może być nadal stosowane.

Ludzie osoby korzystające z DVC często i tak wysyłają swoje" lokalne " commity do zdalnego serwera jako rozwiązanie do tworzenia kopii zapasowych. Nie pcha się do głównego serwera, na którym pracuje reszta zespołu, ale do innego (ewentualnie prywatnego) serwera. W ten sposób mogą pracować w izolacji i nadal przechowywać kopie zapasowe poza siedzibą.

Praca w trybie offline lub w samolocie. [...]

DVCS jest dla mnie bardzo interesujący:

• Dodaje zupełnie nowy wymiar do kontroli źródła proces: publication .
  Nie tylko masz merge workflow , ale także publication workflow (do którego repozytorium będziesz naciskał/wyciągał), a to może mieć wiele implikacji w term:

  • cykl rozwoju (z repozytoriami tworzonymi tylko dla określonego typu commitów, jak ten, który ma być wydany do profuctions, do celów rozmieszczenia)
  • zadania solo (można wypchnąć i zaktualizować kopię zapasową repo, nawet w formie tylko jednego pliku)
  • inter-dependencies project (kiedy zespół projektu a czeka, aż Team porject B W końcu powierzy się centralnemu repo, może poprosić B, aby "przekazał" pośredni rozwój jako załączony plik zip w mailu. Teraz wystarczy, że A doda B repo jako potencjalnego pilota, pobierze go i rzuci okiem)

• Przynosi nową drogę z produkcja / konsumowanie poprawek z:

  • a pasywny sposób tworzenia nowych wersji (tylko te, które aktywnie pobierają z twojego repo, zobaczą je w swoich gałęziach)
  • aktywny sposób spożywania zmian od innych (poprzez dodanie ich repo jako zdalnego i pobieranie/łączenie tego, czego od nich potrzebujesz).

Oznacza to, że nie polegasz na innych dostarczających swoją pracę do centralnego repo, ale możesz mieć bardziej bezpośrednie relacje z różnymi aktorami i ich repo.

Twój główny argument o IDE robi śledzenie dla Ciebie jest fałszywy. Większość IDE w rzeczywistości nie ma żadnej takiej funkcjonalności poza nieograniczonymi poziomami cofania. Pomyśl o gałęziach, połączeniach, rewertach, komunikatach commit (log) i tym podobnych, a założę się, że nawet IDE, do którego się odnosiłeś, nie jest wystarczające. Szczególnie wątpię, by śledziło to twoje commity-prawdopodobnie na kilku różnych gałęziach, nad którymi pracujesz-i właściwie wpychało je do repozytorium po uruchomieniu.

Jeśli Twoje IDE właściwie robi to wszystko, w rzeczywistości nazwałbym to rozproszonym systemem kontroli wersji sam w sobie.

Wreszcie, jeśli centralne repozytorium umrze z jakiegokolwiek powodu (Twój usługodawca zbankrutował, był pożar, haker go uszkodził,...), masz pełną kopię zapasową na każdym komputerze, który niedawno wyciągnął repozytorium.

EDIT: możesz używać DVCS tak jak scentralizowane repozytorium, a ja nawet polecam to zrobić przynajmniej dla małych i średnich projektów. Mając jedno centralne "autorytatywne" repozytorium, które jest zawsze online, upraszcza wiele rzeczy. A gdy ta maszyna ulegnie awarii, możesz tymczasowo przełączyć się na jedną z innych maszyn, dopóki serwer nie zostanie naprawiony.

Jeśli nie widzisz wartości lokalnej historii lub lokalnych budów, to nie jestem pewien, czy jakakolwiek ilość odpowiedzi na pytanie zmieni Twoje zdanie.

Cechy historii IDE są ograniczone i niezdarne. W niczym nie przypominają pełnej funkcji.

Dobrym przykładem tego, jak te rzeczy są używane w różnych projektach Apache. Mogę zsynchronizować repo git z repo Apache svn. Potem mogę pracować przez tydzień w prywatnym oddziale. Mogę obniżyć zmiany z repo. Mogę zgłaszać moje zmiany, detaliczne lub hurtowe. A kiedy skończę, mogę je spakować jako jeden commit.

Ciekawe pytanie.

Nie jestem doświadczonym użytkownikiem DVCS, ale moja ograniczona ekspozycja była bardzo pozytywna.

Uwielbiam możliwość dwuetapowego commit. Pasuje mi.

Niektóre zalety, które przychodzą na myśl:

1. Lepiej połączyć wsparcie. Branch-Merge jest bardziej jak obywatel pierwszej klasy w DVCS, podczas gdy w moim doświadczeniu scentralizowanych rozwiązań, uznałem to za bolesne i podstępne. Śledzenie scalania jest teraz dostępne w svn, ale nadal jest powolne i uciążliwe.

2. Duże zespoły. DVCS jest nie tylko dla commitów dla pojedynczego użytkownika. Możesz wypychać i ciągnąć zmiany między zespołami, zanim wrócisz do głównego repozytorium (lub nie). Jest to bezcenne dla niektórych smaków współpracy.

3. Pracując nad funkcjonalnością eksperymentalną, warto często się angażować, ale tylko na krótką metę. Nie chcę zawsze rozgałęziać głównej bazy kodowej, więc miło jest móc odtwarzać i ponownie nagrywać. / Align = "left" / jest przydatny podczas pracy z ciągłą integracją. Jeśli całymi dniami pracuję nad refaktoryzacją, mogę przerwać Kompilacje na niedopuszczalne ramy czasowe, ale nadal chcę śledzić moje zmiany.

Zauważ, że moje doświadczenie z DVCS jest bardziej z Mercurial niż z Git. Korzystając z CVS / SVN, odkryłem, że krzywa uczenia się jest znacznie łatwiejsza dzięki Mercurial (Hg). Niedawno dodana obsługa kodu Google dla Mercurial jest również dobrodziejstwem. ... Posunę się nawet do stwierdzenia, że mój początkowa odpowiedź na Gita była negatywna, ale bardziej z punktu widzenia użyteczności niż cokolwiek wspólnego z DVC

Warto zauważyć, że Subversion prawdopodobnie będzie pobierał w przyszłości takie rzeczy jak commity offline. Oczywiście nie możemy naprawdę porównać tych funkcji do tego, co jest obecnie dostępne, ale może to być bardzo dobry sposób na "korzystanie z DVC w sposób scentralizowany", jak opisano w innych odpowiedziach tutaj.

Kolejny Ostatni post stwierdza, że Subversion nie próbuje stać się DVCS

Te rzeczy prawdopodobnie będą oznaczać, że repozytorium jest nadal scentralizowane, oznacza to, że nie możesz rozłączać rozgałęzień, różnicować starych wersji, ale możesz ustawić commity w kolejce.

nic tu nie sprzedam.

* Jaka jest zaleta lub wartość zaangażowania lokalnie? Co? naprawdę? Wszystkie nowoczesne IDE pozwalają na śledzenie zmian? i jeśli wymagane możesz przywrócić określoną zmianę. Mają też funkcja oznaczania zmian / wersji na poziomie IDE!?

Jedyną prawdziwą zaletą jest to, że nie musisz potrzebować łączności z głównym centralnym repozytorium. Ktoś może powiedzieć, że korzyścią Git jest fakt że programista może popełnić lokalnie, przygotowując świetną kombinację łatek, a następnie ciągnąć je do Błogosławionego centralnego repo, ale IMO to jest dość nieciekawe. Programista może użyć prywatnej półki lub gałęzi w repozytorium Subversion do pracy nad swoim zadaniem, a następnie połączyć je z linią główną (np. / trunk) lub inną gałęzią.

Dla mnie głównym minusem jest to, że muszę pobrać i przechowywać całe repozytorium Git na moim komputerze. Dzięki dużemu projektowi z historią looong staje się ból i zajmuje zbyt dużo miejsca.

Kolejną wadą scentralizowania jest to, że Git technicznie nie może śledzić zmian nazw ani operacji kopiowania. Po prostu próbuje odgadnąć, czy plik został przemianowany, czy skopiowany na podstawie zawartości pliku . Prowadzi to do takich śmiesznych przypadków: svn do git migration przechowywanie historii skopiowanego pliku (gość pyta, dlaczego historia pliku została utracona po SVN>GIT migration, ).

• co jeśli rozwalę dysk twardy? gdzie się podziało moje lokalne repozytorium? (so jak to jest fajne w porównaniu do meldowania się w centralnym repo?)

W przypadku Gita, jeśli uszkodziłeś swoje lokalne urządzenie pamięci masowej (HDD, SSD, cokolwiek) i miało zmiany, które nie zostały wyciągnięte lub wypchnięte do Błogosławionego repo Gita, to masz pecha. Właśnie straciłeś swój czas i swój kod. Oprócz tego, awaria dysku twardego z lokalnym Git repo może zatrzymać proces rozwoju na jakiś czas: Linus Torvald ' S SSD breaks, zatrzymuje jądro Linuksa rozwój .

Dzięki scentralizowanej kontroli źródeł, takiej jak SVN, możesz stracić swój ostatni commit tylko dlatego, że cała Twoja praca została już przekazana do centralnego repozytorium do gałęzi, prywatnej półki lub nawet bagażnika. Oczywiście należy upewnić się, że odzyskiwanie po awarii i tworzenie kopii zapasowych zostało wdrożone dla centralnego repo.

• ok Linus Torvalds oddaje życie Gitowi i nienawidzi wszystkiego innego. Czy to wystarczy, by ślepo śpiewać pochwały? Linus mieszka w innym świat w porównaniu do deweloperów offshore w moim projekcie średniej wielkości?

Dla takiego projektu jak jądro Linuksa, które używało Bitkeepera w przeszłości, Git jest najlepszym systemem kontroli źródeł! Ale powiedziałbym, że Git nie pasuje do wszystkich.

Wybieraj mądrze!

Najprawdopodobniej nikt ci tu niczego nie sprzeda. Jeśli potrzebujesz funkcji Gita, po prostu git init. Jeśli to nie pasuje do ciebie, po prostu nie.

Jeśli nie znasz jeszcze funkcji Gita, wpisz git vs (zwróć uwagę na spację końcową) w wyszukiwarce Google i zobacz wyniki autouzupełniania.

Wolałem Notatnik niż IDE, dopóki nie potrzebowałem funkcji Netbeans. Wygląda na to, że to ta sama sprawa.

Jak wiecie, było wiele udanych projektów bez VC w ogóle.

PS. Sprzedaż Gita narusza jego licencję! ;)