GIT - commit -m vs commit -am

[MamPytanie]

Witajcie - google'owałem odpowiedzi na to pytanie, ale nie rozumiem. Jestem absolutnie początkującym w programowaniu.

 commit -m vs commit -am. Tylko tak bardzo łopatologicznie, bo jestem jakiś odporny na wiedzę w tym temacie chyba 

[gnysek]

git commit -am

 

zrobi to samo co

 

git add *

git commit -m

 

Polecam: https://explainshell.com/explain?cmd=git+commit+-am (chociaż z tamtego opisu akurat nie wynika to co napisałem). No i to akurat nie jest programowanie

[MamPytanie]

Właśnie tak to zrozumiałem, ale gość w filmiku mówił inaczej. Do tego zapytałem go na priv to twierdzi, że jest inaczej. Uczy programować i sam nie wie? Przez ten jego kurs to mam wrażenie, że mam więcej złych informacji niż dobrych. Od trzech dni nie umiem zrozumieć GIT. Znacie coś dobrego od A do Z o GIT, żebym przygotował się do pierwszej pracy po polsku za darmo? Po angielsku też bym pewnie zrozumiał mniej więcej, ale chciałbym wszystko maksymalnie dobrze zrozumieć. Jest tego mnóstwo na YT, ale jak widać można stracić parę dni na nie warty uwagi kurs

[gnysek]

Ja korzystam tylko z wizualnej wersji gita w Jetbrainsowych produktach, czasem tylko do tworzenia branchy z terminala daję "git checkout -b nazwabrancha", albo jak trzeba zrobić reset (czego nie potrafie zapamiętać i zawsze kopiuję ze stackoverflow). W sumie do gita za duzo nie trzeba znać, push, fetch, commit i jakoś się żyje

[Chell]

koleś dobrze mówi, proszę nie obrażać ludzi którzy chcą nam pomóc ale ich nie rozumiemy. pliki dzielą się na tracked i untracked. Wszelkie modyfikacje już istniejących plików (zmiana treści, usunięcie pliku lub przeniesienie go) są z marszu trackowane, a utworzenie nowego pliku nie.
-a nie doda żadnego pliku do trackowanych, tylko zastage'uje te już trackowane, natomiast add . zastage'uje wszystkie pliki. w commicie idą te pliki, które są już staged

nowy plik z -a (nic się nie zacommitowało):
 

nowy plik z add . (plik się zacommitował):


modyfikowany plik oraz nowy plik z -a (zacommitowal sie modyfikowany plik):


modyfikowany plik oraz nowy plik z add . (oba zacommitowane, zwroc uwage ze przy drugim git status (po add .) modyfikowany plik jest juz na liscie tracked files):


edit: suma sumarum ja już odruchowo w większości przypadków lecę po prostu "git add . && git commit -m "tresc commita"". podobnie jak gnysek z resztą też posiłkuję się GUIowymi gitami, z terminala robię tylko podstawowe rzeczy jak commitowanie, pull & push, checkout, merge, stashe, a jak już mam cofać commita czy bawić się z konfliktami to lepiej wyklikać, aint nobody got time fo dat

Edytowane 11 Lutego 2022 przez Chell
uwaga Ranmusa

[gnysek]

Ok, faktycznie, wygląda, że "git commit -a" robi to samo co "git add -u", a nie to co "git add". Dobrze wiedzieć Ja zwyczajnie wolę zawsze przed commitem sprawdzić co w nim idzie, dlatego bym nigdy nie połączył go z "-a" w żaden sposób.

[Ranmus]

1 godzinę temu, Chell napisał:

koleś dobrze mówi, proszę nie obrażać ludzi którzy chcą nam pomóc ale ich nie rozumiemy. pliki dzielą się na tracked i untracked. Modyfikacja pliku jest z marszu trackowana, a utworzenie, usunięcie i zmiana nazwy (przeniesienie) nie są.
-a nie doda żadnego pliku do trackowanych, tylko zastage'uje te już trackowane, natomiast add . zastage'uje wszystkie pliki. w commicie idą te pliki, które są już staged

 

Doprecyzuję, bo nieprecyzyjnie napisałeś. Git poprzez parametr -a uwzględni w commicie każdą modyfikację plików trackowanych, włącznie z usunięciem i zmianą nazwy - bo te akcje to technicznie modyfikacje pliku (Tobie zapewne chodziło o modyfikację zawartości pliku), z tym że dla zmiany nazwy warto dla pewności użyć git mv.

 

Git add po prostu dodaje nowe / nieznane gitowi pliki do trackowania. Git -m i -am różnią się w zasadzie jedynie automatycznym stagem zmodyfikowanych, trackowanych plików.

 

A co do używania gita cli, to w zasadzie używam tylko do pobrania repo. W dzisiejszych czasach znajomość cli nie jest jakoś specjalnie wymagana do pracy jak się ma narzędzia gui. Wystarczy znać podstawy działania typu właśnie pull, fetch, push, merge, fast-forward, rebase i cherry pick. Ja już nawet nie pamiętam kiedy squashowałem jakieś commity.

 

[gnysek]

17 minut temu, Ranmus napisał:

Ja już nawet nie pamiętam kiedy squashowałem jakieś commity.

 

Bo jak prawidłowo pracujesz z gitem, to takie rzeczy nie są potrzebne

[Chell]

14 minut temu, Ranmus napisał:

Doprecyzuję, bo nieprecyzyjnie napisałeś. Git poprzez parametr -a uwzględni w commicie każdą modyfikację plików trackowanych, włącznie z usunięciem i zmianą nazwy - bo te akcje to technicznie modyfikacje pliku (Tobie zapewne chodziło o modyfikację zawartości pliku), z tym że dla zmiany nazwy warto dla pewności użyć git mv.

fakt, dzięki za zwrócenie uwagi, już poprawiam

 

15 minut temu, Ranmus napisał:

Ja już nawet nie pamiętam kiedy squashowałem jakieś commity.

ja z pół roku temu, gdy pierwszy raz zdzwaniałem się z francuskim klientem zapisałem sobie w IDE (bo było najbardziej pod ręką) że imię Gaetan się czyta gejtą. chwilę później poleciał commit, a chwilę później rebase

[Ranmus]

25 minut temu, gnysek napisał:

Bo jak prawidłowo pracujesz z gitem, to takie rzeczy nie są potrzebne

 

Niby tak, ale nie do końca. To zależy od przyjętych metodyk, narzędzi i tyle.  Można przecież mieć założenie w zespole by feature branch przed pull requestem był maksymalnie sprzątnięty i była na niej jak najmniejsza ilość commitów, natomiast w robienie feature podzieliłeś sobie na wiele commitów. Robisz squasha i tyle, tudzież od biedy reset i nowy commit. W poprzedniej robocie to i na jednym z repo wymagałem, by finalnie w repo nie było żadnych branch prócz master i develop (ale to musi być mały zespół by utrzymać), więc squashe i interaktywny rebase zdarzał się nader często.

 

A teraz przykładowo pracuję w zespole o wiele bardziej doświadczonym pod względem architektury aplikacji i jakości kodu, a od strony gita nawet nie ma git flowa, commit commita pogania, merge na mergu stoi.

[snake_developer]

@ChellCo to za terminal? Ciekawie wygląda. Sorry za offtopic

[gnysek]

Godzinę temu, snake_developer napisał:

Co to za terminal?

 

Mi to wygląda na... Windows Terminal (nie CMD i nie PowerShell).

[Chell]

19 godzin temu, snake_developer napisał:

@ChellCo to za terminal? Ciekawie wygląda. Sorry za offtopic

terminal iTerm2, shell fish, motyw agnoster. akurat iTerm2 jest tylko na maca, ale na pewno da się jakoś zainstalować fish na windowsie i będzie identycznie wyglądać 

 

edit: faktycznie windows terminal ma ten sam motyw

[Ranmus]

@Chell Pytanie z innej beczki skoro używasz iTerm2 na macu. Potrzebuję zaktualizować swój komputer osobisty, bo już niedomaga. Przeznaczenie to obróbka zdjęć, wideo oraz programowanie. Komputer odpalany rzadko, bo siedzę głównie na służbowym. Polecasz migrację na maca? Myślę o mac mini / albo airbooku z M1. Trochę boję się kosztowności tego ekosystemu.

[Uzjel]

@Ranmus, Ja jak by co polecam. Kupiłem M1 Pro rok temu i wgniata w fotel. Używam do montażu, grafiki i programowania  Ale faktem jest, że za niektóre programy, które są free na Windowsie tutaj trzeba płacić.

[Chell]

W dniu 28.02.2022 o 08:19, Ranmus napisał:

@Chell Pytanie z innej beczki skoro używasz iTerm2 na macu. Potrzebuję zaktualizować swój komputer osobisty, bo już niedomaga. Przeznaczenie to obróbka zdjęć, wideo oraz programowanie. Komputer odpalany rzadko, bo siedzę głównie na służbowym. Polecasz migrację na maca? Myślę o mac mini / albo airbooku z M1. Trochę boję się kosztowności tego ekosystemu.

nie mam żadnego doświadczenia ze zdjęciami i wideo na macu (chociaż pewnie jest super, bo szeroko pojęci graficy to jeden z ich głównych targetów), ja używam tylko do programowania i fejsika. Pierwszego dostałem ze 4 lata temu z firmy, i w sumie od wtedy tylko ich używam.

w samym programowaniu mi raczej ten sprzęt nie pomaga. Docker chodzi dużo gorzej niż na linuxie (do tego stopnia, że w prawie każdym projekcie trzeba adresować ten problem i robić jakieś wygibasy z konfiguracją wolumenów), a package managery są gorsze niż apt czy inni unixowi kuzyni. I w sumie tyle, reszta to 1:1 jak praca na linuxie.

doswiadczenie z robieniem tego wszystkiego na macu to jednak zupełnie co innego, macOS to chyba jedyny system który ma dział UX. Nawet nie bardzo wiem co na ten temat napisać, workflow z wieloma pulpitami i gestami touchpada to po prostu smooth sailing.

touchpady w macbookach są genialne (i dużo nawigacji się na nim opiera), jak z takim popracujesz to każdy inny touchpad będzie dla Ciebie nieużywalnym kawałkiem plastiku. Klawiatury są po prostu OK, i to dopiero od 2020 - wcześniejsze to była tragedia. Ekrany to sztos zupełny. Obudowy są pancerne, kumpel zrzucił w jakiś sposób zamkniętego mbp ze schodów tak, że przeturlał się z nich jak ta taka sprężyna, i oczywiście widać że jest poobijany na maksa, ale nic się nie połamało, wciąż wygląda jak laptop i dalej śmiga.

mac mini bardzo fajny sprzęcik, w zupełności Ci wystarczy, ale kupiłbym na pewno mychę MX Master 3 do niego (albo magic trackpad, ale nigdy go nie używałem bo zewnętrzny touchpad to dla mnie trochę dziwny koncept), bo ma bardzo intuicyjną implementację gestów. Magic mouse odradzam, moim zdaniem taka sobie próba przeniesienia gestów na smyralną mychę, a ergonomicznie totalna kaszana i zespół cieśni nadgarstka murowany.

macbook air z m1 też fajny, chociaż sam już bym kupował pro z m1 - różnica w cenie nie jest taka rażąca, a zawsze ciut lepszy performance z tym aktywnym chłodzeniem

ale ściana tekstu mi wyszła  tl;dr - kupuj, bardzo fajne sprzęty