Nazewnictwo

Pull request:

• Tytuł:

  • #001/(optional)PART/section/optional-specjal-mode/summary
  • section: UI / logic / DEV
  • optional-specjal-mode: refactor / bugfix / hotfix
  • PART - dodajemy, gdy pull request jest częścią naszego taska, którą chcemy umieścić na developie (np. ktoś inny potrzebuje tych funkcjonalności
  • jeśli robimy PART pull request - koniecznie napiszcie co jest zrobione, a co zostało jako TODO, żeby było wiadomo co jest świadomie niefunkcjonujące, a co jest bugiem
  • np #001/PART/UI/blue-button , #001/PART/logic/bugfix/repaired-fetching-data
  • UI:
    • UI - jak najkrótsza nazwa stworzonego komponentu, która jednoznacznie mówi czym ten komponent jest
    • np. #001/UI/blue-button , #001/UI/register-form
  • Logic:
    • tutaj jeszcze pomyślę w trakcie nauki backend
    • podsumowanie dodawanej funkcjonalności / klasy / zakresu
    • np #001/logic/get-competitor-data, #001/logic/data-operations-in-organizer-role

• Opis:

  • skrócony opis tego co zawiera pull request, co zostało dodane, zmienione, każdy element / grupa elementów od myślnika
  • TODO - od myślników co wiecie że jest do zrobienia, ale celowo nie wchodzi w zakres tego pull requesta

Branch:

• #001/section/summary/optional-specjal-mode
• section: logic / UI
• optional-specjal-mode: refactor / bugfix / hotfix
• BRANCHE robocze/testowe/śmieciowe:
  • test/#001/section/summary
• np. #001/UI/leaderboard , #002/UI/leaderboard/bugfix

Commit:

• krótkie, imperatywne (tryb rozkazujacy) stwierdzenia, co zostało zmienione, od myślników
  • np -change styles for blue button | do wyjaśnienia !!!
• można, ale nie trzeba bardziej szczegółowo
• jeśli to robocze commity w fazie prób i błędów - na początku informacja: TO SAVE CHANGES / WORK IN PROGRESS, a dalsza zawartość opcjonalna

Podsumowanie:

• nazwy commitów mają pomóc potem zgrabnie i sprawnie opisać PR, a nazwy branchy nadać tytuł PR który będzie mówił wszystko o zawartości