(Pytanie?) do samouków i przekwalifikowanych.
Wysyłacie CV z długą listą znanych technologii i super projekt który w pocie czoła robiliście na GitHubie. Wszystko robi wrażenie, projekt wypasiony i CV. Najbardziej powala z nóg kiedy taki projekt robicie z kopa bez jednego błędu i prób kodu. Wow!
Jesteście pewni, że powinniście go wysyłać do repozytorium z tagiem Initial commit?
Najbardziej powala z nóg kiedy taki projekt robicie z kopa bez jednego błędu i prób kodu
To całkiem zbyteczne. Poza tym mało osób tak potrafi ("Nobody actually creates perfect code the first time around, except me. But there's only one of me." Linus Torvalds). Nie ma nic złego w próbowaniu wielu podejść, zanim się zrobi dobrze (mój ulubiony przykład to Angular - goście od Google cały framework zrobili na próbę, żeby potem dopiero zrobić od nowa dwójkę na czysto). Innymi słowy chcesz być lepszy od programistów Google, a to całkiem zbyteczne.
Poza tym próby i eksperymentowanie jest fajne, bardziej fajne moim zdaniem niż zrobienie czegoś od początku do końca i już.
bez jednego błędu
Bugów się nie uniknie i tak. Jeśli nie masz bugów, to zwykle znaczy, że z projektu nikt nie korzysta, i nie miał kto ich wykryć.
Jesteście pewni, że powinniście go wysyłać do repozytorium z tagiem Initial commit?
Nie rozumiem, przecież robiłeś chyba jakieś commity w trakcie?
Normalnie (i najbardziej elegancko) się pracuje tak, że puszcza się małe commity do Gita, i wtedy nie ma jednego dużego "initial commit", tylko jest ileś commitów i niewielkie postępy.
Jeden wielki initial commit kojarzy mi się z projektami, które zostały wydzielone z innego projektu, i jest to brzydkie (chociaż możliwe, że czasem jest to konieczność).
Część projektów może pochodzić z czasów zanim zaczęło się używać gita. Wtedy nie ma za bardzo wyjścia, bo niby jak inaczej go wrzucić niż przez jeden commit? No chyba że ktoś używa gita na zasadzie magazynu danych, a nie systemu kontroli wersji, to wtedy zgoda.
Dlatego właśnie czasem jest to najprostsze rozwiązanie wrzucić wszystko razem, mimo, że mniej eleganckie niż małe commity (chociaż też czasem można powoli dodawać kolejne pliki i robić po fakcie commity (można nawet git add -p i dodawać fragmenty plików), tylko też trzeba się zastanowić czy w danym przypadku ma to sens, czy nie lepiej nie chrzanić się i wrzucić czegoś na pałę. Developerka nie jest nigdy idealna)
Chyba chodzi o to czemu jeden commit zamiast po prostu fork ze źródła ;)
Ironia napisał(a):
Chyba chodzi o to czemu jeden commit zamiast po prostu fork ze źródła ;)
jakaś sfrustrowana HRstytutka wylała żale, a wy się podniecacie
Część projektów pochodzi z czasów, gdy nie używałem jeszcze kontroli wersji, a w przypadku części z nich wolę nie ujawniać antycznej historii*. Wtedy na początku faktycznie będzie wielki pierwszy commit (ale zazwyczaj nie "Initial commit", tylko np. "Release v.1.0 (YYYY-MM-DD)"), a potem już normalnie.
*Przykład: tworzę grę. Na początku używam w niej zasobów pożyczonych z innej gry, potem dopiero robię jakieś własne assety albo robię własne. Nie mogę upublicznić całego repo, bo wtedy rozpowszechniałbym wspomniane pożyczone zasoby, do których nie mam praw. Mam zatem dwie opcje:
a) Przechodzę przez całą historię repo i edytuję commity z zasobami, usuwając problematyczne rzeczy
b) Po prostu biorę ostateczną wersję projektu i pakuję jako nowe repozytorium z 1 commitem
Opcja b) jest jednak dużo szybsza i prostsza.