Więc co Twoim zdaniem jest lepsze i bardziej intuicyjne?
Fixed the XXX bug in YYY
Fix the XXX bug in YYY
Fixes the XXX bug in YYY
Fixing the XXX bug in YYY
Proszę podać swoje uzasadnienie. Uwaga Pytam z twojej ogólnej perspektywy, co oznacza, że nie powinieneś próbować kojarzyć tego z preferowanymi narzędziami svn / cvs lub językami programowania, ale raczej myśl o tym jako o czymś, co powinno / może być zastosowane do jakichkolwiek narzędzi i języków programowania.
Odpowiedzi:
Myślę o tych wiadomościach tak, jak widzą je inni deweloperzy. Nie mają jeszcze zastosowanych zmian i pojawia się niejawne pytanie „co spowoduje zastosowanie tego zestawu zmian / poprawki?” To „Napraw błąd XXX w YYY”!
W przypadku innych czasowników zapisywanie ich jako polecenia wydaje się bardziej naturalne i działa lepiej, jeśli masz określony cel z góry - możesz dosłownie napisać podsumowanie zatwierdzenia wraz z wstępnymi testami przed wykonaniem pracy.
Nie przykładam do tego dużej wagi, ale dla mnie jest to ścieżka najmniejszego oporu przy zachowaniu spójności.
Osobiście posługuję się czasem przeszłym („naprawiony”), ponieważ zanim popełnię błąd, błąd jest już naprawiony (w przeciwnym razie nie zatwierdzałbym).
Wolę widzieć komunikaty o zatwierdzeniach w czasie teraźniejszym. W ten sposób komunikat opisuje, co robi diff (ponieważ możesz przeciągnąć tę różnicę lub nawet całe zatwierdzenie do innej gałęzi). Zatem komunikat o zatwierdzeniu nie opisuje tego, co „zrobił”… Opisuje, co „robi” samo zatwierdzenie. Więc powinno być w czasie teraźniejszym.
Wyobraź sobie, że patrzysz na różnicę w izolacji i próbujesz zdecydować, czy go zastosujesz. Nie ma sensu mieć tytułu w czasie przeszłym.
IMHO, jeśli chcesz, aby był opisowy bez konieczności rozważania kontekstu, to „Naprawiono” jest zdecydowanie jedynym właściwym wariantem.
Jeśli chodzi o intuicyjność - jeśli spojrzę na jakiś changelog, na pewno zrozumiem, że masz na myśli naprawiony błąd, ponieważ znam kontekst, w którym słowo jest użyte, ale mój mózg złapie go znacznie szybciej, jeśli słowo zostanie zapisane w tym ja- określając sposób.
„Naprawianie” jest najgorszym wyborem IMHO, ponieważ można je zinterpretować nie tylko jako opis działania poprawki (do czego służy), ale także jako stan błędu, który oznaczałby, że nad nim pracujemy i nie został jeszcze rozwiązany.
Fix the XXX bug in YYY
Teach the XXX to be more ZZZ
Correct typos in javadoc
Ogólnie: {czasownik imperatywny} {obiekt, którego dotyczy problem} {opcjonalne kwalifikatory}
Forma rozkazująca pasuje do wszystkich przypadków użycia, gdy rozważam zestaw poprawek.
Niezależnie od twojego wyboru uważam, że spójność ogromnie pomaga w czytelności. Wybierz jeden i trzymaj się go.
Myślę, że pisanie o aktualnym zatwierdzeniu w czasie teraźniejszym jest dobrym pomysłem, ponieważ wyjaśnia to bardziej, gdy odnosisz się do wcześniejszych zatwierdzeń w czasie przeszłym.
Myślę, że to naprawdę nie ma znaczenia. Celem jest:
1) Przekaż, co jest lub było robione, aby łatwiej było znaleźć błędy, łatwiej było naprawić problemy i ogólnie łatwiej utrzymać projekt.
2) Przekaż, jakie bilety zostały naprawione, jeśli w ogóle, aby audytorzy (jeśli są używane w Twojej firmie, mogą zobaczyć, jakie zmiany odpowiadają którym biletom).
Wreszcie, jeśli problem został już naprawiony, „Naprawianie” nie ma sensu, a jeśli nadal nad tym pracujesz, „Naprawiono” nie jest poprawne.
„ Fix bug X ” jest o 2 znaki krótsze niż „ Fixed bug X ”.
I 3 krócej niż „ Naprawianie błędu X ”.
Z punktu widzenia pisania krótkich wiadomości, czas teraźniejszy czasami / zwykle oszczędza kilka znaków?
Co, jak sądzę, ma trochę znaczenia, np. Z zaleceniem Gita o mniej niż 50 znaków w pierwszej linii wiadomości zatwierdzenia.
Poza tym mniej tekstu -> czytać szybciej?
Komunikat dotyczący zatwierdzenia opisuje, dlaczego napisałeś kod, który jest zatwierdzany.
„Naprawiono problem 3124” lub „Naprawia problem 3124” wydaje się poprawne, ponieważ zawiera informację, że ten kod rozwiązał | rozwiązuje problem 3124.
Jednak gramatyka może również zależeć od tego, dlaczego oznacza błąd jako naprawiony. Jeśli możesz oznaczyć błąd jako naprawiony po zatwierdzeniu, wtedy „Naprawiono” jest w porządku, ale jeśli błąd ma zostać oznaczony jako naprawiony przez kogoś innego po zweryfikowaniu Twojego kodu, wtedy „Poprawki” mogą być bardziej odpowiednie.
Myślę, że najważniejszą odpowiedzią na takie pytanie jest: każdy powinien wykorzystać to, co działa w konkretnym projekcie i zachować przynajmniej odrobinę spójności.
Chociaż widzę zalety używania czasu teraźniejszego (i faktycznie natknąłem się na ten post, ponieważ widziałem kilka komunikatów z czasem teraźniejszym w projektach open source), prawdopodobnie nigdy nie będę używał czasu teraźniejszego w moich projektach. Jest to zalecany sposób dla Linuksa i Gita, i prawdopodobnie innych większych projektów open source, ale szczerze mówiąc, nie obchodzi mnie to, dopóki nie jestem częścią tych projektów.
Jestem deweloperem niezależnym i używam pierwszej linii komunikatu o zmianach w informacjach o wydaniu, podczas gdy opis w kolejnych wierszach daje mi wyobrażenie o szczegółach implementacji. Jest to przepływ pracy zorientowany na użytkownika w porównaniu z obecnym podejściem opartym na programistach. W ten sposób mogę zaoszczędzić trochę czasu. Podawanie instrukcji użytkownikom w informacjach o wydaniu byłoby niezwykle nienaturalne. Moim zadaniem jest naprawianie błędów i dodawanie funkcji. Muszę oszczędzać czas, ponieważ jestem niezależny. W moim zespole nie mam „autora notatek wydania”.
Użyj reguł projektu, jeśli są już ustalone, ale zachowaj pragmatyzm i rób wszystko, co ułatwi lub przyspieszy Twoją pracę.
Myślę, że "Fixes XXX bug"ma to więcej sensu, niż "Fix XXX bug"gdyby powodem użycia czasu teraźniejszego było „uczynienie go bardziej opisowym tego, co robi zatwierdzenie” , niż to, co zrobił popełniający.
Jeśli jest to mały commit, używam Present Continuous:
Naprawianie błędu 304
lub
Dodawanie komentarzy
Jeśli jest to duże zatwierdzenie, robię więcej w dzienniku zmian: