I'm wondering what should be the commit type of a commit which resolves conflicts according to Convensional commits. Please consider the following scenario
I'm in branch A
git merge B
resolve conflicts
add .
What should be the type of this commit according to Convensional commits ?
tl;dr: Normally you shouldn't have a new commit that simply resolves conflicts. Instead, some other commit that exists for it's own reason should resolve the conflicts. Therefore, you don't need a specific title for resolving conflicts.
Disclaimer: I have never actually used conventional commits before, but I have read the spec a few times.
Detailed Example:
Suppose you have a branch feat/add-new-thingy with two new commits on it. Imagine when you run git log --oneline that you see:
222 fix: prevent stack overflow (HEAD -> feat/add-new-thingy, origin/feat/add-new-thingy)
111 feat: add new thingy
000 ... (main)
Suppose you attempt to use a Pull Request to merge your branch into main on GitHub, but the remote version of main is ahead of where you started from, and you currently have conflicts. After fetching, and then running git log origin/main --oneline you see something like this:
bbb feat: add more ducks to the pond (origin/main)
aaa fix: increase maximum stack size
000 ... (main)
On your branch, you added a new feature but also fixed a stack overflow bug. It appears that someone else also fixed the stack overflow bug, but perhaps did it in a different way than you did. This is likely (but not necessarily) the reason there are conflicts. To resolve the conflicts, you generally will either merge in the latest version of origin/main into your branch, or you can rebase your branch onto the latest origin/main. Let's see what happens with merge first:
git fetch # probably up to date since we fetched 1 minute ago, but it can't hurt
git switch feat/add-new-thingy # probably already checked out
git merge origin/main # conflicts
If you didn't have conflicts, you would now simply have a merge commit with a message like "Merge remote-tracking branch 'origin/main' into feat/add-new-thingy". Note you could change that merge commit message if you wish, but even if you do it probably isn't necessary to use a conventional-commit specific type for a merge commit, since each of the relevant commits already specify their type.
If you did have conflicts, then you resolve them and commit the merge, and usually you don't need to change the merge commit message, compared to what the merge commit message would be without conflicts. Therefore, even with conflicts, your merge commit message is just a regular merge commit message. After the merge with your resolved conflicts, you simply push:
git push # Now your PR can be completed.
Instead of merging, if you elect to resolve conflicts by rebasing, for example:
git fetch # probably up to date since we fetched 1 minute ago, but it can't hurt
git rebase origin/main feat/add-new-thingy # conflicts
To resolve conflicts you'll be stopped before committing each commit that has conflicts, which in this example is most likely at commit 2 of 2. After resolving the conflicts you will either commit yourself, or git rebase --continue to re-use the existing commit message, and your 2nd commit, "fix: prevent stack overflow" will be written in the new way that resolves the conflicts. With rebase, there is no additional commit.