Rozpoczęcie zadania przez kogoś innego, a kończenie przeze mnie

0

Witam,

Jakiś czas temu miałem taska do zrobienia, ale nie wiedziałem jak do niego podejść. Drugi deweloper pomógł mi je zacząć i też stworzył pod to swojego brancha w gicie. Ja natomiast dalej już klepałem to zadanie na tym branchu na które zeszło mi kilka tygodni, bo kodu było dość sporo. Niedawno zostało ono zmergowane. Jednak przy mergowaniu robimy squasha wszystkich commitow do jednego commita przez co teraz w kodzie aplikacji wszystkie zmiany są widoczne jakoby ta druga osoba je robiła. Jedynie po poprzez wejście do PRa można zobaczyć, że miałem też w tym udział.

Powiedzcie czy w takich sytuacjach jest czym się martwić czy martwię się bez powodu ? Wyjdzie, że przez ostatnie kilka tyg nie napisałem żadnego kodu jeśli by sprawdzać kod aplikacji za pomocą git blama.

2

Byłem w Twojej, jak i w przeciwnej sytuacji i nie było z tym problemów.

13

Jedyna sytuacja, w której ktoś sprawdza autora commita, to sytuacja w której ktoś chce tego autora zbluzgać za wprowadzenie buga :)

0

Zrób reverta, wyciągnij własne zmiany i zrób nowego pull requesta.

1

Where problem?

2
ledi12 napisał(a):

Where problem?

Problem jest tylko jak trzeba przygotować raport z commitow do KUP. Ale w firmach zwykle jeden commit na miesiąc do losowego repo starcza

0
kaktus18 napisał(a):

Powiedzcie czy w takich sytuacjach jest czym się martwić czy martwię się bez powodu ? Wyjdzie, że przez ostatnie kilka tyg nie napisałem żadnego kodu jeśli by sprawdzać kod aplikacji za pomocą git blama.

Trzymaj swojego Gita na prywatnym remote a na najbliższym lessons learned zaproponuj przejście na SVNa w ramach zwiększenia transparentności.

0

Czym się martwisz? Wasz proces jest głupi i to wychodzi. Squashowanie commitów do jednego, gdy nie jest to oczywiste nie ma sensu.

0

Osobiście nie lubię squshów, bo przez nie często istotna informacja w commit message potrafi zginąć.
Dlatego preferuje rebase + merge. Od merge do merge widać wtedy jeden feature, a widać detale poszczególnych commitów.

To, że w git blame widać nie to nazwisko, to bym się nie przejmował. Jak ktoś będzie chciał dopytać autora o detale, to wtedy jest tylko problem, bo dłużej sie szuka włąściwej osoby.
Nikt nie stosuje git blame w innych celach, niż wyjaśnienie co robi (powinien robić) kod.

Raz używałem git-a by wygenerować listę moich commitów, w celu stworzenia raportu na potrzeby KUP.

2

Ale kogo to o obchodzi kogo widać w git blame? Jak ktoś będzie chciał zobaczyć kto tak naprawdę robił dany kod to se historię merge requesta przejrzy, spokojna twoja rozczochrana.

Jedyny moment kiedy to kogoś obchodzi to firmy które liczą na tej podstawie performance. Miałem nieprzyjemność w takiej pracować i wtedy nie robiło się squash.

1

Najlepiej nie martwić się na zapas, Carpe diem !
Jeszcze nikt się nie przyczepił, a już jakieś czarnowidztwo.
Jak się przyczepi to wyjaśnisz jak było, normalny człowiek zrozumie i może dostrzeże nawet jakieś ułomności firmowej metodologi a nie normalny, cóż!
Z nienormalnym nie chciał bym pracować

4

Ja natomiast dalej już klepałem to zadanie na tym branchu na które zeszło mi kilka tygodni, bo kodu było dość sporo.

Ja bym się nie martwił kogo widać w commicie, tylko tym, że task zajął kilka tygodni ;-)

1 użytkowników online, w tym zalogowanych: 0, gości: 1