2010-11-08 11 views

Odpowiedz

12

To zależy, oczywiście, ale to bardzo powszechny format jest coś takiego (wzięte z http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html, że myślę, że podsumowuje to naprawdę dobrze):

Short (50 chars or less) summary of changes 

More detailed explanatory text, if necessary. Wrap it to about 72 
characters or so. In some contexts, the first line is treated as the 
subject of an email and the rest of the text as the body. The blank 
line separating the summary from the body is critical (unless you omit 
the body entirely); tools like rebase can get confused if you run the 
two together. 

Further paragraphs come after blank lines. 

- Bullet points are okay, too 

- Typically a hyphen or asterisk is used for the bullet, preceded by a 
    single space, with blank lines in between, but conventions vary here 

Jedno nie odnosi to coś Zaadoptowałem dla siebie, a mianowicie za pomocą krótkich tagów na początku pierwszej linii, aby zidentyfikować rodzaj zatwierdzenia. Mogą to być takie znaczniki, jak [fix] dla poprawki błędu, [new] dla nowej funkcji lub [dev] dla zatwierdzenia, które dotyczy tylko wewnętrznych. Dzięki takiemu zasadom łatwo jest automatycznie wygenerować listę zmian z zatwierdzeń.

Edit: Oto kolejny dobry podsumowanie, nawet z tej strony: In git, what are some good conventions to format multiple comments to a single commit

+1

Znacznie częstszym przedrostkiem dla pierwszej linii jest część projektu, do której odnosi się zatwierdzenie. Może to być nazwa pliku, moduł, cokolwiek ci pasuje. W przeciwnym razie, myślę, że w zasadzie obejmowałeś zwykłych podejrzanych! – Cascabel

+0

Mam tendencję do nie zagracania mojego podsumowania za pomocą żadnych metadanych (innych niż wskaźniki błędów). Dobrze napisane commity z dobrymi podsumowaniami to dobry początek. zawsze możesz dodać tagi u dołu podsumowania, aby zdecydować, czy coś kwalifikuje się do wydania. Następnie umieszczam je w tagu rzeczywistym i [generuję mój dziennik zmian] (http://dustin.github.com/2009/01/17/changelog.html) z tagów. :) – Dustin

1

nie polecam dużych wiadomości. Jeśli nie potrafisz wyjaśnić jednym zdaniem, co robisz, twoje zatwierdzenie obejmuje zbyt wiele zmian. Użyj git rebase -i i podziel commit, jeśli już popełniłeś. Jeśli nie wprowadziłeś jeszcze zmian, użyj git add -p, aby tworzyć małe części, a następnie zatwierdz jako mniejsze zatwierdzenia.

Szczegółowa historia zmian w ten sposób pomoże w późniejszym scalaniu i rebazach. Pomoże Ci to również utworzyć link do narzędzia do śledzenia problemów. Jeśli zaadresujesz 2 lub więcej biletów, trudniej będzie odszyfrować, jaki bilet zmieni się w zatwierdzonym zatwierdzeniu.

+1

Nietrywialne zmiany często wymagają znacznego wyjaśnienia, szczególnie jeśli pracujemy nad dużym projektem, który musi zachować semantykę zewnętrznego i/lub wewnętrznego dokumentu specyfikacji. Musiałem napisać cztery komunikaty zatwierdzania akapitu, aby zmienić pojedyncze makro w źródle MPICH, ponieważ musiałem wyjaśnić standardowe zachowanie MPI ORAZ wewnętrzną semantykę makro, aby uzasadnić zmianę. Gdybym tego nie zrobił, jakiś przyszły programista marnowałby nadmierną ilość czasu na ponowne odkrycie tych informacji. Zgłaszałbym, gdybym mógł ... – Jeff

+0

Dzięki, @Jeff. Oprogramowanie jest tak wielkim światem, że tak naprawdę nie chodzi o reguły, ale raczej o wytyczne. Czasem po prostu nie można ich zastosować. –

+0

Zgadzam się z ideą popełnienia ataków atomowych (dlatego ogólnie nie lubię zgniatania), ale uważam, że lepiej jest po stronie błędu podać więcej kontekstu niż potrzeba, a nie mniej. Także jeśli praca nie została zatwierdzona jako Atomowe Polecenia, nie polecałbym rozpadu po tym, jak sugerujesz. Rodzi to ryzyko popełnienia niekompletnego kodu. –