Jaki jest najbardziej efektywny / wydajny sposób na opracowanie aplikacji dla wielu osób bez kontroli źródła?

Wprowadzenie do mojej sytuacji

Pracuję dla małej firmy zajmującej się programowaniem stron internetowych. Mamy zespół czterech programistów ASP.NET, w tym mnie. Prawie wszystkie nasze projekty (> 98%) to projekty jednoosobowe, których realizacja zajmuje około 1-4 tygodni. Nie używamy kontroli źródła ani wersji. Jedyne, co mamy, to folder współdzielony na serwerze lokalnym, który zawiera najnowsze źródło (== źródło aplikacji na żywo) wszystkich projektów.

W rzadkich przypadkach, gdy musimy pracować nad tym samym projektem z więcej niż jedną osobą, używamy ... Beyond Compare. Raz lub dwa razy dziennie programiści pytają się nawzajem, czy mają wersję, która się kompiluje, a następnie synchronizują kod za pomocą Beyond Compare. Gdy tylko dwie osoby pracują nad projektem, działa to „raczej dobrze”, ale gdy tylko trzeci programista wejdzie w ten proces, staje się niemożliwym do opanowania śmieciem. Zwłaszcza, gdy wszyscy zaczynają wprowadzać zmiany w bazie danych.

Ja (i jeden lub dwóch moich kolegów programistów) już kilkakrotnie powiedziałem szefowi, że powinniśmy zacząć korzystać z jakiejś formy kontroli źródła i wersji, takiej jak Git, Mercurial lub TFS (nasz szef jest bardzo nastawiony na Microsoft). Niestety mój szef nie widzi korzyści z przejścia na system kontroli wersji i źródła, ponieważ w jego oczach wszystko działa teraz dobrze i nie chce inwestować czasu i pieniędzy w tworzenie nowego systemu i upewnianie się, że wszyscy umie z niego korzystać. Nawet po tym, jak wyjaśniłem mu zalety (takie jak uproszczona współpraca, różne wersje aplikacji, bezpieczniejszy sposób zmiany kodu, ...), nadal nie uważa, że ​​jest to coś, czego potrzebujemy.

Z czterech programistów tylko dwóch (w tym ja) ma doświadczenie w kontroli źródeł (Git). I to doświadczenie jest bardzo ograniczone. Wiem, jak sklonować repozytorium Github na moim komputerze, wprowadzić pewne zmiany, zatwierdzić je i odesłać z powrotem do Github. Otóż ​​to.

Wyjaśnienie mojego problemu / troski

Za kilka tygodni zaczniemy pracować nad dość dużym projektem zgodnym z naszymi standardami. Jego ukończenie zajmie prawdopodobnie 2-3 programistów. Będę kierownikiem projektu (kierownik projektu i główny programista) i będę odpowiedzialny za wszystko. Miałem wiele problemów z podejściem Beyond Compare i nie chcę iść tą drogą z tym wielkim projektem, który będzie moim obowiązkiem.

Ponieważ wątpię, że będziemy w stanie

• załóż własny serwer Git,
• naucz wszystkich pracować z Git i
• z powodzeniem zatrudnij Gita w tym dużym projekcie,

Interesuje mnie, czy ktoś z was zna dobre sposoby na umożliwienie wielu osobom współpracy nad tym samym projektem bez korzystania z kontroli źródła lub wersji.

Aktualizacja

Chciałbym podziękować wszystkim za ich odpowiedzi i komentarze. Oto plan:

1. Spotkaj się z programistami, aby upewnić się, że wszyscy pracownicy techniczni czują to samo, jeśli chodzi o wdrażanie kontroli źródła. Zrobimy silniejszy punkt, gdy wszyscy za tym stoją.
2. Przedstaw pomysł szefowi i powiedz mu, że naprawdę potrzebujemy kontroli źródła.
3. Zaimplementuj go jak najszybciej.

Poświęć dzień na zainstalowanie kontroli wersji i naucz wszystkich w projekcie, jak z niej korzystać. To nie jest takie trudne. Osobiście nie korzystałem z Git, ale skonfigurowałem i użyłem innych systemów kontroli wersji i nie są one trudne do uruchomienia. Upewnij się, że wybierasz taki, który integruje się ze środowiskiem programistycznym. Dzięki temu korzystanie z niego będzie praktycznie bezproblemowe.

To nie będzie stracony czas.

Czas, który stracisz, gdy ktoś zastąpi lub usunie jakiś kod, będzie cię kosztować znacznie więcej.

Jeśli nie masz kontroli wersji, spędzisz także nadmiernie dużo czasu na tworzeniu kopii zapasowej projektu i martwieniu się o to, którą wersję każdy ma i którą wersję ma na serwerze itp.

Jeśli musisz przekonać swojego szefa, oszacuj czas, jaki zajmie ci skonfigurowanie i monitorowanie dowolnego rozwiązania kontroli wersji i dodaj koszty przepisywania kilku dni straconej pracy. Nie zapomnij dodać kosztów ręcznego scalania edycji od 3 programistów pracujących nad tym samym plikiem źródłowym oraz dodatkowych kosztów spowodowanych błędnym połączeniem. Dobra kontrola wersji daje to za darmo

Następnie porównaj to z kosztem uzyskania kontroli wersji - zero (jeśli korzystasz z oprogramowania typu open source) i skonfigurowania - 3 osobodni.

Nie zapominaj, że błąd później w projekcie będzie kosztował więcej niż jeden na początku. Jeśli musisz przerobić cały projekt z powodu błędu, który każdy może popełnić, będzie to kosztować znacznie więcej niż tylko przepisywanie czasu, może to kosztować twojego szefa reputację jego firmy.

Jeśli udostępnisz źródło w folderze, możesz również udostępnić tam repozytorium. Szef nie będzie o tym wiedział, poza tym, że jest tam folder .git.

Nigdy nie powinieneś prosić o pozwolenie na prawidłowe wykonywanie swojej pracy - Seth Godin.

Skonfiguruj kontrolę źródła, naucz się go używać i nie mów szefowi. Zwykle nie opowiadam się za nieposłuszeństwem wobec zarządzania, ale w tym przypadku twój szef jest głupi. Jeśli naprawdę uważasz, że git zajmie zbyt dużo czasu na naukę, zacznij od bardziej uproszczonego systemu kontroli wersji, takiego jak svn - nie robi to wszystkich fajnych rzeczy, które robi git, ale jeszcze łatwiej jest uzyskać podstawową wiedzę.

Nie czekaj, aż znajdziesz się w środku i poważnie masz kłopoty, zanim coś wdrożysz. Po prostu zrób to i wykonaj pracę.

Zredagowano, aby dodać: To, co naprawdę zadajesz pytanie, brzmi „w jaki sposób mam kontrolować źródła bez korzystania z systemu kontroli źródła”. Rozpoznałeś potrzebę i myślę, że wszyscy tutaj mówią ci to samo: nie ma rozsądnego sposobu na kontrolę źródła bez systemu kontroli źródła.

Mam tylko twoje podsumowanie, ale z tego wynika, że ​​twój szef kłóci się o czas i pieniądze, a ty wysuwasz argument techniczny o wyższości. Musisz kłócić się o czas i pieniądze. Naucz się gitowego sposobu robienia rzeczy i śledź czas, który mógłby zaoszczędzić, a następnie przedstaw swojemu szefowi dziennik z wpisami takimi jak „28.03.2011 musiał czekać 30 minut, aż Joe wróci do kompilacji podlegającej kompilacji więc moglibyśmy wykonać scalenie, polecenie scalenia git w stosunku do jego ostatniego zatwierdzenia byłoby około 5 sekund "z ładną sumą u dołu.

Jeśli szkolenie i konfiguracja serwera są przeszkodami biznesowymi, istnieje nieskończona liczba sposobów skonfigurowania przepływu pracy git, w tym fakt, że tylko jeden członek zespołu faktycznie korzysta z git, z folderami współdzielonymi dla „serwera”.

Poinstruuj swoich współpracowników, aby skopiowali swój kod do danego folderu udostępnionego, gdy jest to dobry moment na udostępnienie. Możesz przechowywać repozytorium dla każdego z nich i samodzielnie wykonywać wszystkie czynności związane z kontrolą źródła, a także powoli przekazywać na nich coraz więcej obowiązków związanych z kontrolą źródła, gdy tylko zyskasz pewność siebie, aby je przeszkolić. To daleko od idealnego sposobu na zrobienie tego, ale w porównaniu do tego, co masz teraz, nawet to pozwoli ci zaoszczędzić czas na łączeniach. Łatwiej jest przekonać swojego szefa dzięki mniejszej krzywej uczenia się zespołu, a uzyskasz wszystkie korzyści związane z wycofaniem wersji i wersjonowaniem.

Nie wykonuję dużo pracy z bazami danych, ale według mojej wiedzy scalanie zmian schematu bazy danych nie jest dobrze obsługiwane przez kontrolę źródła. Jeśli te połączenia są trudne, możesz rozważyć zmianę procesu, w której wszystkie zmiany w bazie danych przechodzą przez jednego strażnika.

To jest szalone. Powinieneś używać VCS, nawet jeśli pracujesz sam. Nie należy używać VCS w firmie. Po prostu to zrób. Teraz! Naprawdę ... Nie potrzebujesz zaawansowanych rzeczy od samego początku. GitHub i GitLab są bardzo proste w użyciu, ale jestem pewien, że możesz znaleźć więcej usług hostingowych kompatybilnych z Windows, jeśli twój szef nalega (nawet jeśli nie jest trudno skonfigurować i używać Git w systemie Windows).

Myśl, o którą pytasz, jest niemożliwa . Jeśli wiele osób pracuje nad tym samym projektem bez korzystania z kontroli źródła, szybko będziesz mieć wiele problemów, a ponieważ będziesz głównym programistą, będziesz musiał sobie z nimi poradzić.

Z mojego osobistego doświadczenia praca nad projektem bez kontroli źródła staje się niemożliwa od dwóch programistów . Nie trzy. Nie cztery. Dwa. Prawdopodobnie będziesz w stanie poradzić sobie z sytuacją z dwoma programistami w wyjątkowych okolicznościach : jeśli ci programiści są bardzo zorganizowani i profesjonalni, jeśli dobrze współdziałają, jeśli mogą łatwo wymieniać się (więc znajdują się w tym samym pokoju o tej samej godzinie, co czas) i jeśli są w stanie uniknąć błędów ludzkich (modyfikowanie przez pomyłkę pliku, który został zmodyfikowany przez inną osobę w tym samym momencie, a następnie usuwanie zmian dokonanych przez tę osobę).

W moim przypadku zawsze była to katastrofa, gdy dwie osoby brały udział w projekcie bez kontroli wersji. W najlepszych przypadkach jedna osoba wysyłała zmienione pliki do drugiej, a ta druga używała narzędzia różnicowego do ręcznego stosowania zmian. W najgorszych przypadkach jedna osoba śledziła zmiany, które wprowadzała, a następnie stosowała je za każdym razem, gdy druga osoba modyfikowała kod źródłowy. Rezultat: ogromna strata czasu, pieniędzy i wydajności.

Teraz, z mojego punktu widzenia i własnego doświadczenia, widzę trzy rozwiązania tego problemu:

• Zainstaluj kontrolę wersji, która jest łatwa w użyciu . Kiedyś instalowałem CollabNetSubversion jako serwer SVN, jest dość szybki i łatwy w konfiguracji, jeśli nie zależy ci na bezpieczeństwie . Jeśli korzystasz z Visual Studio, AnkhSvn może zostać zainstalowany, aby umożliwić programistom łatwe aktualizowanie / zatwierdzanie kodu źródłowego z poziomu Visual Studio.

• Przekonaj swojego szefa, że test Joela jest napisany przez osobę, która bardzo dobrze zna jego pracę, a jeśli test Joela sugeruje kontrolę wersji, jest to uzasadniony powód. W końcu może również zdecydować, że programiści nie potrzebują narzędzi do wyróżniania IDE / składni do pisania kodu. Notatnik Windows jest w porządku, prawda? A także po co mieć dostęp do Internetu? Potrzebujemy tylko bardzo, bardzo starego komputera z systemem Windows 3.1.

• Zrezygnuj z tej firmy , ponieważ mam wątpliwości, że wszystko oprócz kontroli wersji jest tam idealne i profesjonalne.

Nie używanie VCS w żadnym większym projekcie, ponieważ nie chcesz inwestować czasu na jego przygotowanie, jest jak podróż na boso, ponieważ nie chcesz inwestować czasu na zakładanie butów.

Każdy VCS jest o rząd wielkości lepszy niż żaden.

Bardzo łatwym sposobem na skonfigurowanie VCS jest uzyskanie TortoiseSVN (ponieważ wydaje się, że używasz C #, zakładam, że jesteś w systemie Windows). Tworzysz repozytorium w wybranym folderze lokalnym (przejdź do niego, kliknij prawym przyciskiem myszy> TortoiseSVN> Utwórz repozytorium tutaj). Udostępnij ten folder w sieci (najlepiej na komputerze, który jest zawsze dostępny) i dokonaj płatności za pomocą adresu URL file://computername/path/to/that/repository. Pobieranie wykluczone, konfiguracja zajmuje nie dłużej niż minutę.

Twoja odpowiedź to prosty link do szefa ... wyślij mu tę stronę pocztą e-mail i zaznacz, ile razy słowa „rzucić” pojawiają się wśród profesjonalistów.

Chociaż słowo „głupi” pojawia się prawdopodobnie tyle razy, jestem pewien, że twój szef nie. Po prostu nie jest dla niego jasne, czy jest to absolutna wartość. Pytanie, które należy zadać, brzmi: jakie pytanie związane z biznesem przyniosłoby tę samą odpowiedź (być może księgowy sugerujący: „Raczej nie ubezpieczaj tego budynku, że jesteś przywiązany do maksimum, to pozwoli ci zaoszczędzić kilka dolarów!”)

Kontrola źródła jest konieczna tylko wtedy, gdy liczba programistów w projekcie wynosi> 0. Zaczynam myśleć, że można powiedzieć to samo o ciągłej integracji ...

(-:

Ponieważ jesteście programistami ASP.NET, sugeruję, abyście chcieli korzystać z Subversion, TFS lub Mercurial - ale szczerze mówiąc, nie ma znaczenia, o ile tak długo będziecie z czymś pracować. Opracowywanie bez kontroli wersji nie ma żadnego sensu - tym bardziej, gdy narzędzia są mniej lub bardziej bezpłatne do wdrożenia, a narzut związany z ich użyciem jest minimalny.

TFS zapewni oszałamiający poziom integracji. DVCS (rtęciowy lub git) prawdopodobnie zapewni ci największą elastyczność i możliwości. Nie ma dobrego powodu, aby tego NIE robić.

Gdybym zaczynał od zera, prawie na pewno byłoby to z Mercurialem.

Po uzyskaniu kontroli wersji możesz przejść do serwera kompilacji (TFS, TeamCity), a następnie do ciągłej integracji, w którym to momencie zaczynasz zdobywać pięść.

Aby wrócić do punktu początkowego:

Będę kierownikiem projektu (kierownik projektu i główny programista) i będę odpowiedzialny za wszystko

Prawo, jesteś odpowiedzialny więc ty zdecydować trzeba kontroli wersji (bo nie), możesz zdecydować, że trzeba budować serwer (bo nie), możesz zdecydować, że trzeba mieć wdrożyć wyjście z projektu już od pierwszego dnia (ponieważ jeśli zawsze możesz go wdrożyć - a tym samym ułatwić dalsze testowanie) i że wdrożenie będzie wysoce zautomatyzowane - to kroki, które podejmujesz, aby zapewnić powodzenie swojego projektu (za który jesteś odpowiedzialny ...)

Jak wspomniano powyżej, możesz umieścić repozytorium w folderze współdzielonym, który już masz. Nie musisz tracić czasu na konfigurowanie serwera, jeśli korzystasz z rozproszonego systemu kontroli źródła, takiego jak Git, Mercurial lub Bazaar.

Sugeruję użycie Git, ponieważ masz już pewne doświadczenie z nim, lub Mercurial, który ma dobrą integrację z Visual Studio.

Jeśli w przyszłości twój szef powie ci przejście na TFS, to nadal jest lepsze niż brak kontroli wersji.

W moich czasach Powerbuilder mieliśmy cały zespół pracujący nad pakietem aplikacji bez kontroli źródła. Och, Powerbuilder miał kontrolę nad źródłami, ale w rzeczywistości używanie go było gównem - jeśli PB zawiesił się, gdy miałeś wyewidencjonowany plik (i rozbił DUŻO), ten opatentowany, binarny plik kodu źródłowego był teraz niedostępny. Niektóre flagi zostały ustawione w pliku i żadna inna kopia PB nie mogła go załadować, nawet ta sama osoba, która go wypisała.

To, co zrobiliśmy, było dość proste. „Hej, Tom, będę pracował na xyz.pbl. Więc nie wprowadzaj żadnych zmian”. W wielkim schemacie rzeczy rzadko mieliśmy problemy.

Zakładając, że nie możesz przekonać swojego zespołu do przyjęcia kontroli wersji lub że twój szef wieje o podstęp i nalega, aby zespół się zatrzymał, istnieje mniej niż optymalne podejście, które możesz przyjąć.

Zainstaluj Git lub Mercurial na swoim komputerze. Wersja własnej pracy. Gdy zespół zsynchronizuje swoją pracę za pomocą procesu Beyond Compare, dodaj zmiany do lokalnego repozytorium jako nowe zatwierdzenie. Zawsze będziesz mógł odzyskać poprzednią działającą wersję z lokalnego repozytorium, jeśli synchronizacja zespołu coś zepsuje.

Korzystanie z DVCS zapewnia, że ​​nie ma wymogu posiadania serwera ani skomplikowanego procesu konfiguracji. Instalacja Mercurial i rozpoczęcie pracy z podstawami nie powinno zająć więcej niż około 30 minut.

To nie jest idealne rozwiązanie, ale jest lepsze niż nic.

Moja początkowa reakcja na to była taka, że ​​masz już idealny proces pracy bez kontroli wersji. Wydaje się, że wszyscy macie dobry sposób na zarządzanie połączeniem i tak dalej. Z perspektywy zarządzania jest to pozornie dobra sytuacja. Spotkałem zespoły, które używają kontroli wersji, ale muszą zmagać się z samym procesem programowania.

Przekonanie szefa, że ​​oparcie argumentu na kontroli wersji przyniosłoby „lepszy proces”, jest bezcelowe. Jest jednak jeszcze jeden o wiele ważniejszy argument, dlaczego w pierwszej kolejności należy używać kontroli wersji lub źródła, którą można łatwo przeliczyć na pieniądze. I to jest:

Ryzyko

Problemem nie jest to, że użycie kontroli źródła poprawia proces programowania. Chodzi raczej o to, co by się stało, gdybyś w ogóle nie miał kontroli źródła. Jakie są zagrożenia?

Powiedz, że ktoś przez pomyłkę usuwa funkcję w kodzie lub w całym pliku? Ile kosztowałby ten koszt naprawy? Mam nadzieję, że ktoś to obejmie, więc poprawka jest znikoma.

Ale co się stanie, jeśli żadne ciało nie utworzy kopii zapasowej utraconego pliku? Ile godzin pracy kosztowałoby to naprawienie? Może to potrwać kilka dni i łatwo to obliczyć jako średnią roboczogodzin. Czy byłoby to zbyt wiele dla firmy? Czy można temu zaradzić w jakiś sposób szybciej?

Tak, z pewnym rodzajem kontroli źródła. W przeciwieństwie do tego: ile czasu zajmie skonfigurowanie kontroli wersji i utworzenie kopii zapasowej? Większość otwartych programów, takich jak git lub mercurial, nie zajmuje dużo czasu. Nauczenie ludzi, jak go używać, nie byłoby takie trudne, biorąc pod uwagę, że już wiesz, jak połączyć się z Beyond Compare i „zameldujesz się” w folderze udostępnionym. Jest to jednorazowy koszt konfiguracji. Czy te osobogodziny byłyby krótsze niż te, które wiążą się z ryzykiem? Jeśli jest to prawda, priorytetem powinno być użycie kontroli źródła.

Tak długo, jak możesz wskazać powód biznesowy, dlaczego warto mieć kontrolę źródła, a zarządzanie ryzykiem byłoby tak ogromnym czynnikiem, który przekonałby większość szefów.

Użyj rozproszonego systemu kontroli wersji, takiego jak git, i użyj komputera z folderami współdzielonymi do przechowywania repozytorium referencyjnego. Dlatego:

Każdy klon jest kopią zapasową

Jeśli dysk twardy serwera ulegnie awarii, każdy ma kopię gotową do wdrożenia na nowym dysku lub serwerze. Ponieważ Twoja firma nie traktuje poważnie kontroli wersji, przypuszczam, że może być prawie tak samo z kopiami zapasowymi.

Wspólne odniesienie

Posiadanie głównego repozytorium z odgałęzieniem głównym pozwala poznać wersję, która zawiera ostatnie słowo. To rozwiązuje problem: „Przetestowałeś swoje zmiany w stosunku do wersji Francka, ale czy miałeś też Johna? I jak je scaliłeś?”.

Dostarczaj bardziej komfortowo

Klient chce dziś wersji alfa? Możesz sprawdzić, czy mistrz jest wystarczająco stabilny i wysłać go. Jeśli tak nie jest i nie masz czasu, aby to naprawić, po prostu cofnij się w czasie i uzyskaj starszą, ale bardziej stabilną wersję. Nie możesz tego zrobić, jeśli masz tylko najnowszą wersję.

Cofnij się w czasie i napraw swoje błędy

Podczas ręcznego scalania wystąpiły problemy, które zobaczyłeś dopiero po kilku dniach, ale już zastąpiłeś zawartość folderów współdzielonych? Bez VSC nie masz historii, więc nie możesz łatwo wrócić do punktu, w którym możesz sprawdzić popełnione błędy i je naprawić. Kod nie jest jak obraz, jest jak film: ewoluuje w czasie. Możesz wyodrębnić zdjęcie z filmu. Nie można wyodrębnić filmu ze zdjęcia.

Łatwiejsze znajdowanie błędów

Pojawił się błąd, ale tak naprawdę nie zauważyłeś go w momencie jego wprowadzenia, więc nie możesz go naprawić, gdy kod jest „gorący”. Teraz tak naprawdę nie wiesz, która zmiana wprowadziła, więc może pochodzić z kilku różnych miejsc w kodzie. Zajmie to godziny, aby znaleźć, gdzie szukać. Dzięki git mogłeś właśnie opracować test, aby stwierdzić, czy błąd występuje w określonej wersji, i użyć, git bissectaby znaleźć dokładne zatwierdzenie, które wprowadziło błąd. Zamiast szukać tysięcy wierszy kodu, wiesz teraz, że znajduje się on w 10 zmianach wiersza, i możesz zachować test w swoim pakiecie testowym, aby upewnić się, że błąd nie zostanie ponownie wprowadzony.

Każdy programista jest odpowiedzialny za swoją pracę

Jeśli jesteś liderem zespołu i nie masz VCS, najprawdopodobniej będziesz musiał wykonać brudną robotę, połączenia. Jeśli zrobisz to sam, prawdopodobnie nie wiesz wszystkiego o wszystkich zmianach i może wprowadzić błędy. Wręcz przeciwnie, jeśli zawsze prosisz osoby, które napisały kod, o zebranie się za każdym razem, gdy istnieje kod do scalenia, to czas, aby nie wykorzystały go do stworzenia nowego kodu.

Dzięki VCS, w prostym przepływie pracy, programista musi tylko zadbać o swoją pracę i jedno zewnętrzne źródło zmian: gałąź master. W głównej gałęzi może być 1 lub 100 osób, to samo. Aby móc wprowadzić zmiany, będzie musiał je dostosować do najnowszych zmian wprowadzonych przez innych. Wydawać by się mogło, że wypychanie kodu zajmuje więcej czasu, ale dzieje się tak, ponieważ wykonujesz scalanie, które i tak zajęłoby trochę czasu.

Różnica polega na tym, że scalanie jest wykonywane przez osobę, która dokonała zmian, która najlepiej zna ten kod, ponieważ go napisał.

Kto napisał ten kod?

Tutaj jest ten błąd, ale kto napisał ten konkretny wiersz kodu? Trudno to zapamiętać, zwłaszcza jeśli projekt trwa kilka miesięcy. git blamepowiedziałbym ci, kto i kiedy napisano ten wiersz, więc możesz zapytać właściwą osobę, a nie ma „Nie pamiętam, żeby to pisać”.

Projekt staje się większy

Klient chce więcej funkcji, a jesteś zespołem zbyt małym, potrzebujesz innego programisty. Jak zarządzać zwiększoną złożonością scalania bez VSC?

Pilne zmiany

Klient zadzwonił i poprosił o krytyczną naprawę błędu w produkcji, ale pracujesz nad nową funkcją. Po prostu git stashodłóż zmiany na bok lub zatwierdz je w nowym oddziale i wypchnij zmiany, a będziesz gotowy do pracy nad pilną poprawką, bez obawy o utratę oczekującej pracy.

Działa 10 minut temu

Wprowadzasz jakieś zmiany lokalnie, a coś, co działało 10 minut temu, przestało działać. Bez VCS albo wpatrujesz się w kod, albo co najwyżej, wykonujesz kopię wersji referencyjnej i różnicujesz, aby zobaczyć, co zmieniasz. Och, czekaj, referencje zmieniły się, odkąd zacząłem działać, więc nie mogę już się różnić. I nie pomyślałem o zachowaniu nieskazitelnej kopii kodu, na którym oparłem swoje zmiany.

Dzięki VCS po prostu robisz coś takiego git diffod razu, a Twoja zmiana jest porównywana z odpowiednią wersją kodu, na którym się opierasz.

Muszę przechowywać dzienniki debugowania

Jesteś złym facetem i nie używasz rejestrowania? Musiałeś posypać printfwszystkie bazy kodem, dopóki nie znalazłeś wszystkich kawałków tego paskudnego robaka? Teraz znalazłeś jeden, naprawiłeś go, ale chcesz zachować starannie spreparowany kod debugowania, aby naprawić pozostałe problemy.

Bez VCS musisz skopiować pliki, usunąć kod debugowania (który może powodować błędy edycyjne), wypchnąć i odłożyć pliki z kopii zapasowej. Och, ale wygląda na to, że mimo to dostał się jakiś kod debugujący.

Dzięki git po prostu wybierasz git add --patchkilka wierszy kodu, które chcesz umieścić w swoim zatwierdzeniu, i możesz zatwierdzić tylko to. Następnie wznawiasz pracę i nadal masz kod debugowania. Nie trzeba było dotykać kodu, więc nie wystąpił błąd kopiowania / wklejania.

Wielka kula błota

Bez VCS ludzie pracują po swojej stronie i wprowadzają wiele zmian, czasem niezwiązanych. Gdy jest za dużo kodu do sprawdzenia, trudno jest znaleźć błąd.

VCS pozwoli ci dokonywać małych, przyrostowych zmian i da ci dziennik zmian. Dziennik zmian jest niezbędny: ludzie muszą powiedzieć, dlaczego dokonują zmiany, a nie jaka jest zmiana (na jakie pytanie odpowiada sama zmiana kodu). Oznacza to, że na przykład podczas sprawdzania kodu nowej funkcji nie będziesz musiał czytać wielu niepowiązanych zmian mieszanych, takich jak niepowiązane poprawki błędów. Pomaga to skupić się na kodzie, na którym Ci zależy.

Jeśli dam ci 100 ziemniaków 1 na 1, a jeden jest zgniły, natychmiast go znajdziesz. Teraz, jeśli zrzucę 100 ziemniaków przed sobą i poproszę o znalezienie zgniłego, to nie to samo zadanie.

Wcięcie

Mam nadzieję, że masz dobrą politykę stylu kodowania, w przeciwnym razie zmiany wcięć doprowadzą Cię do szaleństwa, jeśli scalisz ręcznie. Jasne, możesz zignorować białe znaki w zmianach (ale nie w językach, w których liczy się wcięcie, takich jak Python). Ale wtedy trudno ci będzie odczytać dziwnie wyglądający kod.

Jesteś liderem projektu

Jeśli jesteś liderem, oznacza to, że obwinisz się, jeśli coś nie zadziała. Jeśli nie możesz pogodzić się z sytuacją, ponieważ twój szef wciąż nie rozumie, że warto użyć odpowiedniego narzędzia do właściwej pracy, to przynajmniej odmówiłbym zostania liderem przewidywalnej porażki.

Użyj Dropbox, ma automatyczną historię wersji. Możesz udostępnić folder Dropbox wielu użytkownikom.

Edytować

Możesz także pobrać klienta TortoiseSVN i utworzyć „lokalne repozytorium” na dysku sieciowym. Następnie ludzie mogą pobrać kod źródłowy według lokalizacji folderu sieciowego.