W jaki sposób profesjonalni twórcy aplikacji korzystają z systemów kontroli wersji, takich jak GIT i Subversion?

10

Jestem początkującym programistą i od samego początku zastanawiałem się, w jaki sposób profesjonalne narzędzia, takie jak GIT i Subversion (nie bardzo dobrze rozumiem tych narzędzi), spełniają potrzeby ich projektu. Jeśli z niego skorzystają, jak mam coś takiego ustawić?

Moje aplikacje nie są tak duże i nie pracuję jeszcze w zespole, czy byłyby dla mnie ogromną pomocą?

Na tej stronie znajdują się pytania dotyczące korzystania z narzędzi, ale potrzebuję wsparcia dla początkujących.

Wolfi
źródło
5
Git i Subversion zawierają instrukcje; są w zasadzie repozytorium, które przechowuje kod programistyczny w uporządkowany sposób. Poszczególni programiści czerpią korzyści z posiadania pełnego rejestru zmian w kodzie oraz niezawodnego narzędzia do tworzenia kopii zapasowych. Zespoły projektowe korzystają z możliwości udostępniania tego samego repozytorium kodu źródłowego, utrzymując synchronizację zmian między stacjami roboczymi.
Robert Harvey,

Odpowiedzi:

13

Kontrola źródła jest wszechobecna - można nawet powiedzieć, że nie możesz nazywać się profesjonalnym programistą, jeśli go nie używasz. Nawet gdy sam się rozwija, kontrola źródła nadal oferuje całkiem sporo korzyści. Na koniec zapewnia zarówno historię, jak i obszerną ścieżkę cofania. To także pozwala ci eksperymentować o wiele więcej, mając pewność, że jeśli nie podoba ci się nowa wersja, zawsze możesz wrócić do tego, co miałeś wcześniej.

To powiedziawszy, przepływy pracy, nawet w systemie kontroli źródła, takim jak Subversion lub Git, różnią się znacznie w zależności od zespołu. Najlepszym miejscem na rozpoczęcie jest prawdopodobnie wybór systemu kontroli źródła i zapoznanie się ze standardowymi przepływami pracy (pamiętając o tym, że będziesz musiał przełączać przepływy pracy przez całe życie zawodowe).

Na początek polecam Git. Jestem fanem Git, ale dokładniej wybranie Git pozwala rozpocząć pracę bez serwera i skonfigurować serwer tylko wtedy, gdy ma to sens. Z drugiej strony Subversion wymaga serwera, a jego konfiguracja, choć nie jest niezwykle trudna, jest zniechęcająca, gdy nie znasz tego rodzaju rzeczy.

Oto dobry przegląd niektórych dobrych ogólnych zasad kontroli źródła: http://scottonwriting.net/sowblog/archive/2008/11/13/163320.aspx

Podczas samodzielnej pracy nie potrzebujesz dużej ilości pracy. Popełniaj wcześnie, często popełniaj. Jeśli zaczniesz wdrażać wersje, oznacz swoje wydania. Twórz gałęzie dla eksperymentów lub długich rozbieżnych prac (Git sprawia, że ​​jest to tańsze i prostsze niż Subversion).

Michał
źródło
1
Dobra odpowiedź oprócz jednego punktu. Zdecydowanie nie wybrałbym subversion wymagającej serwera, ponieważ jest to największą wadą, częściowo dlatego, że faktycznie używałem go bez niego dość często; repozytorium może znajdować się w katalogu lokalnym, a następnie instalacja jest pojedyncza komenda. Główną różnicą między Git a Subversion jest to, że systemy rozproszone, takie jak Git, są znacznie bardziej elastyczne niż scentralizowane, takie jak Subversion.
Jan Hudec
5

Systemy kontroli źródła (SVN, Git itp.) Na bardzo uproszczonym poziomie pozwalają zachować historię zmian plików. Pozwala to zobaczyć, jak zmieniał się Twój kod w czasie i wycofać zmiany, których możesz nie chcieć (np. Zmiana nie działa zgodnie z oczekiwaniami, możesz przywrócić kod do wcześniej znanego stanu). Jest to coś, co nawet samemu się rozwija, gdy zaczniesz go używać.

Gdy tylko współpracujesz z innymi osobami w zespole, korzyści rosną jeszcze bardziej, ponieważ wiele osób może zmienić ten sam plik, a jeśli zmiany nie powodują konfliktu (np. 2 osoby zmieniają różne sekcje pliku), zmiany zostaną scalone automatycznie. Jeśli wystąpią jakiekolwiek konflikty, będziesz mógł zobaczyć swoje zmiany obok swoich kolegów i omówić z nimi, jak je scalić.

Możesz także tworzyć migawki bazy kodu (zwykle nazywanej tagiem) podczas wypuszczania wersji kodu, dzięki czemu możesz łatwo debugować problemy, nawet jeśli główne źródło przeszło z nowymi funkcjami, które jeszcze nie zostały wydane.

Oto kilka przydatnych zasobów:

Pierwsze uruchomienie Subversion i Tortoise SVN z Visual Studio i .NET

Kontrola wersji z Subversion

Trevor Pilley
źródło
1
Nie daje +1, ponieważ nauczenie się Subversion jako pierwszego systemu jest swego rodzaju przeciwwskazaniem w dzisiejszych czasach, kiedy wszyscy przechodzą na systemy rozproszone.
Jan Hudec
3

Samouczki dla początkujących

Istnieją świetne samouczki (wideo i tekst), które pomogą Ci zacząć od bardzo podstawowego poziomu. Wydaje się, że Git ma świetne podejście do łagodnego wprowadzania tego tematu dla początkujących, który mówi ci, dlaczego pierwszy i używa powtórzeń, definicji i grafiki, aby pomóc Ci zapamiętać nazwy i funkcje kluczowych poleceń.

SVN

SVN miał być CVS zrobiony lepiej. CVS (współbieżny system wersji) działał na rzeczy na plik na raz, SVN zwykle pracował na rzeczy na katalog lub drzewo katalogów na raz. SVN (i CVS lub inne systemy) mogą być ważne, jeśli używasz go w pracy, ale moim zdaniem znacznie poprawiamy nasze zrozumienie tego, co trzeba zrobić, aby kontrolować źródła co kilka lat, tak jak wolisz późny model komputer, powinieneś preferować późne narzędzie do kontroli źródła. Zmiana systemów jest ogromną inwestycją, a historia kodu może zostać utracona, chociaż w wielu systemach istnieją konwertery, które umożliwiają migrację kodu, a także historii i innych artefaktów tworzonych przez wycofany system.

Profesjonalna kontrola źródła zaspokaja profesjonalne potrzeby

Twoje pytanie „W jaki sposób profesjonaliści używają narzędzi takich jak GIT i Subversion do zaspokojenia potrzeb swojego projektu?” ściśle wiąże się z pytaniem „W jaki sposób zespoły współpracują ze sobą, nie wchodząc sobie w drogę, a jednocześnie pracując tak szybko, jak to możliwe?”

Kod często się zmienia, a niektórzy programiści tworzą kod, z którego będą korzystać inni programiści, a różne zainteresowane strony potrzebują różnych poziomów stabilności w porównaniu do innowacji. Systemy kontroli źródła pomagają, przechowując kod do użytku przez zespół, utrzymując każdą zmianę w kontekście z wersjami, które zmieniają się wraz z upływem czasu, a często także z gałęziami, które są kontrolowanymi kopiami kodu, które służą do izolowania grup zmian od innych grup zmian.

Łączenie rzeczy z powrotem, łączenie pracy wielu członków zespołu jest obowiązkiem, który w SVN i starszych systemach był scentralizowany i trudny. W przypadku zespołów korzystających z Git łączenie staje się prostsze i bardziej dostępne dla wpływu całego zespołu zamiast kilku ekspertów. W SVN rozgałęzianie może być sprawą osobistą, ale łączenie często miało bolesny wpływ na zespół, a przeniesienie kodu z powrotem do głównej linii może być bolesne z punktu widzenia uzyskania pozwolenia, uniknięcia złamania, a poziom wysiłku wymagał zadania .

Z istniejącego repozytorium kontroli źródła specjaliści mogą zaspokoić inne potrzeby, takie jak diagnozowanie problemów do ich pierwotnej przyczyny. Jeśli istniały wersje kodu, które kiedyś działały, i nowo wykryte problemy, które występują w bieżącej wersji, można przejść do przodu i do tyłu w historii, aby wskazać, kiedy wystąpił problem. W SVN ta funkcja jest niedojrzała, ale w Gicie wyszukiwanie ostatniej działającej / pierwszej niesprawnej wersji jest obsługiwane przez polecenie o nazwie git bisect. Problem będzie spowodowany jedną ze zmian źródłowych między dwiema wersjami, co jest potencjalnie znacznie łatwiejszą diagnozą niż przeszukiwanie całej bazy kodu.

Przepraszam za włóczenie się, mam nadzieję, że pomoże ci to na drodze do kontroli źródła.

DeveloperDon
źródło
0

Mój zespół używa domowego systemu kontroli wersji zespołu. (Niestety, Git nie wydaje się jeszcze działać na „rodzimych” plikach źródłowych IBM i). Ale osobiście, kiedy już pobrałem źródło z tego systemu, używam Gita podczas projektowania, aż projekt się skończy i sprawdzę go z powrotem w zespół VCS.

Jak mówią podczas głosowania ... popełnij wcześnie, popełnij często. Gdy pracuję nad nowymi funkcjami, zatwierdzam. Zatwierdzam między kompilacjami i przy każdej próbie poprawienia błędów kompilatora, za każdym razem, gdy wprowadzam zmiany podczas testowania i debugowania. Dzięki temu łatwiej jest wypróbować kilka odmian motywu i w razie potrzeby łatwo go wycofać, zwłaszcza gdy zmiana jest koordynowana w kilku plikach.

Git poprawił sposób, w jaki podchodzę do rozwoju.

WarrenT
źródło
„Wydaje się, że Git nie działa jeszcze na„ natywnych ”plikach źródłowych systemu IBM i)” - Git powinien działać na każdym pliku. O co tu chodzi?
Marnen Laibow-Koser
@ MarnenLaibow-Koser Większość programistów IBM i pracuje z plikami źródłowymi w systemie, który możemy nazwać rodzimym (starszym) systemem plików QSYS, w którym pliki źródłowe mają wbudowany format o stałej długości. Każdy wiersz zaczyna się od 6-cyfrowego numeru sekwencyjnego, 6-cyfrowej daty zmiany, a następnie wiersza tekstu kodu źródłowego. Sekwencja i data zmiany mogą ulec zmianie, nawet jeśli kod źródłowy w linii nie zmienił się. Rozwiązania mogły zostać opracowane niedawno. IBM i inni wspierają teraz git na IBM i. I nie powinno być problemu ze źródłem w „normalnych” plikach strumieniowych w innych systemach plików IFS w systemie IBM i.
WarrenT
O Boże, niejasno pamiętam to z tworzenia AS / 400 20 lat temu. Myślę jednak, że nie ma powodu, aby Git nie działał z takimi plikami. Może być konieczne napisanie sterownika scalania, który dyskontuje numery linii, ale powinno to być łatwe do zrobienia. (Zastanawiam się, czy to właśnie zrobił IBM ...)
Marnen Laibow-Koser
Ale jeśli usuniesz numery linii i datę zmiany linii, stracisz je, gdy sprawdzisz coś z Git. Nie jest łatwo przekonać niektórych ludzi, że nie potrzebują już tych dat, po poleganiu na nich przez może trzy dekady. Tak, wiem, że wina Git zapewnia to samo, ale ludzie niechętnie rezygnują z czegoś, na czym tak długo polegali, nawet jeśli niekoniecznie jest to logiczny argument.
WarrenT
Możesz faktycznie zrobić filtr Git Clean / Smudge, aby przywrócić datę z winy Git. :)
Marnen Laibow-Koser