De acordo com a documentação do Conventional Commits, commits semânticos são uma convenção simples para ser utilizada nas mensagens de commit. Essa convenção define um conjunto de regras para criar um histórico de commit explícito, o que facilita a criação de ferramentas automatizadas.
Esses commits auxiliarão você e sua equipe a entenderem de forma facilitada quais alterações foram realizadas no trecho de código que foi commitado.
Essa identificação ocorre por meio de uma palavra e emoji que identifica se aquele commit realizado se trata de uma alteração de código, atualização de pacotes, documentação, alteração de visual, teste...
O commit semântico possui os elementos estruturais abaixo (tipos), que informam a intenção do seu commit ao utilizador(a) de seu código.
-
feat- Commits do tipo feat indicam que seu trecho de código está incluindo um novo recurso (se relaciona com o MINOR do versionamento semântico). -
fix- Commits do tipo fix indicam que seu trecho de código commitado está solucionando um problema (bug fix), (se relaciona com o PATCH do versionamento semântico). -
docs- Commits do tipo docs indicam que houveram mudanças na documentação, como por exemplo no Readme do seu repositório. (Não inclui alterações em código). -
test- Commits do tipo test são utilizados quando são realizadas alterações em testes, seja criando, alterando ou excluindo testes unitários. (Não inclui alterações em código) -
build- Commits do tipo build são utilizados quando são realizadas modificações em arquivos de build e dependências. -
perf- Commits do tipo perf servem para identificar quaisquer alterações de código que estejam relacionadas a performance. -
style- Commits do tipo style indicam que houveram alterações referentes a formatações de código, semicolons, trailing spaces, lint... (Não inclui alterações em código). -
refactor- Commits do tipo refactor referem-se a mudanças devido a refatorações que não alterem sua funcionalidade, como por exemplo, uma alteração no formato como é processada determinada parte da tela, mas que manteve a mesma funcionalidade, ou melhorias de performance devido a um code review. -
chore- Commits do tipo chore indicam atualizações de tarefas de build, configurações de administrador, pacotes... como por exemplo adicionar um pacote no gitignore. (Não inclui alterações em código) -
ci- Commits do tipo ci indicam mudanças relacionadas a integração contínua (continuous integration). -
raw- Commits to tipo raw indicam mudanças relacionadas a arquivos de configurações, dados, features, parametros.
- Adicione um tipo consistente com o título do conteúdo.
- Recomendamos que na primeira linha deve ter no máximo 4 palavras.
- Para descrever com detalhes, usar a descrição do commit.
- Usar um emoji no início da mensagem de commit representando sobre o commit.
- Os links precisam ser adicionados em sua forma mais autêntica, ou seja: sem encurtadores de link e links afiliados.
- Rodapé: informação sobre o revisor e número do card no Trello ou Jira. Exemplo: Reviewed-by: Elisandro Mello Refs #133
- Corpo: descrições mais precisas do que está contido no commit, apresentando impactos e os motivos pelos quais foram empregadas as alterações no código, como também instruções essenciais para intervenções futuras. Exemplo: see the issue for details on typos fixed.
- Descrições: uma descrição sucinta da mudança. Exemplo: correct minor typos in code
| Tipo do commit | Emoji | Palavra-chave |
|---|---|---|
| Acessibilidade | ♿ :wheelchair: |
|
| Adicionando um teste | ✅ :white_check_mark: |
test |
| Atualizando a versão de um submódulo | ⬆️ :arrow_up: |
|
| Retrocedendo a versão de um submódulo | ⬇️ :arrow_down: |
|
| Adicionando uma dependência | ➕ :heavy_plus_sign: |
build |
| Alterações de revisão de código | 👌 :ok_hand: |
style |
| Animações e transições | 💫 :dizzy: |
|
| Bugfix | 🐛 :bug: |
fix |
| Comentários | 💡 :bulb: |
docs |
| Commit inicial | 🎉 :tada: |
init |
| Configuração | 🔧 :wrench: |
chore |
| Deploy | 🚀 :rocket: |
|
| Documentação | 📚 :books: |
docs |
| Em progresso | 🚧 :construction: |
|
| Estilização de interface | 💄 :lipstick: |
feat |
| Infraestrutura | 🧱 :bricks: |
ci |
| Lista de ideias (tasks) | 🔜 :soon: |
|
| Mover/Renomear | 🚚 :truck: |
chore |
| Novo recurso | ✨ :sparkles: |
feat |
| Package.json em JS | 📦 :package: |
build |
| Performance | ⚡ :zap: |
perf |
| Refatoração | ♻️ :recycle: |
refactor |
| Removendo um arquivo | 🔥 :fire: |
|
| Removendo uma dependência | ➖ :heavy_minus_sign: |
build |
| Responsividade | 📱 :iphone: |
|
| Revertendo mudanças | 💥 :boom: |
fix |
| Segurança | 🔒️ :lock: |
|
| SEO | 🔍️ :mag: |
|
| Tag de versão | 🔖 :bookmark: |
|
| Teste de aprovação | ✔️ :heavy_check_mark: |
test |
| Testes | 🧪 :test_tube: |
test |
| Texto | 📝 :pencil: |
|
| Tipagem | 🏷️ :label: |
|
| Tratamento de erros | 🥅 :goal_net: |
|
| Dados | 🗃️ :card_file_box: |
raw |
| Comando Git | Resultado no GitHub |
|---|---|
git commit -m ":tada: Commit inicial"
|
🎉 Commit inicial |
git commit -m ":books: docs: Atualização do README"
|
📚 docs: Atualização do README |
git commit -m ":bug: fix: Loop infinito na linha 50"
|
🐛 fix: Loop infinito na linha 50 |
git commit -m ":sparkles: feat: Página de login"
|
✨ feat: Página de login |
git commit -m ":bricks: ci: Modificação no Dockerfile"
|
🧱 ci: Modificação no Dockerfile |
git commit -m ":recycle: refactor: Passando para arrow functions"
|
♻️ refactor: Passando para arrow functions |
git commit -m ":zap: perf: Melhoria no tempo de resposta"
|
⚡ perf: Melhoria no tempo de resposta |
git commit -m ":boom: fix: Revertendo mudanças ineficientes"
|
💥 fix: Revertendo mudanças ineficientes |
git commit -m ":lipstick: feat: Estilização CSS do formulário"
|
💄 feat: Estilização CSS do formulário |
git commit -m ":test_tube: test: Criando novo teste"
|
🧪 test: Criando novo teste |
git commit -m ":bulb: docs: Comentários sobre a função LoremIpsum( )"
|
💡 docs: Comentários sobre a função LoremIpsum( ) |
git commit -m ":bulb: raw: RAW Data do ano aaaa"
|
🗃️ raw: RAW Data do ano aaaa |
Aqui estão os passos para configurar uma chave SSH no GitHub:
Se você ainda não tem uma chave SSH, você pode gerá-la usando o seguinte comando:
ssh-keygen -t rsa -b 4096 -C "seu_email@example.com"Substitua "seu_email@example.com" pelo seu endereço de e-mail.
Inicie o ssh-agent em segundo plano:
eval $(ssh-agent -s)Adicione sua chave SSH privada ao ssh-agent. Substitua "caminho_para_sua_chave" pelo caminho onde sua chave está localizada:
ssh-add caminho_para_sua_chave_ssh- Copie o conteúdo da sua chave pública. Substitua "caminho_para_sua_chave" pelo caminho onde sua chave está localizada:
cat caminho_para_sua_chave.pub-
Vá para as configurações de SSH do GitHub.
-
Clique em "New SSH key".
-
Cole o conteúdo da sua chave pública no campo "Key".
-
Clique em "Add SSH key".
Você pode testar a conexão SSH com o GitHub usando o seguinte comando:
ssh -T git@github.comSe tudo estiver configurado corretamente, você deve ver uma mensagem dizendo que você se autenticou com sucesso.
Para adicionar dois repositórios remotos ao mesmo projeto, você pode seguir os passos abaixo:
Se você ainda não adicionou um repositório remoto ao seu projeto, você pode fazer isso com o comando git remote add. Por exemplo:
git remote add origin git@github.com:User/Repo1.gitPara adicionar um segundo repositório remoto, você pode usar o mesmo comando, mas com um nome diferente para o remote. Por exemplo:
git remote add second git@github.com:User/Repo2.gitPara verificar se os remotes foram adicionados corretamente, você pode usar o comando git remote -v. Isso deve listar ambos os repositórios remotos.
Agora, quando você quiser fazer push para ambos os repositórios, você pode fazer isso com dois comandos:
git push origin main
git push second mainOu, se você quiser fazer push para ambos os repositórios ao mesmo tempo, você pode usar o operador && para concatenar os dois comandos:
git push origin main && git push second mainLembre-se de substituir "main" pela branch que você deseja fazer push.