[Dejdwid96]

Jak prawidłowo nazywać Git commity i co jaki czas je robić? Możecie dać przykład?
#programowanie #naukaprogramowania #programista15k

[slgdfhsdhjfbs]

@Dejdwid96: Nikt na to nie patrzy, najważniejsze to żeby w nazwie commita była nazwa ticketa z Jiry.

[alek-alek-hej]

git commit -m "stable shit"
Zmiany
git commit -m "r--------m build"
Zmiany
git commit -m "stable shit"
git rebase

[alek-alek-hej]

@alek-alek-hej: no i oczywiście na samym początku git branch i git switch

[Hauleth]

@Dejdwid96: teraz na serio

- Robisz jak często Ci się podoba
- Przed wysłaniem ich do merge robisz rebase albo git reset i potem commitujesz sobie z ładnym opisem i tytułem
- https://www.conventionalcommits.org/en/v1.0.0/ - ja używam tego, ale z pewną zmianą, bo używam ft zamiast feat, bo marnowanie dwóch dodatkowych znaków (z limitu 72 w tytule) na nic nie znaczący tag jest IMHO bezsensowne

[Myzreal]

@Dejdwid96: Nie ma tu żadnej dogmy, mozesz je generalnie robić jak chcesz i raczej nikt się nie p----------i, ale jeśli chcesz to robić porządnie to commity robisz tak żeby miały w sobie zawartą jakiś logiczny kawałek roboty. Np. dodanie jakiegoś panelu albo coś. To wtedy ułatwia ewentualne debugowanie, bisectowanie gitem i inne takie zaawansowane czynności które w swojej karierze wykonasz może raz w życiu :P

[Fattek]

@Dejdwid96: "small fix", "small change"

[Lucjusz6]

@Dejdwid96: commit powinien być dokończeniem zdania "this commit will..." Np. 'Add table filters' 'Fix issues with chart color' 'Refactor user chat system' bez znaków interpukcyjnych. Co do tego kiedy je robić - commit powinien zawierać osobną atomowąfunkcjonalność/bugfix która działa odrębnie ale poprawnie. Czyli np wyświetlanie userów, nie musi mieć filtrów od razu. Ale nie możesz robić commita który wyświetla userów ale ich np nie pobiera. Wszystko zależy od Product Ownera

[Djelon]

@Dejdwid96: conventional commits zarówno w commitach jak i nazwach branchy, to najlpopularniejszy standard o ile nie jedyny ;)
Robisz co chcesz w ficzer branczu, a potem PR/MR robisz ze squashem

[hufsa]

Przestaje sie dziwic stanowi polskiego IT i tego, ze wiekszosc z was szuka pracy po pol roku i znalezc nie moze ( ͡° ͜ʖ ͡°) dopiero @Lucjusz6 odpowiedzial poprawnie

[slgdfhsdhjfbs]

dopiero @Lucjusz6 odpowiedzial poprawnie

@hufsa: Według mnie to ja odpowiedziałem poprawnie.

[hufsa]

@slgdfhsdhjfbs jaki bootcamp ukończyłeś? ( ͡° ͜ʖ ͡°)

[slgdfhsdhjfbs]

@hufsa: Żaden, piszę z doświadczenia xd

[draxgar]

@Dejdwid96: to zależy. Robisz commit w dwóch sytuacjach:

1. Chcesz zachować jakiś postęp gdy programujesz.
2. Zakończyłeś robotę nad funkcjonalnością i chcesz dostarczyć (merge) zmian z gałęzi.

W pierwszym przypadku częstotliwość i treść commitu nie mają znaczenia. W drugim już fajnie by było opisać, co zrobiłeś, zachować jakąś przyjętą formalną strukturę wiadomości. Dobrze by było mieć podział feature na sensowne fragmenty, lub jeden commit w branch. Commit message w przypadku