Używasz kontroli wersji podczas pracy w pojedynkę i przy małych projektach?

Bardzo często pracuję nad małymi projektami tylko dla siebie. Pracuję na jednej maszynie, ale ostatnio pomyślałem o użyciu kontroli wersji. Miałoby to pewne zalety, na przykład:

• Nie muszę już dbać o lokalną kopię zapasową
• Błędy można łatwo cofnąć
• Historię można zachować

Ale z drugiej strony ma też pewne wady, na przykład:

• Wymagane dodatkowe zasoby
• Czas na konfigurację, przyzwyczajenie się itp.

Z własnego doświadczenia, czy warto korzystać z kontroli wersji, gdy pracujesz sam?

Tak.

Wystarczy jeden błąd, a sam się za to przekopiesz. Jesteś także w stanie wybrać, który system kontroli wersji (VCS) ma być używany. Jeśli istnieje jakakolwiek możliwość, że będziesz pracować w zespole programistów w przyszłości, jest to świetny czas, aby dać sobie praktyczne doświadczenie z VCS. SVN i Git (lub Mercurial) byłyby świetnymi punktami wyjścia i powinny zająć tylko kilka godzin, aby uchwycić podstawowe polecenia w każdym VCS.

Teraz obalić, co negatywne punkty ...

1) Wymagane dodatkowe zasoby

Tylko zasób wymagana jest przestrzeń na dysku. Ponieważ jest to niewielki procent (mniejszy w Git niż X ) całego kodu, nie sądzę, że będzie to problem. To też nie kosztuje.

2) Czas na konfigurację, przyzwyczajenie się itp.

Będzie to wymagało czasu, aby się tego nauczyć, ale dla każdego z nich jest tylko kilka godzin (jak wspomniano powyżej). W dłuższej perspektywie może potencjalnie zaoszczędzić nieskończoną ilość czasu (i wiele więcej). Gdy opanujesz podstawy VCS, będzie to znacznie mniej skomplikowane niż tworzenie lokalnej kopii zapasowej, którą masz na myśli.

Tak. Użyj tego do wszystkiego. Użyj go do każdego dokumentu, który piszesz w programie Word. Użyj go do całego pisanego kodu. Użyj go do każdego tworzonego obrazu.

Ponadto, gdy nauczysz się go używać, będziesz lepiej, gdy będziesz pracować w środowisku zespołowym.

Uwielbiam używać Git, gdy pracuję sam. Na przykład, pracując w PHP, po prostu tworzę repozytorium Git w moim lokalnym katalogu, który obsługuje Apache. Mogę łatwo rozpocząć pracę nad nową funkcją (w oddziale) i przetestować ją na moim komputerze lokalnym. Następnie, jeśli coś się pojawi i muszę dokonać „naprawy awaryjnej”, jest to proste:

git checkout master

Voila! Mój katalog roboczy powrócił do stanu sprzed mojego oddziału. Mogę dokonać szybkiej naprawy. Kiedy skończę, mogę wrócić do oddziału i dalej się rozwijać.

Krzywa uczenia się nie jest bardzo stroma, a online jest mnóstwo informacji, które pomogą Ci zacząć. Kop w to. To jest tego warte.

Dziennik zmian zapewnia dobre miejsce do dokumentowania zmian bez zaśmiecania źródła.

Wybierz coś hostowanego jak SourceRepo. Nie jest zbyt drogi, ale korzystanie z kontroli źródła znacznie ułatwia cofanie błędów i przywracanie kodu.

W razie potrzeby możesz uzyskać do niego dostęp w dowolnym miejscu.

Zawsze używałem git do mojego rozwoju, dopóki nie zdałem sobie sprawy, że mogę go używać również do innych celów. Więc spróbuj git, to da ci prawdziwe repozytorium, bez potrzeby serwera i stałego połączenia (to dla mnie duży plus); nie rozprzestrzenia podkatalogów twojego projektu z ukrytymi plikami i folderami, zamiast tego jest tylko jeden folder na górze projektu; możesz rzucić wszystko i sklonować wszystko, co chcesz i połączyć je ponownie, że to po prostu działa.

Jeśli szukasz bezpłatnego i wsparcia dla zamkniętego źródła, rzuciłbym okiem na Visual Studio Online. Jest bezpłatny dla maksymalnie 5 programistów i bycie samemu ... cóż ... tak. To jest post 4 lata później, więc Twoja sytuacja prawdopodobnie się zmieniła, ale dla innych indywidualnych deweloperów szukających łatwej kontroli źródła VSO jest jednym z moich ulubionych wyborów, jeśli nie chcę ujawniać mojego kodu źródłowego. IIRC Github jest darmowy tylko dla rzeczy open source, ale ich ceny są bardzo tanie. Zarówno VSO, jak i Github bardzo dobrze integrują się z Visual Studio, jeśli tak się stanie, to twoje IDE.

Zawsze konfiguruję kontrolę źródła dla własnych projektów, z ciągłym środowiskiem integracyjnym, a także do budowania / uruchamiania testów jednostkowych / uruchamiania testów integracji za każdym razem, gdy się melduję. Dodatkowo, jeśli jest to aplikacja internetowa lub usługa Windows, mam to wdrażanie celów także. Zaoszczędziłem sobie niezliczone godziny debugowania i wdrażania przy użyciu tej metody i to nic w porównaniu z początkową konfiguracją.

Inną fajną cechą repozytoriów jest możliwość przeprowadzania bardzo ryzykownych eksperymentów / funkcji w innej branży. Jeśli to się uda, możesz scalić jako część głównego kodu. Jeśli tak się nie stanie lub zabraknie Ci czasu, możesz go porzucić (zapisać) i powrócić do głównego kodu z opcją powrotu do niego później bez zepsucia głównej bazy kodu.