Projekt rekrutacyjny w jednym commicie

Hej,
Ostatnio mam dużą chęć na tworzenie projektów i uczenie się nowych bibliotek Pythona, np. BeautifulSoup i inne. Moje pytanie dotyczy commitowania projektów do repozytorium zdalnego. Otóż nie mam wyrobionego nawyku commitowania, wolę przesłać już gotowy działający projekt, szczególnie jeżeli jest to coś na 2 - 3 dni kodzenia. Projekty robię sobie hobbystycznie. Nie ukrywam jednak, że przydadzą mi się w rekrutacji gdy będę szukał nowej pracy, bardziej ukierunkowanej na programowanie.

I tutaj moje pytanie: czy wrzucenie całego, gotowego projektu na GitHuba, w pierwszym commicie, skreśla go w oczach rekrutera? Mówię o raczej małym projekcie na 250 linijek kodu.

Mam taki już gotowy projekt i zastanawiam się, jak powinienem go zaprezentować. Czy podzielić go na części (funkcje itp.) i "sztucznie" wrzucać kawałkami, codziennie na GitHuba, tak żeby było widać progres projektu? Wiem, że to głupie i "udawane", ale nie wiem co z takim gotowym projektem zrobić.

Mam opory przed pokazywaniem kodu, który nie jest idealny, który może się jeszcze prawie w całości zmienić. Dlatego nie robię commitów.

Będę wdzięczny za opinię na ten temat. Wiem, że mogłem kogoś tematem rozśmieszyć, ale naprawdę rzadko używam githuba, i chciałbym to zmienić i wyrobić sobie jakieś dobre nawyki.

Nie skreśla.
Ale pokazywanie jak poprawiasz kod to jest akurat zaleta.
Wszyscy zwykle tworzymy w pierwszym podejściu kupę, która dopiero potem zamienia się w znośne jako tako.

Tym niemniej zupełnie Cię rozumiem - też nie lubię jak inni widzą jak się męcze z programowaniem :-)
Na razie daruj sobie nawyki i wrzucaj jak Ci pasuje.

Excelowiec napisał(a):

czy wrzucenie całego, gotowego projektu na GitHuba, w pierwszym commicie, skreśla go w oczach rekrutera? Mówię o raczej małym projekcie na 250 linijek kodu.

99% rekruterów w odwłoku ma czyjegokolwiek GitHuba.

Mam opory przed pokazywaniem kodu, który nie jest idealny, który może
się jeszcze prawie w całości zmienić. Dlatego nie robię commitów.

Nie myśl o tym w kategorii "pokazywania komuś kodu", tylko w kategorii dokonanych zmian. Gdy rozwijasz swój projekt, masz zapewne w głowie jakąś listę rzeczy do zrobienia - możesz po prostu robić commit za każdym razem, gdy coś w tej mentalnej liście zaznaczasz jako "zrobione". Dla mnie osobiście nieocenionym dobrodziejstwem gita jest to, że jak mam zrobione commity, to mogę grzebać w kodzie, eksperymentować i robić tam nie wiadomo jaki smród - ale wystarczy git reset --hard i cały kod jest z powrotem w stanie z ostatniego commita i mogę zacząć kombinować na czysto, od nowa.

Czy [...] wrzucać kawałkami, codziennie na GitHuba,

Commity możesz przecież robić lokalnie i dopiero na koniec wrzucić całość. Poza tym, zawsze możesz użyć git rebase --interactive, żeby zmienić historię, np. zbierając kilka małych commitów i łącząc je w jeden większy.

Nic nie stracisz, ale nie zapunktujesz przez pokazanie np TDD

Excelowiec napisał(a):

Hej,
Ostatnio mam dużą chęć na tworzenie projektów i uczenie się nowych bibliotek Pythona, np. BeautifulSoup i inne. Moje pytanie dotyczy commitowania projektów do repozytorium zdalnego. Otóż nie mam wyrobionego nawyku commitowania, wolę przesłać już gotowy działający projekt, szczególnie jeżeli jest to coś na 2 - 3 dni kodzenia. Projekty robię sobie hobbystycznie. Nie ukrywam jednak, że przydadzą mi się w rekrutacji gdy będę szukał nowej pracy, bardziej ukierunkowanej na programowanie.

I tutaj moje pytanie: czy wrzucenie całego, gotowego projektu na GitHuba, w pierwszym commicie, skreśla go w oczach rekrutera? Mówię o raczej małym projekcie na 250 linijek kodu.

Raczej nie skreśla.

Jak to mu powiesz Otóż nie mam wyrobionego nawyku commitowania to Cię może skreślić, ale sam projekt, zwłaszcza rekrutacyjny, w jednym commicie Cię nie skreśli. Podejście które reprezentujesz (jeśli dasz po sobie poznać) owszem.

Mam taki już gotowy projekt i zastanawiam się, jak powinienem go zaprezentować. Czy podzielić go na części (funkcje itp.) i "sztucznie" wrzucać kawałkami, codziennie na GitHuba, tak żeby było widać progres projektu? Wiem, że to głupie i "udawane", ale nie wiem co z takim gotowym projektem zrobić.

Jak masz w jednym commicie, to wyślij w jednym commicie.

Podczas pracy powinieneś je dzielić - ale jak mówiłeś, nie masz tego "nawyku". Więc od poprawienia tego "nawyku" zacznij.

Ewentualnie, jak juz masz gotowy projekt, to możesz z niego powyciągać z niego commity, ale nie musisz czekać dni pomiędzy nimi - po prostu zacommituj je od razu. Częstotliwośc tych commitów nie ma znaczenia - znaczenie ma co w nich zmieniasz, jakie mają nazwy, oraz czy są od siebie oddzielone (jeden commit od drugiego) w miare "normalnie", tam gdzie to ma sens, czy po prostu randomowo wrzucasz pliki.

Każdy commit powinno się dać osobno uruchomić i przetestować.

Mam opory przed pokazywaniem kodu, który nie jest idealny, który może się jeszcze prawie w całości zmienić. Dlatego nie robię commitów.

To czemu piszesz taki kod? Zrób jeden początkowy MVC który jest w miare dobry, i dopiero jak to zrobisz, commit, i zacznij pracę nad następnym.

Chyba że masz podejście: "zrobie największy shit jaki jest początkowo, i potem fixuję" - jeśli tak, to od tego musisz zacząć.

Robienie całego projektu w jednym commicie to musi być niesamowita męczarnia i kupa straconego czasu.

Excelowiec napisał(a):

Mam opory przed pokazywaniem kodu, który nie jest idealny, który może się jeszcze prawie w całości zmienić. Dlatego nie robię commitów.

I właśnie w dwóch zdaniach podważyłeś cały sens istnienia Gita.

Gdyby ludzie wrzucali tylko idealny kod, który nigdy się nie zmieni, to nikt by Gita nie używał, bo nie byłoby po co. Wtedy ludzie by po prostu mieli jakiś folder w sieci, do którego programiści by dogrywali kolejne pliki z kodem (które nigdy już nie zostałyby zmienione, bo przecież byłyby tak idealne, że nie byłoby potrzeby ich zmieniać).

I tutaj moje pytanie: czy wrzucenie całego, gotowego projektu na GitHuba, w pierwszym commicie, (...)`

Nie jest to dobra praktyka, ale powszechna. Zobacz sobie na popularne projekty open source, wiele z nich ma na początku "initial commit", a tam np. z kilkaset do kilku tysiecy linijek kodu wrzuconych na początek.

Ogólnie nie ma co się spinać. Myślę, że zrobiło się nieporozumienie, że Github to ma być portfolio dla rekruterów, podczas gdy w rzeczywistości GH częściej przypomina piaskownicę/obszar roboczy.

Mam taki już gotowy projekt i zastanawiam się, jak powinienem go zaprezentować. Czy podzielić go na części (funkcje itp.) i "sztucznie" wrzucać kawałkami, codziennie na GitHuba, tak żeby było widać progres projektu? Wiem, że to głupie i "udawane", ale nie wiem co z takim gotowym projektem zrobić.

po prostu git add plik i dodajesz kolejne pliki (albo nawet git add -p plik żeby dodać poszczególne linijki kodu w konkretnym pliku, zamiast całego od razu), potem git commit -m "opis commita".

A potem brać następne pliki (niekoniecznie 1 plik = 1 commit, raczej chodzi o wydzielenie logicznych całości) i robić w ten sposób kolejne commity. I tym sposobem z dużej ilości niezacommitowanego kodu będziesz mieć ładnie porobione commity.

Tylko całość może trwać z 10 minut, po co robić to kilka dni? Bez sensu. Jest cienka granica między robieniem czegoś po to, żeby było elegancko/czytelnie/praktycznie (oddzielne commity), a robieniem czegoś na pokaz (udawanie, że wrzucałeś te commity na żywo).

Dodam coś od siebie z perspektywy technicznego rekrutera juniorów - jeśli w Githubie masz same małe projekty to wiele to nie znaczy, ale jak masz jeden konkretny to już lepiej. Problem z małymi projektami jest taki, że mają zupełnie inne problemy niż duże. Jak masz duży to pokazujesz swoje prawdziwe umiejętności i to, że masz umiejętności potrzebne do odnajdywania się w takowych. Idealnie jakbyś jeszcze miał demo na necie