Teoria (i terminologia) za kontrolą źródła

Question

Próbowałem używać kontroli kodu źródłowego dla kilku projektów, ale wciąż tak naprawdę nie rozumiem. W przypadku tych projektów użyliśmy TortoiseSVN i mieliśmy tylko jedną linię wersji. (Nie ma tułowia, gałęzi ani żadnej z nich). Jeśli jest zalecany sposób konfiguracji systemów kontroli źródła, co to jest? Jakie są powody i zalety takiego ustawienia? Jakie są podstawowe różnice między działaniem scentralizowanego i rozproszonego systemu kontroli źródła?

Answer 1

I polecam sprawdzić następujące Eric Sink:

http://www.ericsink.com/scm/source_control.html

Mając jakiś system kontroli wersji w miejsce jest prawdopodobnie najważniejszym narzędziem programista ma do przeglądania zmian kodu i zrozumienie kto zrobił co komu. Nawet w przypadku projektów jednoosobowych niezwykle ważne jest, aby móc odróżnić obecny kod od wcześniej znanej działającej wersji, aby zrozumieć, co mogło pójść nie tak ze względu na zmianę.

Answer 2

Pomyśl o kontroli źródła jako gigantycznym przycisku "Cofnij" dla kodu źródłowego. Za każdym razem, gdy się meldujesz, dodajesz punkt, do którego możesz wrócić. Nawet jeśli nie używasz rozgałęzień/scalania, sama ta funkcja może być bardzo cenna.

Dodatkowo, dzięki jednej "autorytatywnej" wersji kontroli źródła, tworzenie kopii zapasowych staje się znacznie łatwiejsze.

Scentralizowana vs. rozproszona ... różnica polega na tym, że w dystrybucji nie ma jednej "autorytatywnej" wersji kontroli źródła, chociaż w praktyce ludzie zazwyczaj wciąż mają drzewo główne.

Dużą zaletą rozproszonych kontroli źródła jest dwojaki:

1. Kiedy używać rozprowadzany kontroli źródła, masz całe drzewa źródłowego na komputerze lokalnym. Możesz zatwierdzać, tworzyć gałęzie i pracować prawie tak, jakbyś był sam, a kiedy będziesz gotowy, aby wprowadzić zmiany, możesz je promować ze swojego komputera do kopii głównej. Jeśli pracujesz "offline" dużo, może to być ogromna korzyść.

2. Nie musisz pytać nikogo o pozwolenie, aby zostać dystrybutorem kontroli źródła. Jeśli osoba A realizuje projekt, ale osoba B i C chce wprowadzać zmiany i dzielić się tymi zmianami ze sobą, staje się znacznie łatwiejsze dzięki rozproszonej kontroli źródła.

Answer 3

Nawet jeśli nie rozgałęziacie się, może okazać się przydatne używanie znaczników do oznaczania wersji.

Wyobraź sobie, że wczoraj wprowadziłeś nową wersję swojego oprogramowania i zacząłeś wprowadzać istotne zmiany w następnej wersji. Użytkownik dzwoni do Ciebie, aby zgłosić poważny błąd we wczorajszym wydaniu. Nie możesz tak po prostu naprawić i skopiować zmian z twojego pnia rozwojowego, ponieważ zmiany, które właśnie spowodowałeś, są niestabilne.

Jeśli oznakowałeś wydanie, możesz sprawdzić jego kopię roboczą i użyć go do usunięcia błędu.

Następnie możesz utworzyć gałąź w tagu i sprawdzić poprawkę błędu. W ten sposób możesz naprawić więcej błędów w tej wersji, podczas gdy nadal będziesz aktualizować bagażnik. Możesz również scalić te poprawki w bagażniku, aby były obecne w następnej wersji.

Answer 4

Oto dwa artykuły, które są bardzo pomocne w zrozumieniu podstaw. Poza informowaniem, firma Sink sprzedaje świetny produkt kontroli źródła o nazwie Vault, który jest bezpłatny dla pojedynczych użytkowników (nie jestem w żaden sposób powiązany z tą firmą).

http://www.ericsink.com/scm/source_control.html

http://betterexplained.com/articles/a-visual-guide-to-version-control/

Vault informacji na www.vault.com.

Answer 5

Powszechnie stosowanym standardem dla Subversion jest posiadanie trzech folderów w katalogu głównym repozytorium: trunk, branch and tags. Folder trunk przechowuje aktualną "główną" linię rozwoju. Dla wielu sklepów i sytuacji jest to wszystko, czego używają ... tylko jedno działające repozytorium kodu.

Folder tagów posuwa się o krok dalej i pozwala "kontrolować" twój kod w określonych momentach. Na przykład, kiedy wydajesz nową kompilację lub czasami po prostu make nową kompilację, "znacznik" kopię w tym folderze. To po prostu pozwala dokładnie wiedzieć, jak wyglądał Twój kod w tym momencie.

Folder oddziałów zawiera różne gałęzie, które mogą być potrzebne w szczególnych sytuacjach. Czasami oddział jest miejscem pracy nad funkcją eksperymentalną lub funkcjami, które mogą zająć dużo czasu, aby uzyskać stabilność (dlatego nie chcesz jeszcze wprowadzać ich do głównej linii). Innym razem oddział może reprezentować "produkcyjną" kopię kodu, którą można edytować i wdrażać niezależnie od głównej linii kodu, która zawiera zmiany przeznaczone dla przyszłej wersji.

W każdym razie jest to tylko jeden z aspektów konfiguracji systemu, ale myślę, że warto zastanowić się nad tą strukturą.