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

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.

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).

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

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.

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.