I FKUI använder vi commits som grund till både Changelog och för att automatiskt bestämma vilken nästkommande version blir.

Commitmeddelanden använder en modifierad variant av Conventional Commits där skillnaden är att vi kräver en Jira-referens i slutet:

${type}: ${description} (${relation} ${jira})

där:

• ${type} är vilken typ av commit, vanligtvis fix eller feat.
• ${description} är en kort summering av commit.
• ${relation} är hur commit relaterat till en Jira, refs eller fixes.
• ${jira} är den Jira som commit relaterar till.

Scope sätter vi enbart i undantagsfall då det populeras automatiskt i Changelog. Vanligt undantag är chore(deps) för beroenden, chore(release) för releaser samt refactor(${verktyg}) och style(${verktyg}).

Typ

Den viktigaste beståndsdelen är type som används för att avgöra om commitmeddelandet ska visas i changelog samt om det ska användas för att skapa en release.

De vanligaste två är feat (ny funktionallitet) och fix (rättning av existerande funktionallitet). Andra vanliga är docs (ändring enbart av dokumentation) och refactor (interna förändringar som inte påverkar konsument).

Läs mer om brytande ändringar.

Tumregler

Ett bra commitmeddelande ska:

• Beskriva vilken eller vilka komponenter eller funktioner som berörs. Skriv "add new prop foo on component FBar" istället för "add new prop" eller "add new prop foo" eftersom läsaren inte känner till sammanhanget.
• Undvika att benämna ramverkskomponenter ("i-komponenter") utan skriv istället de publika komponenter ("f-komponenter") som påverkas av ändringen.

Commitlint

Vi använder Commitlint för att upprätthålla formatet på commitmeddelanden. Commitlint anropas från git commit-msg hook (via husky från .husky/commit-msg) och är konfigurerat med att använda @forsakringskassan/commitlint-config.

Om det behövs kan du kringgå commitlint med --no-verify:

git commit --no-verify -m 'non-conforming message'

Arbetsflöde

För feature-branches rekommenderar vi detta arbetsflödet för dina commits:

1. För varje distinkt feature eller buggrättning, skapa en specifik och fristående commit (tänk på det som att den skulle gå att lägga en egen PR och mergas separat från övriga commits i din branch). Denna commit ska använda feat eller fix som type.
2. Behöver du bygga vidare på en tidigare commit (i din branch) kan du antingen använda git commit --fixup eller skapar en ny commit med refactor som type.
3. Innan det är dags för merge gör du en sista rebase över master där du slår ihop lämpliga commits, framförallt fixups men även de commits som använder refactor (vars syfte inte är att göra en refaktorisering av kod som inte skapats i denna branch).