Dobrym przykładem osoby, która pasuje do tego opisu, może być kierownik projektu.

Pewnego dnia szef zapytał mnie: „Co to za Github i dlaczego jest to ważne?” Ma kilka własnych projektów, więc potrzebowałby prywatnego hostingu, a ja starałem się wyjaśnić ponad to, co zwykle: VCS sprawiają, że współpraca jest trywialna, zapewnia historię i „archiwizuje” wszystkie twoje dane oraz pozwala ci rejestrować zmiany atomowe w bazie kodu . W mojej głowie myślałem: „to prawie tak, jakbyś musiał użyć DRVS, aby naprawdę zrozumieć, jak to jest korzystne”.

Skończyło się na tym, że wskazałem mu BitBucket, ponieważ dają ci nieograniczone prywatne repozytoria (musiałem nawet wyjaśnić, co to jest repozytorium).

Czy ktoś ma naprawdę dobre konkretne przykłady tego, jak VCS uratował im tyłek lub ułatwił życie itp. - w zasadzie, jak sprzedałbyś DVSC komuś, kto nie jest obeznany z programowaniem, ale nie jest programistą z zawodu?

Kontrola wersji doskonale nadaje się do (co najmniej) trzech czterech rzeczy: tworzenia kopii zapasowych, udostępniania kodu między programistami, znajdowania + naprawiania błędów i śledzenia postępów.

1. Kopia zapasowa . Jeśli nic więcej, to zapasowe na sterydach. Masz całą historię programowania, każde zatwierdzenie jest migawką całego kodu z identyfikatorem (numerem wersji), opisem, datownikiem, informacjami o użytkowniku. I łatwo jest porównywać pliki między wersjami. Co więcej, jest szybszy niż zwykła kopia zapasowa (wysyłane i przechowywane są tylko zmiany plików) i zawiera znacznie bardziej przydatne metadane. Po co to wymyślać na nowo?

2. Udostępnianie kodu między programistami . Jeśli masz co najmniej dwóch programistów pracujących jednocześnie nad tym samym produktem, nie widzę innego sposobu, aby niezawodnie i konsekwentnie udostępniać zmiany kodu i scalać je. Wysyłasz zamki pocztą?

3. Znajdowanie i naprawianie błędów . Gdy Twoi klienci zgłaszają błąd dotyczący konkretnej wersji produktu, możesz szybko uzyskać rzeczywistą migawkę źródła w celu jej odtworzenia i naprawy. Trudno jest odtworzyć błędy, jeśli twoje źródło jest inne niż źródło klienta. Czy poprosisz ich o przesłanie pliku wykonywalnego, abyś mógł go zdemontować? Ponadto, jeśli masz problem ze zidentyfikowaniem przyczyny błędu, możesz użyć VCS, aby wskazać dokładną wersję, w której został wprowadzony.

4. Śledzenie postępów . Po zatwierdzeniu pracy w migawkach pozwala ona (i kierownikowi) śledzić postępy we wdrażaniu funkcji i status otwartych błędów. Systemy VC można również łatwo zintegrować z systemami śledzenia i systemami ciągłej integracji . Utrzymanie poziomu jakości dla czegoś innego niż projekt hobbystyczny jest prawie niemożliwe, chyba że masz VCS.

Gdy już wszyscy zgodzicie się, że nie powinno się nigdy tworzyć oprogramowania poza VCS (nie przegapiłbym tego nawet w przypadku projektu hobbystycznego), wtedy możecie omówić cechy (nieco bardziej skomplikowanego) DVCS (następna część rażąco skopiowana z Wikipedia ):

• Każdy użytkownik ma własną lokalną kopię repozytorium (i skutecznie kopię zapasową)
• Umożliwia użytkownikom wydajną pracę, nawet gdy nie jest podłączony do sieci
• Sprawia, że ​​większość operacji jest znacznie szybsza, ponieważ nie jest zaangażowana żadna sieć
• Umożliwia uczestnictwo w projektach bez konieczności uzyskania pozwolenia od władz projektu
• Umożliwia pracę prywatną, dzięki czemu użytkownicy mogą korzystać z systemu kontroli wersji nawet w przypadku wczesnych wersji roboczych , których nie chcą publikować
• Unika polegania na pojedynczej maszynie fizycznej jako pojedynczym punkcie awarii

„Czy kiedykolwiek przydał Ci się przycisk„ cofnij ”? Och, więc zgadzasz się, że powinniśmy użyć kontroli wersji?”

Kiedy zacząłem używać kontroli wersji, główną funkcją, która mnie interesowała, była możliwość „cofnięcia” moich błędów i powrotu do poprzedniej wersji. Każdy może docenić przycisk cofania. Udzielona kontrola wersji może znacznie więcej.

Zacznij od podstaw:

Po pierwsze, VCS chroni programistów przed sobą i przed sobą nawzajem - jeśli nie miałoby to innego celu niż umożliwienie dwóm lub więcej programistom względnie bezpiecznej pracy na tej samej bazie kodu, miałoby to ogromną wartość (i byłem w zespole, w którym poprzedni dni pracy zostały nadpisane przez trochę nieostrożnego kopiowania).

Po drugie, zapewnia ścieżkę audytu - historię - możesz cofnąć się i zobaczyć, kto zmienił co i kiedy, i możesz cofnąć się i odzyskać usunięty kod, ponieważ nie był już potrzebny lub odpowiedni, kiedy okaże się, że będzie potrzebny po wszystko.

Po trzecie, daje ci punkt odniesienia - ostatecznym źródłem jest zatwierdzony kod (w świecie rzeczywistym jest nieco bardziej skomplikowany, szczególnie z DVCS, ale ze względu na tę dyskusję jest wystarczająco blisko). Jeśli masz kopię zapasową repozytorium, powinieneś chronić aktywa firmy.

Te trzy rzeczy powinny być „wystarczające” do sprzedaży VCS - jeśli menedżer nie widzi wystarczającej wartości w swoim czasie, aby znaleźć innego menedżera.

Gdy już sprzedałeś VCS (które są ostatecznie przydatne tylko dla zespołów programistycznych, w których liczba deweloperów jest większa od zera), to pytanie, dlaczego DVCS przekroczy, powiedzmy, SVN lub TFS i dalsze pytanie, czy pracować w domu lub w celu korzystania z usług hostowanych, takich jak Kiln, Bitbucket lub Github (który działa prywatnie, jeśli płacisz) jest raczej głębszy i bardziej zależny od kontekstu.

VCS

Po prostu wyjaśnij pojęcie kopii zapasowych . Kopie zapasowe pozwalają zobaczyć, nad czym pracowałeś w danym momencie. Powiedz, jak wcześniej programiści VCS kopiowali całe swoje projekty kompulsywnie, generalnie, aby zapisać każde dobre i stabilne wydanie, które mieli, więc kiedy coś poszło nie tak, mieli dobry punkt odniesienia, kiedy wszystko działało, porównaj je z najnowszymi rzeczami i zobacz, gdzie oni lub ktoś inny pomieszali i naprawili to łatwiej , patrząc na różnice zamiast na całe dwie kopie zapasowe projektu.

Podsumowując : VCS pozwalają zapisywać kopie zapasowe swojej pracy i umożliwiają dostrzeżenie tylko różnic między kopiami zapasowymi.

DVCS

Jeśli chodzi o rozproszoną kontrolę wersji, wyjaśnij, w jaki sposób typowa kontrola wersji potrzebowała serwera i połączenia internetowego, i że wszyscy się tym zmęczyli, ponieważ była wolniejsza i wszyscy pracowali nad jedną kopią zapasową, jeśli ktoś ją pomieszał, pomieszał projekt dla wszystkich, więc dzięki rozproszonej kontroli wersji każdy może pracować nad własną kopią zapasową na swoim komputerze bez połączenia z Internetem, i wszyscy są zadowoleni, ponieważ nikt nie zadziera z kopią zapasową podczas pracy i może martwić się o udostępnienie swojej pracy później, gdy skończy.

Kolejną dobrą jest to, że w przeciwieństwie do scentralizowanego VCS, w którym jest tylko jedna kopia zapasowa, jeśli komputer z kopią zapasową zapali się, będą jeszcze inne kompletne kopie zapasowe do obejrzenia (co najmniej jedna dla każdego programisty).

Podsumowując : DVCS umożliwiają pracę we własnej kopii zapasowej, bez konieczności wtrącania się wszystkich osób w jeden serwer, i martwienie się o inne zmiany po zakończeniu pracy. Ponadto nic się nie dzieje, jeśli główna maszyna repozytorium się zapali .

Pracuję głównie z inżynierami (nie programistami per se, ale oni piszą kod)

Kiedy wyjaśniam im o kontroli wersji, najważniejszą kwestią jest możliwość cofnięcia kodu / dokumentacji / zarządzania czymkolwiek i uproszczenia współpracy z innymi programistami / pisarzami itp.

To dobry punkt sprzedaży - i to był główny powód, dla którego użyłem VCS do całej mojej pracy, a także innych zalet: posiadania historii, repozytorium, które można łatwo wykonać kopię zapasową ...

Większość z nich podoba się pomysłowi i uważa go za bardzo przydatny, dostosowując go do swoich projektów (szczególnie jeśli wymagają współpracy z innymi inżynierami).

Próbując przekonać kogokolwiek o czymkolwiek, zawsze musisz spróbować podejść do tego z ich punktu widzenia.

Twój kierownik projektu ma prosty cel - realizacja projektów na czas i zgodnie z budżetem.

Jeśli obecnie nie używasz kontroli wersji, zespół programistów rozwiązuje problemy, które kontrola wersji rozwiązuje ręcznie. Wszystkie te problemy zostały dobrze wyliczone przez inne odpowiedzi, więc nie będę się tutaj zajmował.

Musisz wyjaśnić swojemu kierownikowi projektu, że zespół spędza Xkilka godzin tygodniowo na ręcznym rozwiązywaniu problemów, które GIT może rozwiązać automatycznie lub, powiedzmy, w 0.1 * Xliczbie godzin programistów.

Nie podchodź do niego z powodów, dla których GIT ułatwi ci życie lub życie innych programistów, podejdź do niego z perspektywy, że GIT będzie dostarczać oprogramowanie szybciej i taniej.

Podoba mi się opis @ Buttons840 jako przycisku cofania bazy kodu. Pomocne może być także porównanie go z (mniej frustrującą) wersją programu Word lub funkcją „Śledź zmiany” programu InDesign. Z mojego doświadczenia wynika, że ​​zdecydowanie zmniejsza to potrzebę przechodzenia przez jedną osobę dookoła i mówienia innym, aby nie dotykać plików X, Y i Z przez kilka następnych godzin, co jest przydatne do robienia rzeczy.

Odkryłem również, że szczegółowe informacje o wersji są niezwykle przydatne do naprawiania / usuwania błędów. Przechowuję numer wersji SVN (za pomocą właściwości $ Id) w prawie każdym generowanym pliku danych. W ten sposób, jeśli (kiedy?) Zostanie znaleziony błąd, identyfikacja plików z potencjalnymi problemami i ich ponowne wygenerowanie lub wygenerowanie przez inny kod błędu jest trywialne.

Jeśli nie korzystasz z kontroli wersji, skąd wiesz, jak odbudować środowisko produkcyjne?

1 Różne osoby (testerzy, programiści) będą szukać tych samych informacji w różnych miejscach

co prowadzi do DUPLIKACJI DANYCH, które nie są synchronizowane.
Kontrola wersji to najprostszy sposób na wyeliminowanie zduplikowanych danych.

2 Jeśli korzystasz z kontroli wersji, łatwo jest upewnić się, że środowisko produkcyjne odpowiada temu, co jest w kontroli wersji.

Ułatwia to wykrycie, czy przyczyną problemu była zła kompilacja (prod nie odpowiada kontroli wersji), czy błąd projektowy lub kodowy (prod odpowiada kontroli wersji).

Kontrola wersji ułatwia przypisanie numeru wersji do każdego środowiska testowego i naturalnie można oczekiwać, że produkcja będzie miała niższy numer wersji niż test lub programowanie, a test będzie miał niższy numer wersji niż programista. Jeśli tak nie jest, część kodu nie została poprawnie przetestowana.

Również w przypadku wydania oprogramowania istotna jest następująca funkcja VCS: Załóżmy, że klient znalazł błąd. Obecny rozwój oprogramowania jest prawdopodobnie w zupełnie innym stanie niż wersja, którą posiada klient. Być może błąd został już naprawiony, a może nie, ale w każdym razie obecne oprogramowanie nie jest w stanie, w którym można go po prostu wysłać do klienta.

VCS sprawia, że ​​powrót do wersji dostarczonej klientowi jest prosty, napraw błąd, o który prosił, zbuduj go i wyślij mu poprawioną wersję. Wszystko to bez zakłócania obecnego rozwoju, bez konieczności wysyłania mu wersji z niedokończonymi / niestabilnymi funkcjami lub dodatkowymi błędami wprowadzonymi z powodu nowego niedokończonego rozwoju.

Ponadto VCS ułatwia przeniesienie tej poprawki z powrotem do nowej gałęzi programistycznej, jeśli błąd nadal tam jest obecny.

Dzięki silnej dyscyplinie możesz prawdopodobnie poradzić sobie z tym bez VCS dla bardzo małego zespołu, ale użycie jednego pozwoli ci zaoszczędzić czas i pieniądze. Najprawdopodobniej pomoże to również utrzymać klientów.

Jeśli Twoja firma ma więcej niż dwie osoby, prawdopodobnie masz dokument słowny lub dokument programu Excel, który jest edytowany przez wiele osób. Czasami osoby te wykonują lokalne kopie, aby zabrać je w podróż służbową itp. Lub dokument jest wysyłany pocztą elektroniczną po każdej zmianie.

Jeśli masz taki plik, to modyfikacje niektórych osób zostały utracone w przeszłości lub zostaną utracone w przyszłości. Lub ludzie myślą, że stracili zmiany, ale nie mogą tego udowodnić. Lub chcieliby zobaczyć, kto dokonał zmiany, kiedy i dlaczego. Właśnie taki problem rozwiązuje VCS.

Wybierając oprogramowanie / biblioteki open source, posiadanie repozytorium DVCS jest zdecydowanie zaletą w kryteriach wyboru.

1) Możemy sklonować całe repozytorium, nie musimy martwić się o projekt lub jego strona internetowa jest martwa.

2) Ludzie chętniej zgłaszają naprawę błędów poprzez żądanie ściągnięcia, co powoduje szybsze naprawianie błędów w pilnych problemach.