Regras de convívio profissional [Para Devs]

Parabéns pelo post!!!

Eu pessoalmente gosto de pensar bem antes de commitar e fazer commits que façam sentido. Sobre esse ponto:

Não faça mais de um commit com a mesma mensagem

Tenho uma dica caso você se veja nessa necessidade. Geralmente isso acontece quando pensamos que já terminamos uma feature X, e a commitamos, mas depois percebemos que ainda vamos ter que trabalhar nela. Se isso acontecer, você não precisa fazer outro commit com o mesmo nome, além da opção óbvia de criar um commit com uma mensagem diferente, você pode usar o comando git commit --ammend, que irá adicionar as novas alterações (que estiverem em stage) ao seu último commit local. Além disso, se você tiver feito besteira e precisar reorganizar seus commits, pode usar o seguinte comando:

git rebase --interactive hash_do_commit

Ele abrirá uma lista de opções para você escolher, podendo excluir ou juntar commits. Vale a pena estudar um pouquinho sobre esse comando.

pick bae6596 chore(SEO): add index tag
pick 2f9dd16 chore(SEO): update index tag

# Rebase 144b615..2f9dd16 onto 144b615 (2 commands)
#
# Commands:
# p, pick <commit> = use commit
# r, reword <commit> = use commit, but edit the commit message
# e, edit <commit> = use commit, but stop for amending
# s, squash <commit> = use commit, but meld into previous commit
# f, fixup [-C | -c] <commit> = like "squash" but keep only the previous
#                    commit's log message, unless -C is used, in which case
#                    keep only this commit's message; -c is same as -C but
#                    opens the editor
# x, exec <command> = run command (the rest of the line) using shell
# b, break = stop here (continue rebase later with 'git rebase --continue')
# d, drop <commit> = remove commit
# l, label <label> = label current HEAD with a name
# t, reset <label> = reset HEAD to a label
# m, merge [-C <commit> | -c <commit>] <label> [# <oneline>]
# .       create a merge commit using the original merge commit's
# .       message (or the oneline, if no original merge commit was
# .       specified); use -c <commit> to reword the commit message
#
# These lines can be re-ordered; they are executed from top to bottom.
#
# If you remove a line here THAT COMMIT WILL BE LOST.
#
# However, if you remove everything, the rebase will be aborted.
#

Tradeoffs dessa abordagem

Vale ressaltar que se você está trabalhando em um time, precisa ter cuidado ao sobreescrever o histórico de commits que você já deu push, porque nesse caso, você pode acabar apagando o commit de alguém ou causando conflitos desnecessários, por isso tome cuidado.

Uma coisa que tem me ajudado muito e acredito que tornam os commits muito legíveis é a extensão Conventional Commits pro VS Code. Usando essa extensão, de uma forma bem prática, você é guiado em passos para:

1. Tipo do commit (feat, fix, build, refactor, etc)
2. Escopo do commit (sem escopo, com escopo e escopo de uso único)
3. Emoji para o commit (esse é opcional)
4. Descrição curta (uma descrição breve do conteúdo do commit)
5. Descrição longa (a descrição detalhada do commit)
6. Breaking changes (aqui pode-se listar as alterações ou as issues que são fechadas com esse commit)

Recomendo demais para quem quer manter tudo organizado. Para quem quiser ler mais sobre o Conventional Commits, eles tem uma documentação em PT-br bem esmiuçada que explica a convenção todinha 😄

muito interessante.

Muito relevante esse post. parabéns. me fez abrir os olhos sobre o assunto.

Nos projetos em que trabalho aplico essa convenção: https://www.conventionalcommits.org/en/v1.0.0/
Ela ajuda na comunicação e organização dos commits, seguindo um padrão.