git dla projektów osobistych (jednoosobowych). Przesada?

Znam i używam dwa systemy kontroli wersji: Subversion i git. Subversion na razie przyzwyczaja się do osobistych projektów, w których jestem jedynym programistą, a git przyzwyczaja się do projektów open source i projektów, w których, jak sądzę, inni również będą pracować nad projektem. Wynika to głównie z niesamowitych możliwości rozwidlania i łączenia git, w których każdy może pracować nad własnym oddziałem; bardzo przydatny.

Teraz używam Subversion do osobistych projektów, ponieważ myślę, że git nie ma tam sensu. To trochę przesada. Jest dla mnie OK, jeśli jest scentralizowany (zwykle na moim serwerze domowym), gdy jestem jedynym programistą; I tak robię regularne kopie zapasowe. Nie potrzebuję możliwości tworzenia własnego oddziału, główny oddział to mój oddział. Tak, SVN ma prostą obsługę rozgałęziania, ale myślę, że o wiele bardziej wydajne wsparcie nie ma sensu. Łączenie się może być z tym bólem, a przynajmniej z mojego małego doświadczenia.

Czy jest jakiś dobry powód, aby używać git do osobistych projektów, czy jest to po prostu przesada?

To nie jest przesada. Głównym powodem, dla którego zacząłem używać Git i Mercurial zamiast Subversion do osobistych projektów, jest to, że inicjowanie repozytorium jest o wiele łatwiejsze.

Chcesz rozpocząć nowy projekt?

> git init

BAM! Nie trzeba konfigurować serwera repozytorium ani sprawdzać struktury folderów w celu obsługi rozgałęzień i tagów w repozytorium subversion.

Udostępnianie projektu później to tylko kwestia: git push(innego niż zdalne repozytorium). Spróbuj zrobić to szybko z subversion!

Twierdziłbym, że używanie Subversion do lokalnych projektów osobistych jest przesadą, podczas gdy Git zdecydowanie nie. Git zajmie mniej miejsca (ze względu na nieefektywną koncepcję „rewizji” SVN w porównaniu do migawek obiektów Gita), wymaga mniejszej konfiguracji (w git initporównaniu z tuzinem svnadminpoleceń i ustawiania uprawnień itd.), Łatwiej jest wykonać kopię zapasową ( git clone --bare[lub git push originjeśli używasz Github lub podobny] i gotowe) i ma lepsze narzędzia do zarządzania kodem (rozgałęzianie jest bezpłatne, a łączenie jest łatwiejsze i czystsze). To, że nikt inny nie ma klonu twojego repozytorium, nie oznacza, że ​​korzyściami jakiegokolwiek DVCS są „nadmierne umiejętności”.

Ponadto powiedziałbym, że obsługa gałęzi Git jest mniej złożona niż SVN, z większymi nagrodami.

Myślenie, że nigdy nie rozgałęzisz własnego kodu, jest trochę krótkowzroczne. Kilka razy rozgałęziłem swój własny kod, szczególnie kiedy eksperymentowałem z nowym podejściem, o którym jeszcze nie byłem do końca przekonany. W końcu będziesz chciał tę funkcję.

To pochodzi od długiego użytkownika Subversion. Konsolidacja za pomocą jednego narzędzia może naprawdę ułatwić Ci życie.

Overkill jest zarezerwowany na wypadek, gdy wystąpią dodatkowe szkody spowodowane przez „rozwiązanie”. Użycie pistoletu do zabicia muchy oznacza, że ​​pocisk trafia w inne miejsce. To przesada. Używanie czegoś potężniejszego niż to konieczne, które nie powoduje problemu, nie jest przesadą i może być dobrą rzeczą, jeśli pomaga usprawnić proces programowania. Nie powoduje szkód i pozwala zaktualizować tylko jeden zestaw oprogramowania zamiast dwóch. Dlaczego więc zawracać sobie głowę dwoma systemami zamiast jednego?

Używam Gita do moich jednoosobowych projektów i uwielbiam to. Wcześniej korzystałem z Subversion i jeszcze nie widziałem wad korzystania z Git. Jest mocniejszy, ale nie w sposób, który komplikuje proste rzeczy. Tworzenie prostych rzeczy niepotrzebnie skomplikowanych / drogich / wolnych / itp. jest IMHO warunkiem koniecznym do nazwania czegoś przesadnym. Ponadto w Github rozwidliłem wcześniej projekty jednoosobowe innych osób, aby dodać pożądaną funkcję, a następnie wysłałem im prośby o ściągnięcie. Uważam, że to całkiem fajne, gdyby ktoś zainteresowany moimi projektami zrobił to samo.

Nigdy wcześniej nie korzystałem z kontroli źródła w osobistych projektach przed DVCS, więc trochę dziwne jest wyobrażanie sobie, że ktoś ma odmienne zdanie. Niektóre z moich powodów to:

• Łatwy w konfiguracji i zrywaniu. Na przykład kolega dał mi w zeszłym tygodniu łamigłówkę programistyczną, którą rozwiązałem w kilku małych krokach. Zrobiłem repozytorium git, które trwało 45 minut, aby zatrzymać moją pracę, a potem jej nie było. Nie wiem, jak łatwo jest coś takiego obalić, ale nigdy nie słyszałem o tym, żeby ktoś to robił.
• Bezładny. Dla mnie możliwość pracy offline jest znacznie bardziej korzystna dla projektu hobby niż dla pracy. Nie muszę wykopywać dziury w domowej zaporze ogniowej ani publicznie hostować projektu. Mogę tymczasowo umieścić repozytorium na pendrivie lub laptopie i nadal synchronizować wszystko.
• Wszystko się kolokowało. Posiadanie repozytorium i działającego drzewa ułatwia śledzenie małych projektów podczas aktualizacji systemu operacyjnego.
• Potężne funkcje. Jasne, nie potrzebuję mocy przez cały czas, ale jest tam, kiedy jej potrzebuję i nie zużywa żadnych zasobów, kiedy jej nie potrzebuję.

Powiedziano mi, że git-bisectnaprawdę miło jest znaleźć dokładne zatwierdzenie, które wprowadziło dane zachowanie, nawigując w przód / tył w zatwierdzeniach, w zależności od danych wejściowych.

Państwo będzie musiał zrobić kilka dni do rzeczy po prostu nie można dowiedzieć się, co się stało.

EDYCJA: Również możliwość rozgałęzienia jest bardzo ważna, gdy musisz robić poprawki błędów w starych wersjach, z których korzystają klienci. Musisz być w stanie zarządzać „po prostu napraw tę drobiazg, ale nie chcę najnowszej wersji, ponieważ nie chcę teraz testować od nowa”.

To zależy od tego, jak poważnie chcesz zająć się wersjonowaniem własnego kodu. Jeśli budujesz na przykład prostą bibliotekę, która zawsze będzie miała aktualną wersję (lub tak długo, jak to prawda), osobiście skorzystam z podstawowej opcji tworzenia kopii zapasowych, takiej jak Dropbox. Jeśli stracisz cały kod, możesz go odzyskać z Internetu, a Dropbox ma 30-dniową kopię zapasową wersji, jeśli naprawdę robisz coś głupiego.

Jednak jeśli na przykład potrzebujesz utrzymywać gałęzie produkcji i deweloperów, git jest absolutnie doskonałym narzędziem - i to o wiele szybszym niż svn. Jednak pamiętaj o ryzyku awarii dysku twardego, jeśli przechowujesz dane tylko lokalnie.

Zawsze, zawsze, zawsze używam systemu kontroli wersji dla każdego projektu deweloperskiego. Duże lub małe naprawdę nie ma znaczenia. Niezależnie od tego, czy gram w domu z jakąś nową technologią, piszę małego pomocnika, aby ułatwić sobie życie, czy pracuję zawodowo w dużym i rozproszonym zespole - zawsze chciałbym, aby system kontroli wersji wspierał mnie.

Oczywiście, przez większość czasu w małych projektach osobistych nie będziesz korzystać z większości funkcji, ale założenie repozytorium git (lub nawet lokalnego repozytorium Subversion) nie jest niczym wielkim, więc idź! I zanim się zorientujesz, będziesz chciał wiedzieć „cholera, jaka była zawartość pliku X w ostatni piątek?”. Bez kontroli wersji - powodzenia ;-)

Tak więc naprawdę nie ma znaczenia, czy używasz git czy SVN - osobiście zaczynam migrować coraz więcej rzeczy z SVN do git, ale najważniejsze jest w ogóle korzystanie z kontroli wersji - nawet w przypadku drobiazgów.

Tylko dlatego, że nikt o tym nie wspominał: w przypadku osobistych projektów darcs jest naprawdę dobry i mniej zaangażowany niż git do prostej kontroli wersji. Nie jest tak szybki w przypadku większych projektów, ale także Subversion!

Zrozumienie, że tym, co robimy, jest eksperymentowaniem. Posiadanie taniego / łatwego narzędzia do obsługi tego, zwiększa twoją zdolność do poruszania się do przodu, częściowo dlatego, że zwiększa twoją zdolność do wycofania się z dowolnego eksperymentu, gdy okaże się źle.

Wielu programistów mówi: Cóż, robię po prostu kopie mojego kodu. Ale kopie te stają się trudne do zarządzania i stają się bałaganem. Masz wiele kopii i nie pamiętasz, dla której z nich, a następnie spróbuj dowiedzieć się, kiedy można je bezpiecznie usunąć.

Wszystko to staje się jeszcze bardziej cenne, gdy eksperyment wymaga skoordynowanych zmian w wielu plikach. A gdy jest to solo, użycie Git staje się jeszcze prostsze.

Zamiast zastanawiać się, czy powinienem użyć go w solowym projekcie, teraz myślę, jaka szkoda, że ​​nie odkryłem tego wcześniej.