Antes de mais nada: todo o trabalho precisa ser "commitado". Sem mais, nem menos. Esse é o primeiro passo.
Não reinvente a roda e não seja rebelde. Se o projeto que você começou a trabalhar, já tem um padrão definido e que atende a necessidade, não há razão para mudanças drásticas. Se o projeto já tem tempos de vivência, significa que o padrão atual já dá conta do recado (ou ao menos deveria).
O ideal para manter o código bem versionado é, para cada mudança, um commit. Seja adição de nova funcionalidade, correção de bug ou até remoção de uma funcionalidade antiga. Isso nos dá a facilidade de usar uma das principais funcionalidades do versionamento: retroceder ao código antes do commit indicado.
Todo commit deve ser tratado como um verbo (ação), seguido da(s) alteração(ões) feita(s) – seja uma adicão, atualização ou remoção.
Alguns dos verbos são: add, create, update, edit, remove. Exemplos:
git commit -m "FK-111 Create: filter and countdown"
git commit -m "FK-124 Remove: popup in mobile"
git commit -m "FK-112 Update: responsive menu"
git commit -m "FK-123 Edit: links color in a submenu"
git commit -m "FK-166 Fix: bug in flag"
Exemplo de Add: Estou resolvendo uma feature, mas preciso ir almoçar ou sair pra fazer qualquer outra coisa... Vou commitar para não perder nada, mas como sei que não terminei a task, vou dar um commit enumerado:
git commit -m "FK-010 Add: modal login #1"
Depois que tudo estiver pronto:
git commit -m "FK-010 Add: modal login #2"
A nomeclatura de um merge deve ser simples e coesa, condizendo com o motivo daquele merge. Mais específicamente, indicar a ação realizada naquele merge logo no início. Exemplos de ação: fix, add, remove, refactoring.
Obs: O ID da tarefa no início do commit, é fundamental para a integração que iremos fazer do bitbucket com o jira 😁
Ótimo documento. (^^)