GIt/SVN podczas pracy samodzielnej

0

Szybkie pytanie - co sądzicie o używaniu tego typu narzędzi podczas samodzielnej pracy, do tego realizowanej na jednym kompie (odpada kwestia synchronizacji między kilkoma maszynami)?

Wiadomo, że w wypadku pracy zespołowej jest to praktycznie koniecznością, ale co w sytuacji, gdy piszecie coś sami?
Co sądzicie - warto, czy wprowadza to więcej zamieszania i jest tzw. "przerostem formy nad treścią"?

I nie chodzi mi o dyskusję odnośnie konkretnego rozwiązania (czyli prawdopodobnie udowadnianie wyższości Git'a nad CVS'em) ale ogólnie o podejście do tematu.

1

Używam gita nawet jak robie projekty żeby sie czegoś nauczyć. Przydaje sie chociażby jak np. chce wypróbować jakas inna biblioteke czy konktrukcje języka to wystarczy że cofne sie do wybranego commita i zrobie nowego brancha. Dodatkowo zawsze możesz eksperymentować z różnymi mechanizmami gita w pracy lokalnej i sie ich uczyć na nieco większym kodzie niż 2 - 3 pliki.

2

Jak coś co robie zajmie mi dłużej niż godzina czy 2 to zawsze używam gita No cóż, przede wszystkim git jest o wiele łatwiejszy w użyciu niż pendrive (bo rozumiem że autor robi kopie zapasowe) i robienia jakiś dziwnych folderów z wersjami, i nie wiem za bardzo dlaczego fakt że sam nad czymś pracuje sam miałby coś zmieniać.
A przerostem formy nad treścią jest stosowanie pendrive to trzymania kodu jak mamy dostęp do internetu oO

4

A ile razy się zdarzyło że cośtam chciałeś zmodyfikować i nagle wszystko przestało działać? ;)

2

Przy pierwszych własnych projektach używałam "dla sztuki" żeby się nauczyć posługiwać vcs-ami, teraz robię to z faktycznej potrzeby, by zawsze mieć możliwość powrotu do ostatniej działającej wersji.

3

Domniemywam, że działasz na Gicie/SVN-ie w pracy i chodzi Ci jedynie o użycie tego w domu. Myślę, że:

  1. Czasem, przy większych projektach warto, żeby ćwiczyć polecenia, których rzadko używa się w pracy.
  2. Łatwiej jest eksperymentować, jak wspomniał @Veox.
  3. Warto robić kopie zapasowe (zapezpieczać się przed przypadkami "losowymi"), jak wspomniał @scibi92.
  4. Warto zabezpieczać się przed sobą samym, jak wspomnieli @Shalom i @koffeina.
  5. Może Ci to pomóc czuć, że panujesz nad kodem/projektem, lub: pomagać śledzić, co dzieje się w projekcie – nieocenione, jeśli od pewnego stopnia wielkości projektu właśnie przez chaos nie chce Ci się już go ciągnąć.
  6. Może Ci to pomóc wrócić do własnej myśli – dlaczego wczoraj to coś zostało w ogóle zrobione? Lub: dlaczego w październiku 2017 zrobiłem to, a nie coś innego? A rzeczy, których w ogóle nie zrobiłeś (więc nie można opisać ich w commitach), możesz opisać na przykład w komentarzach.
0

@Silv:

  • odnośnie ćwiczenia to masz rację, ale mi nie chodziło o naukę/szlifowanie obsługi tego narzędzia, tylko o realne korzyści wynikające z jego stosowania (albo przerost zamieszania z nim związanego nad pożytkiem)
  • kopie zapasowe mogą się robić bez tego - np. jakiś google drive i synchronizacja katalogu projektu z chmurką
  • co do reszty - masz rację :D

W takim razie kolejne pytanie do tych, którzy używają Git/CVS "solo" - gdzie to trzymacie?
Lokalnie na kompie, na którym kodujecie? Na innej maszynie/serwerze ale w ramach LAN? Gdzieś zupełnie zdalnie?
Opcja pierwsza może ułatwić cofanie się do starszych wersji, ale nie zapewnia zabezpieczenia przed np. padem dysku.

1

Ja u siebie używam gita, żeby co jakiś czas robić "działającą wersje" do której potem mogę wrócić (aczkolwiek intelij chyba ma budowaną historię) i potem trzymam sobie ewentualnie to na jakimś githubie jako prywatne

1

Warto ale wymaga solidnej dyscypliny bo jak się pracuje samemu to ja mam Ttak, że chce mi się skakać z jednego taska na drugi i w jednym branchu robi się bałagan.
Każda istotna zmiana czy planowana funkcja czy sprawdzenie jakiegoś podejścia to nowy branch i ewentualny merge.

0

No to zapytam jeszcze raz (bo poprzednie pytanie gdzieś się zgubiło w tłoku innych postów).

Pytanie do tych, którzy używają Git/CVS "solo" - gdzie to trzymacie?
Lokalnie na kompie, na którym kodujecie? Na innej maszynie/serwerze ale w ramach LAN? Gdzieś zupełnie zdalnie?
Opcja pierwsza może ułatwić cofanie się do starszych wersji, ale nie zapewnia zabezpieczenia przed np. padem dysku.

1

Własny serwer deeykowany i Gitlab (może być darmowy). Na swoim serwerze mam Bonobo Git Serwer i miin. redmina (redmina głównie że względu na klientów, dość prosty i po polsku).

3

W takim razie kolejne pytanie do tych, którzy używają Git/CVS "solo" - gdzie to trzymacie?
Lokalnie na kompie, na którym kodujecie? Na innej maszynie/serwerze ale w ramach LAN? Gdzieś zupełnie zdalnie?
Opcja pierwsza może ułatwić cofanie się do starszych wersji, ale nie zapewnia zabezpieczenia przed np. padem dysku.

Przecież Git (w przeciwieństwie do CVS i SVN) jest z definicji „lokalnie na kompie”, więc nie wiem na czym ma polegać ułatwienie w cofaniu do starszych wersji…

I nie chodzi mi o dyskusję odnośnie konkretnego rozwiązania (czyli prawdopodobnie udowadnianie wyższości Git'a
nad CVS'em) ale ogólnie o podejście do tematu.

Ale to ma istotne znaczenie, bo widać że nie rozumiesz idei Gita.
Lokalnie na dysku masz całe repozytorium. Wszystkie branche, commity, całą historię. Możesz sobie skakać między wersjami, commitować, merdżować itp. a to cały czas dzieje się u ciebie na dysku.
W przypadku własnego, jednoosobowego projektu to tak naprawdę może już wystarczyć. Możesz mieć repozytorium zdalne gdzie tam chcesz, ale nie jest ono „serwerem”, jak to jest w Subversion, ale po prostu kopią tego co już masz na dysku.

Więc - w przypadku Gita - odpowiedzią na pytanie „gdzie to trzymacie?” jest: tak, lokalnie w każdym przypadku, bo Git jest przede wszystkim lokalny.

1

@cerrato: ja trzymam na githubie, większośc publicznie :) Taki mój "google drive" dla kodu ;)

3
cerrato napisał(a):

No to zapytam jeszcze raz (bo poprzednie pytanie gdzieś się zgubiło w tłoku innych postów).

Pytanie do tych, którzy używają Git/CVS "solo" - gdzie to trzymacie?
Lokalnie na kompie, na którym kodujecie? Na innej maszynie/serwerze ale w ramach LAN? Gdzieś zupełnie zdalnie?
Opcja pierwsza może ułatwić cofanie się do starszych wersji, ale nie zapewnia zabezpieczenia przed np. padem dysku.

Ja trzymam na VSTS. Pozwala mi to również na lepsze zarządzaniem projektem- jeśli pomyślę o czymś co trzeba zrobić czy zauważę buga to wrzucam to szybko na tablice i mam listę rzeczy do zrobienia.

3
cerrato napisał(a):

Wiadomo, że w wypadku pracy zespołowej jest to praktycznie koniecznością

Gdyby tak było, systemy te nazywałyby się raczej systemem pracy zespołowej, a nie kontroli wersji.

Co sądzicie - warto, czy wprowadza to więcej zamieszania i jest tzw. "przerostem formy nad treścią"?

Korzystanie z undo/redo? Dlaczego miałoby być przerostem?

cerrato napisał(a):

Lokalnie na kompie, na którym kodujecie? Na innej maszynie/serwerze ale w ramach LAN? Gdzieś zupełnie zdalnie?
Opcja pierwsza może ułatwić cofanie się do starszych wersji, ale nie zapewnia zabezpieczenia przed np. padem dysku.

Lokalnie - bo tak działa Git. Niektóre repozytoria co jakiś czas wypycham zmiany do GH/BB. Do tego codziennie robi mi się backup moich danych na NAS, więc w razie padu laptopa odzyskam wszystkie repozytoria, nie tylko te, które mam zdalnie.

0
Azarien napisał(a):

Przecież Git (w przeciwieństwie do CVS i SVN) jest z definicji „lokalnie na kompie”, więc nie wiem na czym ma polegać ułatwienie w cofaniu do starszych wersji…

Nie chodzi o to, gdzie fizycznie znajdują się pliki, a o to, że mogę sobie zrobić taga, do którego można wrócić, albo jak zepsuję coś, co działało jeszcze przed chwilą, to mogę kliknąć "Revert" i przywróci mi wszystko do działającej wersji, mam opisane co robiłem, co zmieniałem, z komentarzami i zawsze mogę do tego wrócić.

Rozumiem, że jak lokalnie, to wolisz robić kopie plików samodzielnie. No co kto lubi.

0

@ceratto: nie zabezpiecza przed awarią dysku jak nie stosujesz żadnego zdalnego repo :)

1

GIt/SVN podczas pracy samodzielnej

Wygodne rozwiązanie jeżeli chce się gdzieś przechowywać backup i historię zmian w kodzie. Trzeba tylko pamiętać, że GitHub jest publicznie dostępny dla każdego i raczej nie powinny znaleźć się tam bardziej intymne informacje o autorze przechowywanej zawartości. Sam w ten sposób używam GitHub'a, nie zważając na jakieś super, hiper ficzery samego gita i jest w porządku.

Poza tym mogę wszędzie na świecie popatrzeć w swój kod i kiedy potrzebuję coś z niego wykorzystać to nie ma problemu.
Backup całościowych danych z dysku to już naturalnie inna para kaloszy.

EDIT: aha, w wątku mowa była o samym tylko gicie ale niech już to zostanie.

1

ZAWSZE DO WSZYSTKIEGO :) używam gita (od paru lat [wcześniej króciutko był SVN]), repozytorium mam zawsze -- oprócz lokalnego, oczywiście -- na swoim serwerze, więc mam automatyczną kopię zapasową i kilka razy ratowało mi to tyłek. Poza tym zdarza mi się pracować -- nawet jeśli samodzielnie -- na różnych maszynach (git wtedy jest niezastąpiony), a poza tym git też jest świetny do udostępniania kodu (np. banalnie przez http, jako git over dumb http).

4

chodzi mi o całe "zamieszanie" związane z commitami,

Jak mi się nie chce i pracuję nad czymś, co i tak nie ujrzy światła dziennego i tak nie wrzucę na GH), to czasem robię po prostu git commit -a -m ":)" i w logu mam ileś commitów :).

Oczywiście staram się w miarę możliwości dawać sensowne opisy commitów (nawet programując w pojedynkę opłaca się mieć porządek, szczególnie, że część z tego co sobie robię, wrzucam na Githuba, co fajniejsze projekty), ale jednak przyznaję się - zdarza mi się pisać :).

Ale opis commitu to tylko opis, ważniejsze jest, że możesz sobie podglądnąć co kiedy robiłeś. I nie tylko chodzi o cofanie się w czasie ale również na panowanie nad tym, co aktualnie robisz. git diff przed commitem pozwala na taki mały code review tego co naprodukowałeś przez ostatnie kilka godzin. Wiesz, które pliki były ruszane i co w nich zmieniałeś, czy może jakieś pozostałości debugowania zostały itp.

Podobnie git show pozwala na podejrzenie poprzednich commitów. Dosiadasz do projektu po miesiącu, gubisz kontekst, ale piszesz git show -5 i masz 5 ostatnich commitów (niektórzy używają jakiegoś GUI do Gita i wyklikują to, ale to tylko kwestia interfejsu).

Nie mówiąc już o jakichś sytuacjach awaryjnych typu spieprzyłeś niechcący coś w kodzie albo dokonujesz dużej refaktoryzacji i cóż, nie udało ci się, testy nie przechodzą (albo w ogóle nie zostały napisane), na dodatek po przemyśleniu architektury uważasz, że cały pomysł na refaktoryzację był do d**y... Wtedy Git to zbawienie.

Poza tym Git pozwala na wyrzucanie niepotrzebnego kodu bez skrupułów. Zbędny komentarz? To usuwasz. Git i tak to będzie pamiętał. Kod - eksperyment, który był tylko do połowy udany i trzeba go wyrzucić. Ale szkoda wyrzucać całkowicie, bo może ci się jeszcze przydać? To wydzielasz nową gałąź, commitujesz ten kod do gałęzi i nie musisz tego mieć w masterze.

Tak więc nawet programując samemu mamy zysk.

0

Jednym z rozwiązań jest mieć dysk sieciowy czy choćby jakieś Raspberry Pi włączone cały czas w LANie i tam pushować Gitem.

1 użytkowników online, w tym zalogowanych: 0, gości: 1