Projekt który mógłbym zamieścić w CV - czy koniecznie korzystać z githuba od zaraz?

Jak od 3 postów na mikroblogu obwieszczam wszem i wobec, siedzę od kilku miesięcy nad projektem własnej gry. I myślę sobie, że gdyby udało mi się ją doprowadzić do jako takiego stanu, to można by ją (w końcu) opublikować na GitHubie i zamieścić w CV.

Jest jeden problem. Nie korzystam z GitHuba. Piszę to sobie lokalnie na dysku.

Dlaczego? Cóż, z różnymi gitami, svn-ami, GitHubami, BitBucketami, i innymi podobnymi pomysłami jak dotąd miałem tylko wtedy do czynienia, gdy projekt na studiach miał taki wymóg, albo gdy projekt był grupowy i inaczej trudno byłoby koordynować pracę (a nawet wtedy przynajmniej raz przypominam sobie sytuację, gdy cała koordynacja i przesyłanie sobie nawzajem kodu odbywało się przez tasiemcowe e-maile).

Szczerze mówiąc... Nawet gdy do repozytoriów byłem zmuszany... tak długo, jak długo pisałem sam, jakoś nie widziałem zalet z korzystania ich ponad staromodne edytowanie plików na dysku. Repozytoria mi się overkillem i niewygodą. Ani razu nie zdarzyło mi się przeglądać poprzednich commitów w poszukiwaniu starych fragmentów kodu - zamiast tego kod, który przewidywałem, że może się później przydać, zakomentowywałem i później usuwałem. Ani razu nie odczułem potrzeby wydzielania branchów i tym podobnych.

Dlatego pomyślałem, że dopóki robię tę grę sam dla siebie, dopóty pozwolę sobie nie korzystać z żadnego repo i po prostu trzymać na dysku w 1 wersji. Mam dwie kopie zapasowe na pendrive i dysku wymiennym na wszelki wypadek. Na GitHuba wsadzę całość, gdy będzie to miało sens: czyli albo gdy grę opublikuję razem z kodem źródłowym (wtedy ktoś mógłby tam zgłaszać mi bugi albo - jeślibym miał dużo szczęścia - nawet patche), albo gdy po prostu będę chciał zamieścić grę w CV celem szukania pracy - to mogę dać link do GitHuba.

I tak dorobiłem się już paruset kilobajtów samego własnego kodu. Poprzednich wersji nie mam, oprócz tej jednej, którą wysłałem wykładowcy, by zaliczyć przedmiot.

Ale tu jest moja wątpliwość. No bo tak - daję ew. pracodawcy linka do githuba, gdzie jest w zasadzie tylko jeden commit - z całym projektem. I tu moje pytanie, czy to ma duże znaczenie? Czy, jeśli mam nadzieję zamieścić to kiedyś w CV, to dla jakiś przyczyn naprawdę powinienem zmusić się do rozwijania tego dalej na githubie od zaraz? Czy może mieć to jakikolwiek wpływ na odbiór tego projektu?

Jeżeli gra jest w późniejszym stadium rozwoju, to możesz nakręcić krótki filmik, utworzyć stronę danego projektu czy coś. Opcji jest dużo, nie musisz ograniczać się tylko do githuba. Ot, nie każdy chce mieć swój kod upubliczniony.

kmph napisał(a):

Jak od 3 postów na mikroblogu obwieszczam wszem i wobec, siedzę od kilku miesięcy nad projektem własnej gry. I myślę sobie, że gdyby udało mi się ją doprowadzić do jako takiego stanu, to można by ją (w końcu) opublikować na GitHubie i zamieścić w CV.

Wreszcie ktoś, kto nie rżnie głupa z TODO-list :)

Jest jeden problem. Nie korzystam z GitHuba. Piszę to sobie lokalnie na dysku.

Zgadnij co się stanie, jeśli Twój dysk nagle padnie. A to się niestety zdarza.

Dlaczego? Cóż, z różnymi gitami, svn-ami, GitHubami, BitBucketami, i innymi podobnymi pomysłami jak dotąd miałem tylko wtedy do czynienia, gdy projekt na studiach miał taki wymóg, albo gdy projekt był grupowy i inaczej trudno byłoby koordynować pracę (a nawet wtedy przynajmniej raz przypominam sobie sytuację, gdy cała koordynacja i przesyłanie sobie nawzajem kodu odbywało się przez tasiemcowe e-maile).

Pójdziesz do pracy i to będzie codzienność. Nikt Ci nie każe używać gita tylko po to, by zrobić Ci na złość, naprawdę :)

Szczerze mówiąc... Nawet gdy do repozytoriów byłem zmuszany... tak długo, jak długo pisałem sam, jakoś nie widziałem zalet z korzystania ich ponad staromodne edytowanie plików na dysku. Repozytoria mi się overkillem i niewygodą. Ani razu nie zdarzyło mi się przeglądać poprzednich commitów w poszukiwaniu starych fragmentów kodu - zamiast tego kod, który przewidywałem, że może się później przydać, zakomentowywałem i później usuwałem. Ani razu nie odczułem potrzeby wydzielania branchów i tym podobnych.

Zaleta jest taka, że jak już spali Ci się dysk, możesz ściągnąć ostatnią wersję ze swojego repozytorium i pracować dalej, jak gdyby nic się nie stało. Nie musisz też zaśmiecać sobie kodu miliardem zakomentowanych linijek i potem zgadywać, która z którą współgrała i co odkomentować, żeby robiło to, co wcześniej. Odstawisz projekt na miesiąc, bo sesja, i będziesz mieć zagwozdkę. Choćbyś nawet cisnął na masterze, rób sobie co jakiś czas commita. Ukończysz jakiś kawałek dzieła (choćby to było robocze ukończenie) - pyk, commit. Najwyżej zrobisz squasha jak będzie tego za dużo.

Dlatego pomyślałem, że dopóki robię tę grę sam dla siebie, dopóty pozwolę sobie nie korzystać z żadnego repo i po prostu trzymać na dysku w 1 wersji. Mam dwie kopie zapasowe na pendrive i dysku wymiennym na wszelki wypadek. Na GitHuba wsadzę całość, gdy będzie to miało sens: czyli albo gdy grę opublikuję razem z kodem źródłowym (wtedy ktoś mógłby tam zgłaszać mi bugi albo - jeślibym miał dużo szczęścia - nawet patche), albo gdy po prostu będę chciał zamieścić grę w CV celem szukania pracy - to mogę dać link do GitHuba.

I tak dorobiłem się już paruset kilobajtów samego własnego kodu. Poprzednich wersji nie mam, oprócz tej jednej, którą wysłałem wykładowcy, by zaliczyć przedmiot.

Ale tu jest moja wątpliwość. No bo tak - daję ew. pracodawcy linka do githuba, gdzie jest w zasadzie tylko jeden commit - z całym projektem. I tu moje pytanie, czy to ma duże znaczenie? Czy, jeśli mam nadzieję zamieścić to kiedyś w CV, to dla jakiś przyczyn naprawdę powinienem zmusić się do rozwijania tego dalej na githubie od zaraz? Czy może mieć to jakikolwiek wpływ na odbiór tego projektu?

Pracodawca widzi Twój projekt z jednym, jedyniusieńkim commitem który jest Twoim gotowym projektem. Może wyciągnąć dwa niezbyt przyjemne wnioski:

1. nie umiesz prawidłowo korzystać z gita, może być z Tobą problem przy pracy grupowej
2. skąd ma wiedzieć, że cały ten kod jest Twój? Równie dobrze mogłeś odkupić projekt od kolegi i sobie wrzucić. Nie widać tego, jak nad nim pracowałeś

Jak nie chcesz pokazywać ludziom tego projektu, zanim nie uznasz go za gotowy, załóż prywatne repo. Na BitBucket są darmowe, na GitHub niby trzeba płacić, ale ponoć studenci mogą zrobić tak, by za nie nie musieć płacić. Ale jak masz to gdzieś, śmiało wrzucaj do publicznego repo, jeszcze jakiś zbłąkany rekruter się odezwie. Jak uznasz, że jesteś na to gotowy, oznaczysz release, upublicznisz repozytorium i voila.

Konieczne to nie jest, ale pokazujesz że nie chcesz ogarnąć/nie ogarniasz jednego narzędzia które jest wspólne dla większości programistów, niezależnie od technologii.

Narzut używania gita przy pracy jednoosobowej jest w zasadzie zerowy, a masz zalety typu snapshotowanie pracy, możliwość równoległego rozwijania niezwiązanych ficzerów (np jak już nie chce ci się pisać czegoś trudnego to w 5 sekund przełączasz się na pracę nad czymś innym). Prawdopodobnie nigdy nie wyczuwałeś potrzeby wydzielania branchów i odczuwałeś niechęć z uwagi na to że nigdy faktycznie nie nauczyłeś się z tego wydajnie korzystać. Podobnie jak zapewne nie masz żadnego rodzaju testów bo też nie czujesz potrzeby korzystania z nich.

Repozytoria są niewygodą i overkillem? To rozumiem że szukanie pendrive, ogarnianie na którym jest aktualna wersja a na którym nie. usuwanie starej wersji, dodawanie nowej nie jest overkillem? xD Prychłem dość mocno. No i powodzenia gdy przy kasowaniu starej wersji przez przypadek skasujesz prawidłową. No i to jest podstawowe narzędzie które używa 80-90% programistów. Nie wiem, może to kwestia przyzwyczajenia ale ja nie potrafiłbym klepać przez używania gita, chyba że to jakieś g*wno demo które można napisac w godzine :D

EDIT: ja na przykład dosyć często korzystam z opcji git checkout -- path jak klepie kod samemu

brak repo jest sexy przy małych projektach, przy większych już ciężko zapanować, oczywiście nikt nie broni pakować zipem i robić kopie na SD czy chmurze, wiadomo

No to może jesteś bogiem programowania. Kilka razy tak napsułem w kodzie, że bez git checkout straciłbym pół dnia na odkręcenie syfu, który narobiłem

Czepiacie się. Gość jest po prostu początkujący skoro nie widzi zalet gita nawet w projekcie prowadzonym samodzielnie. To niedobrze o nim świadczy ale to plus dla pracodawcy, że od razu widzi, że gość nie ogarnia pewnych aspektów

Jeśli nie oczekujesz, że komuś w przyszłości przyda się twój kod, to wrzucanie na pokaz kodu na Gita jest wg mnie bez sensu.
Zrób sobie jednak prywatne na repo na gitlabie i co jakiś czas commituj jako backup.
Wrzuć grę na Google Play lub Windows Store w zależności czy robisz grę mobilną czy PC i w CV dawaj linki.
Dostarczenie działającego oprogramowania to raczej większy plus, niż wrzucanie jakiegoś kodu, którego nikt w 5 minut nie zweryfikuje czy w ogóle działa.

Normalny człowiek po odkryciu Gita doznaje olśnienia i czuje, że to najlepsze co ludzkość wymyśliła od czasów kolorowania i podpowiadania składni. Ba, ludzie zaczynają używać Gita do pisania prac naukowych, dokumentów, backupu excela itd, bo to tak przydatne i uniwersalne narzędzie. A Ty dalej wolisz zipy. No cóż.

Twoje problemy z gitem wydają się być związane głównie z tym, że go nie znasz, i używałeś go dotąd nieumiejętnie.
By umiejętnie używać gita, trzeba niestety najpierw przejść przez stromą krzywą uczenia się gita. Warto.
Najlepiej zrobić to przy prywatnym projekcie i dodać git do CV.
Korzystanie z gita jest szybkie i tanie. Kiedy, już się gita pozna, to na podstawowe operacje poświęca się 0 czasu, szczególnie w jedno osobowym projektach.

W każdym prywatnym jednoosobowym projekcie na bitbucket mam repozytorium i tworzę branche, na każdy feature, który implementuje. Mam też skonfigurowany CI z automatycznymi buildami i testami. Wystarczy zrobić to dobrze raz - i przy każdym kolejnym projekcie i projekciku będziemy wiedzieli jak zrobić to szybko.

Zakomentowany kod to zły nawyk i powinien być tępiony.

@kmph: jak kolega powyżej napisał, git na początku może być ciężki, jest to narzędzie o wielkich możliwościach więc wymaga czasu ale zdecydowanie warto. Pomyśl o tym że prędzej czy później będziesz musiał się nauczyć, jak nie teraz to w pracy. Tylko że teraz jak coś odpie*** z repo to najwyżej stracisz swoje zmiany, a jak odwalisz coś w pracy i do tego w okresie próbnym to może być gorzej. Nie musisz uczyć się wszystkiego, ale chodzi o to żebyś wiedział co to commity, jak są powiązane, co to HEAD, jak działają branche, czym się różni merge od rebase i kojarzył git reset. Bo lepiej nauczyć się robić git reset na jakimś tutorialikowym kursie niż dokonać dzieła zniszczenia w firmie :D
Jak piszesz sam aplikacje to większość komend będzie taka:
git add
git commit (+ opcje)
git push
git checkout (+ opcje)
git checkout -- path
Więc wielki ból to nie będzie

Lol. 2018 rok a ludzie nadal korzystają z konsoli zamiast wbudowanego GUI w IDE

@kmph: właśnie się ogarnąłem że niepotrzebnie jedne plik w projekcie skasowałem. Ech, jak to dobrze że tego gita mam, co ja bym teraz zrobił :)

No toście mnie przekonali.

Wstawiłem do repo. Na visualstudio.com, bo Visual Studio od razu mi gui na to dawał, a nie chciało mi się czytać jak integrować z bitbucket.

Niestety, jak głupi wpierw założyłem repo na visualstudio.com, więc potem nie do końca wiedziałem, jak to połączyć z tym, co mam na dysku.

Starą wersję (tą, którą 2 mce temu oddałem wykładowcy) dałem na master, aktualny stan projektu dałem do gałęzi dev.

Niestety, żeby to uzyskać, to zeszło mi całkiem sporo czasu na klikanie na ślepo po Visualowym GUI, na zasadzie "a może jak kliknę tu to zadziała"... Jak (wreszcie) połączyłem starą wersję z repo, to nie wiedziałem jak połączyć nowszą, bo mi wyrzucało błędy, więc w końcu na chama pliki przekopiowałem.

Cała ta zabawa zajęła mi akurat tyle czasu, ile dzisiaj miałem na robotę ;/ No, ale to tylko raz jest do zrobienia, a poza tym już mniej więcej pamiętam, co w końcu należało zrobić.

Teraz zobaczymy, jak pójdzie dalej praca w ten sposób.