Dlaczego powinienem używać kontroli wersji? [Zamknięte]

Czytałem blog, na którym pisarz to powiedział

„Kod nie istnieje, dopóki nie zostanie wpisany do systemu kontroli wersji. Używaj kontroli wersji do wszystkiego, co robisz. Dowolna kontrola wersji, SVN, Git, nawet CVS, opanuj ją i używaj”.

Nigdy nie korzystałem z żadnej kontroli wersji i nie uważam tego za wspaniały. Wyszukałem go w Google i obejrzałem go wcześniej, ale potrzebuję tylko, aby to było przedstawione dzieciom, jeśli chcesz.

Jak teraz rozumiem, rzeczy takie jak SVN służą do przechowywania kodu online, aby grupa użytkowników lub innych programistów miała dostęp do tego samego kodu. Po zaktualizowaniu części kodu możesz przesłać nową wersję, a SVN zachowa kopie starego kodu, a także nowe, które zaktualizujesz.

Czy to jest podstawowa idea, czy też całkowicie się mylę?

Jeśli mam rację, to może się nie przydać, jeśli:

• Nie pozwól innym osobom pracować nad kodem.
• Nie planuj pozwalać innym mieć kodu.

Czy kiedykolwiek:

• Dokonałeś zmiany w kodzie, zdałeś sobie sprawę, że to pomyłka i chcesz wrócić?
• Zgubiony kod lub kopia zapasowa była zbyt stara?
• Czy musiałeś utrzymywać wiele wersji produktu?
• Chcesz zobaczyć różnicę między dwiema (lub więcej) wersjami swojego kodu?
• Chcesz udowodnić, że jakaś zmiana zepsuła lub naprawiła fragment kodu?
• Chcesz przejrzeć historię jakiegoś kodu?
• Chcesz przesłać zmianę w kodzie innej osoby?
• Chcesz udostępnić swój kod lub pozwolić innym osobom pracować nad Twoim kodem?
• Chciałeś zobaczyć, ile pracy jest wykonywanych, gdzie, kiedy i przez kogo?
• Chcesz poeksperymentować z nową funkcją bez ingerencji w działający kod?

W takich przypadkach i bez wątpienia w innych, system kontroli wersji powinien ułatwić Ci życie.

Źle cytując przyjaciela: cywilizowane narzędzie dla cywilizowanego wieku.

Nawet jeśli pracujesz sam, możesz skorzystać z kontroli źródła. Między innymi z tych powodów:

• Nic nie tracisz. Nigdy więcej nie wykomentowałem kodu. Po prostu go usuwam. Nie zaśmieca mojego ekranu i nie jest zgubiony. Mogę go odzyskać, sprawdzając stary commit.

• Możesz eksperymentować do woli. Jeśli to nie rozwiąże problemu, przywróć go.

• Możesz przejrzeć poprzednie wersje kodu, aby dowiedzieć się, kiedy i gdzie wprowadzono błędy. git bisectjest pod tym względem świetny.

• Bardziej „zaawansowane” funkcje, takie jak rozgałęzianie i scalanie, pozwalają na tworzenie wielu równoległych linii rozwoju. Możesz pracować w dwóch jednoczesnych funkcjach bez zakłóceń i przełączać się między nimi bez większych kłopotów.

• Możesz zobaczyć, „co się zmieniło”. Może się to wydawać proste, ale często to sprawdzam. Bardzo często mój jednoosobowy przepływ pracy zaczynam od: co robiłem wczoraj?

Po prostu śmiało i wypróbuj. Zacznij powoli od podstawowych funkcji i ucz się innych w miarę upływu czasu. Wkrótce przekonasz się, że nigdy nie będziesz chciał wracać do „ciemnych wieków” bez VCS.

Jeśli chcesz mieć lokalny VCS, możesz skonfigurować własny serwer subversion (co robiłem w przeszłości), ale dzisiaj polecam używanie git. Dużo prostsze. Po prostu cddo katalogu z kodem i uruchom:

git init

Witaj w klubie.

Kontrola wersji to rzadkie narzędzie, które powiedziałbym, że jest absolutnie wymagane, nawet jeśli używasz go tylko jako samodzielny programista. Niektórzy mówią, że jest to narzędzie, za pomocą którego żyjesz i umierasz, zgadzam się z tym stwierdzeniem.

Prawdopodobnie używasz teraz kontroli wersji, nawet jeśli o tym nie wiesz. Czy masz jakieś foldery z napisem „XXX Php Code (grudzień)” lub „XXX.php.bak.2”? To są formy kontroli wersji. Dobry system kontroli wersji zajmie się tym automatycznie. Będziesz mógł cofnąć się do dowolnego punktu w czasie (w którym zarejestrowałeś dane) i zobaczyć dokładną kopię tych danych.

Ponadto, jeśli zaadoptujesz system taki jak subversion i użyjesz zdalnego repozytorium (takiego jak na serwerze, którego jesteś właścicielem), będziesz mieć miejsce na przechowywanie całego kodu. Potrzebujesz kopii swojego kodu gdzie indziej? Nie ma problemu, po prostu to sprawdź. Awaria dysku twardego w domu? Nie ma problemu (przynajmniej z kodem źródłowym).

Nawet jeśli nie używasz teraz kontroli wersji, prawdopodobnie użyjesz jej w pewnym momencie później w swojej karierze i możesz odnieść korzyści, jeśli teraz poczujesz się bardziej komfortowo z zasadami.

Nawet pracując sam, czy to się kiedykolwiek zdarzyło? Uruchamiasz aplikację i coś nie działa i mówisz „to działało wczoraj i przysięgam, że nie dotknąłem tej klasy / metody”. Jeśli regularnie sprawdzasz kod, szybkie porównanie wersji pokaże dokładnie, co zmieniło się w ciągu ostatniego dnia.

Oto scenariusz, który może zilustrować użyteczność kontroli źródła, nawet jeśli pracujesz sam.

Twój klient prosi Cię o ambitną modyfikację serwisu. Zajmie Ci to kilka tygodni i będzie wymagało edycji wielu stron. Zabierasz się do pracy.

Wykonałeś to zadanie w 50%, gdy klient dzwoni i każe porzucić to, co robisz, aby wprowadzić pilną, ale mniejszą zmianę w witrynie. Nie skończyłeś z większym zadaniem, więc nie jest gotowy do uruchomienia, a klient nie może czekać na mniejszą zmianę. Ale on również chce, aby drobna zmiana została włączona do twojej pracy dla większej zmiany.

Być może pracujesz nad dużym zadaniem w osobnym folderze zawierającym kopię strony internetowej. Teraz musisz wymyślić, jak dokonać drobnej zmiany w sposób, który można szybko wdrożyć. Pracujesz wściekle i robisz to. Klient oddzwania z dalszymi prośbami o udoskonalenie. Ty też to robisz i wdrażasz. Wszystko dobrze.

Teraz musisz włączyć to do prac w toku, aby dokonać głównej zmiany. Co zmieniłeś do pilnej pracy? Pracowałeś zbyt szybko, żeby robić notatki. I nie możesz po prostu łatwo porównać dwóch katalogów teraz, gdy oba mają zmiany w stosunku do linii bazowej, od której zacząłeś.

Powyższy scenariusz pokazuje, że kontrola źródła może być świetnym narzędziem, nawet jeśli pracujesz w pojedynkę.

• Możesz używać gałęzi do pracy nad zadaniami długoterminowymi, a po zakończeniu scalić gałąź z powrotem do głównej linii.
• Możesz porównać całe zestawy plików z innymi gałęziami lub z wcześniejszymi wersjami, aby zobaczyć, co się różni.
• Możesz śledzić pracę w czasie (co jest świetne do raportowania i fakturowania).
• Możesz odzyskać dowolną wersję dowolnego pliku na podstawie daty lub określonego etapu.

W przypadku pracy solowej zalecany jest Subversion lub Git. Każdy może preferować jedną lub drugą, ale jedno i drugie jest zdecydowanie lepsze niż nieużywanie żadnej kontroli wersji. Dobre książki to „ Pragmatic Version Control using Subversion, 2nd Edition ” Mike'a Masona lub „ Pragmatic Version Control Using Git ” Travisa Swicegooda.

Oryginalny autor: Bill Karwin

Nawet jako pojedynczy programista kontrola źródła oferuje ogromne korzyści. Pozwala na przechowywanie historii kodu i powrót do poprzednich wersji oprogramowania w dowolnym momencie. Pozwala to na nieustraszoną elastyczność eksperymentowania, ponieważ zawsze możesz przywrócić inną wersję kodu źródłowego, która działała.

To tak, jakby mieć gigantyczny przycisk „cofnij” z powrotem do pierwszej linii kodu.

Kontrola wersji jest prawie niemożliwa do życia bez niej po rozpoczęciu jej używania. Jest to niezbędne, jeśli więcej niż jeden programista pracuje na tej samej bazie kodu ... ale jest również bardzo przydatne dla jednego programisty.

Śledzi zmiany w kodzie i umożliwia powrót do poprzednich wersji. Dzięki temu możesz eksperymentować ze świadomością, że jeśli coś się zepsuje, możesz cofnąć zmiany.

Zyskujesz bezpieczeństwo (w sensie posiadania kopii zapasowej swojego kodu) i wersjonowanie swojego kodu (zakładając, że nabędziesz nawyku częstego wprowadzania zmian). Obie są bardzo dobre, nawet jeśli nikt inny nigdy nie pracował z tobą nad kodem ...

Kontrola wersji doskonale nadaje się do sprawdzania poprzednich wersji, nawet jeśli pracujesz sam. Na przykład, jeśli przypadkowo usuniesz kod lub plik, możesz go odzyskać; lub możesz porównać poprzednie wersje, aby zobaczyć, dlaczego wkradł się nowy błąd. Dobrze jest również, jeśli jesteś jedną osobą pracującą w wielu lokalizacjach.

Moim ulubionym jest git.

Istnieje wiele powodów, dla których warto używać kontroli wersji, nawet jeśli jesteś jedyną osobą, która kiedykolwiek dotknie kodu.

• Kopia zapasowa - co się stanie, jeśli dysk twardy ulegnie awarii? Masz gdzieś kopię?
• Historia wersji - czy obecnie przechowujesz kopie kodu w różnych folderach? Kontrola wersji umożliwia śledzenie zmian w czasie i łatwe porównywanie różnych wersji, scalanie, cofanie zmian itp. Za pomocą narzędzi.
• Branże - możliwość przetestowania niektórych zmian, nadal śledź to, co robisz, a następnie zdecyduj, czy chcesz to zachować i połączyć z głównym projektem, czy po prostu wyrzucić.

Jeśli zachowasz kod pod kontrolą wersji, naprawdę łatwo zobaczysz, które pliki zmieniłeś (lub zapomniałeś dodać do linii bazowej).

Coś, o czym nikt inny nie wspomniał wprost, to oznaczanie lub etykietowanie wydań. Jeśli masz klienta używającego wersji 1 twojego oprogramowania i jesteś zajęty pracą nad wersją 2, co robisz, gdy klient zgłasza błąd i musisz skompilować wersję 1.1?

System kontroli źródła pozwoli ci oznaczyć każdą wydaną wersję, abyś mógł wrócić do niej później, wprowadzić poprawkę (i scalić ją z kodem nowej wersji 2) i stworzyć nową wersję bez obawy, że możesz przypadkowo dostarczyć coś, co nie jest gotowy.

Kontrola źródła jest podstawową częścią nowoczesnego tworzenia oprogramowania. Jeśli go nie używasz (nawet do osobistych projektów, ponieważ im więcej masz doświadczenia, tym lepiej), robisz coś źle.

Zwykle jednym z pierwszych pytań, które zadaję podczas rozmowy kwalifikacyjnej o pracę, jest „Czego używasz do kontroli źródła?” Jak dotąd tylko jedno miejsce powiedziało „Nic”, ale planowali naprawić to „Naprawdę wkrótce…”

Fakt, że inni programiści uczestniczą lub nie, jest całkowicie ortogonalny w stosunku do potrzeby systemu kontroli wersji.

Możesz być jedynym programistą, ale nadal będziesz czerpać korzyści z:

• ślad historii wszystkich zmian
• zdolność do cofania się i do przodu w tej historii
• możliwość eksperymentowania ze źródłem i posiadanie działającej wersji (rozgałęzienie)
• kopia zapasowa (zwłaszcza jeśli używasz innej maszyny jako serwera kontroli źródła, a nawet więcej, jeśli ta maszyna jest regularnie archiwizowana)

Teraz, jeśli masz grupę rozwijającą się na tym samym kodzie, kontrola wersji jest jeszcze bardziej konieczna

• ludzie mogą edytować ten sam plik w tym samym czasie (w zależności od konkretnego systemu, ale większość rozsądnych na to pozwala)
• możesz powiedzieć, kto i kiedy zrobił kod

Gdy zaangażowanych jest więcej osób, bardziej istotne jest, które narzędzie do kontroli wersji wybierzesz, w zależności od stylu programowania.

Chodzi również o tworzenie kopii zapasowych starego pliku, dlatego nazywa się to „Subversion”. Możesz więc zarządzać wieloma wersjami swojej pracy, w których możesz wrócić (cofnąć) i zarządzać różnymi jej implementacjami (rozgałęzianie).

Może się okazać, że masz działającą wersję programu.

Decydujesz się dodać kilka nowych funkcji w pewnym okresie i udostępniasz to.

Zaczynasz otrzymywać raporty o błędach wpływające na kod, którego nie dotknąłeś.

Na przykład używając SVN, możesz wrócić do starszej wersji i sprawdzić, czy nowy błąd istnieje. Gdy znajdziesz wersję, która wprowadziła błąd, łatwiej będzie to naprawić, ponieważ możesz porównać wersję, która działała, z wersją, która nie zadziałała, i zobaczyć, co się zmieniło, a następnie zawęzi wyszukiwanie.

Kontrola źródła ma wiele zastosowań, nawet jeśli jesteś jedynym programistą.

Wygląda na to, że szukasz czegoś nieco lżejszego. Sprawdź Mercurial ( niesamowitą książkę informacyjną ). Używam go do wszystkiego, od kodu źródłowego po osobistą korespondencję.

Niektóre korzyści:

• Gigantyczny przycisk Cofnij, dzięki czemu możesz zwrócić te beztroskie dni z zeszłego tygodnia, kiedy kod faktycznie działał
• Kod do wyrzucenia. Nie wiesz, czy to najlepszy sposób na zrobienie czegoś? Zrób gałąź i eksperymentuj. Nikt poza tobą nigdy nie musi o tym wiedzieć, jeśli używasz DVCS, takiego jak mercurial.
• Zsynchronizowany rozwój. Tworzę na 4 różnych komputerach. Naciskam i ciągnę między nimi, aby zachować aktualność, więc bez względu na to, na którym jestem, mam najnowsze wersje.

Nawet jeśli nie byłeś jeszcze w sytuacji, w której potrzebowałeś starszej wersji programu, posiadanie kontroli źródła daje większą pewność przy wprowadzaniu dużych zmian.

Po użyciu kontroli kodu zacząłem robić bardziej agresywną refaktoryzację, ponieważ zawsze wiedziałem, że działającą wersję można łatwo przywrócić.

Niedawno też zacząłem interesować się kontrolą wersji. W systemach kontroli wersji masz koncepcję repozytorium dla swojego kodu. Bogactwo nowych poleceń powłoki jest bardzo szybko przyswajane, dzięki czemu można korzystać z tego repozytorium.

Po zapisaniu kodu do pliku, możesz popełnić to repozytorium swojego projektu. W miarę opracowywania kodu i zatwierdzania zmian repozytorium opracowuje serię poprawek . Możesz uzyskać dostęp do każdego z nich, wyewidencjonowując wersję. Jeśli pracujesz sam, jest mało prawdopodobne, że będziesz dużo sprawdzać, chyba że zgubisz pliki kodu lub zechcesz pracować na innym komputerze. W takich przypadkach zazwyczaj będziesz pobierać najnowszą wersję wszystkich plików.

Ze swojej strony nie przechowuję już plików ani folderów o nazwie „project_old”, kiedy decyduję się coś refaktoryzować. Wszelkie zmiany, które wprowadzam, są zapisywane przyrostowo i zawsze będę mógł cofnąć się do projektu, który działał jako całość. Rzadko używam FTP do wdrażania, ponieważ po prostu pobieram kod za pomocą ssh. Pobierane są tylko pliki, które zmieniłem i jeśli muszę przeładować serwer, terminal już tam jest.

Uważam, że ta rozmowa na GIT jest naprawdę pouczająca; http://www.youtube.com/watch?v=4XpnKHJAok8

To dyskusja w Google, w której Linus Torvalds argumentuje za używaniem jednego systemu kontroli wersji zamiast innego. Robiąc to, wyjaśnia, jak pracują, używając pojęć, a następnie porównuje różne sposoby ich wdrażania.

Prawdopodobnie będziesz potrzebować czegoś takiego jak Subversion, nawet jeśli pracujesz samodzielnie, aby mieć historię wszystkich swoich zmian. Możesz chcieć zobaczyć, jak kiedyś wyglądał fragment kodu, aby przypomnieć sobie, dlaczego wprowadziłeś zmianę.

Posiadanie kontroli źródła jest również przydatne, gdy często się meldujesz. Jeśli często się meldujesz, zawsze będziesz w stanie często wycofywać się. Wiele razy mogłeś zacząć podążać jedną ścieżką, aby rozwiązać problem, a potem zdać sobie sprawę, że była to zła ścieżka. Wiele razy mogłeś po prostu szczekać złą ścieżką i skończyć z budowaniem okropnego rozwiązania - tylko dlatego, że nie chciałeś stracić całej swojej pracy. Dzięki częstemu meldowaniu się ostatni punkt „szczęścia” nie jest daleko, więc nawet jeśli pójdziesz złą ścieżką, zawsze możesz cofnąć się i spróbować ponownie i znaleźć bardziej eleganckie i proste rozwiązanie. Co jest zawsze dobre, abyś mógł zrozumieć i zachować to, co napisałeś w przyszłości.

To zależy od wielkości projektu i tego, jak często zmieniasz zdanie na temat jego części. W przypadku małych projektów, w których po prostu robisz coś w sposób liniowy, kontrola wersji prawdopodobnie nie będzie zbyt pomocna (chociaż jeśli przypadkowo usuniesz lub uszkodzisz plik bez kontroli wersji, będziesz płakać).

Ale kilka tygodni temu spotkałem przyjaciela, który sam pisał ogromny projekt hobbystyczny. Miał dziesięć lub dwadzieścia kopii swojego kodu, z przyrostkami takimi jak „X1”, „X2”, „test”, „szybciej” i tak dalej.

Jeśli zrobiłem więcej niż dwie kopie kodu, ty potrzebować kontroli wersji . Dobry system kontroli wersji pozwala cofnąć zmianę wprowadzoną jakiś czas temu bez cofania rzeczy, które zrobiłeś po wprowadzeniu tej zmiany. Pozwala zobaczyć, kiedy zostały wprowadzone określone zmiany. Umożliwia podzielenie kodu na dwie „ścieżki” (np. Jedną do testowania nowego pomysłu, drugą do zabezpieczenia „wypróbowanego i zaufanego” kodu do czasu zakończenia testów), a następnie scalenie ich z powrotem.

Jest rok 2019. W tej stosunkowo późnej chwili napotykam zastrzeżenia do korzystania z Git; widzę tu pewne zastrzeżenia. Ta dyskusja znacznie wyjaśniła konieczność używania kontroli źródła zamiast po prostu tworzenia nazwanych kopii zapasowych. Jednym z kluczowych punktów jest kontrola źródła, nawet jeśli mamy pojedyncze projekty deweloperskie. Nikt nie jest idealny. Popełniasz błędy. Jeśli jesteś wyjątkowo dobry i mądry, będziesz tworzyć bardziej złożone aplikacje; ale nadal będziesz popełniać błędy i to załatwia sprawę. Jezu, o Pete! Nigdy nie używam Linuksa, ale myślę, że wszyscy szanujemy wielką inteligencję techniczną Linusa Torvaldsa. Uznał znaczenie kontroli źródła i wniósł klucz do powstania Git. To podsumowanie wszystkich podanych tutaj powodów. Torvalds to rozumie: kontrola źródła jest bardzo ważna: użyj kontroli źródła. Dziękuję wszystkim, którzy skomentowali ten długo trwający temat.