Para uma boa documentação são necessários os arquivos
- package.json: São guardadas informações sobre o tipo da licença, nome do projeto, versão etc, para projetos Node.js
- LICENSE: Arquivo contendo a licença do do projeto
- README.MD: Esse é o arquivo principal, o que contém a descrição do projeto com fotos, etc. É o que o GitHub lê e mostra como página inicial do projeto. Para se inspirar veja esse modelo
- CHANGELOG.MD: Arquivo contendo todo o log de mudanças de acordo com as versões, obedece um padrão, descrito em keep a changelog
Passo a passo para publicar e fazer mudanças (atualizações dos projetos)
Antes de fazer um novo commit siga os passos abaixo:
- Altere o
README.MD
com as informações que achar necessário sobre a nova versão - Altere o arquivo
CHANGELOG.MD
com a nova versão do commit e adições, alterações e exclusões realizadas - Altere o arquivo
package.json
(campo "version") com a nova versão do commit
Agora vamos para a linha de comando para atualizar tudo
Git local
git add .
git commit -m "Adições, alterações e exclusões realizadas"
Tags
Se for o caso de nova versão do sistema, (por exemplo: 1.0.1, 1.5.22), é possível adicionar a tag para essa versão, usando o comando:
git tag -a <tag_name> <commit_sha> -m "message"
Para pegar o <commit_sha>
use o git log
git log --oneline
Então o comando ficaria mais ou menos assim:
git tag -a 1.0.0 cab6e1b -m "Versão 1.0.0"
Para usar o último commit para cadastrar a tag, você pode substituir o <commit_sha>
por HEAD
git tag -a 1.0.0 HEAD -m "Versão 1.0.0"
Para remover uma tag, use o comando:
git tag -d <tag_name>
Parar de seguir um arquivo
Se você quiser parar de seguir um arquivo, por exemplo, um arquivo de configuração que você não quer que seja enviado para o repositório, use o comando:
git update-index --skip-worktree <file_name>
Para voltar a seguir o arquivo, use o comando:
git update-index --no-skip-worktree <file_name>
Alterando um Commit
Após fazer podemos esquecer de adicionar um arquivo e querer modificar um commit, então vamos adicionar um arquivo que você esqueceu no commit anterior. Primeiro faça obtenha o hash
com o log. Vamos aos passos:
git log --oneline
A saida será parecida com bf49b83 Texto do último commit realizado
ou seja hash commit
copie o hash e dê um reset nele com o comando:
git reset bf49b83
Ao fazer isso, os arquivos desse commit voltam para a stage area, adicione outros arquivos que você tinha especido de comitar.
git add ./arquivo-que-voce-esqueceu-de-commitar.php
E dê um commit novamente para com a opção --amend
git commit --amend -m "Mensagem do commit que pode ser alterada"
Se não quiser alterar a mensagem do commit, basta rodar o comando abaixo
git commit --amend --no-edit
Atualizando no GitHub
Para atualizar no GitHub, rode o comando abaixo
git push origin main
Lembrando que assim que você cria o projeto no GitHub ele dá os comandos para você rodar na pasta local do projeto, vinculando essa pasta com o seu projeto no site do GitHub.
Atualizando as tags no GitHub
As tags não são atualizadas automaticamente, para isso, rode o comando abaixo:
git push origin --tags
Se preferir pode enviar apenas uma tag
git push origin 1.0.0
Ou você pode usar os comandos abaixo para criar tags através do CLI do GiHub
Rodar o comando abaixo para que seja criado um novo release do projeto (uma nova versão) no GitHub com a geração das notas sobre a versão geradas automaticamente pelo GitHub.
gh release create 1.0.0 --generate-notes
Caso queira especificar as notas da versão use o comando abaixo:
gh release create 1.0.0 --notes "Notas da versão, como: Versão 1.0.0, ou corrigidos bugs e adicionadas features"
O comando gh só está disponível depois de instalar o GitHub CLI
Marketplace da Microsoft
Caso o projeto esteja disponível no Marketplace da Microsoft (como um tema para o vscode) rodar o comando abaixo para publicar também no Marketplace da Microsoft
vsce publish
Para saber como publicar um novo tema para VSCode acesse esse tutorial, lembrando que caso ele não esteja mais disponível no momento da visita, acesse o https://archive.org/ para obter uma cópia.
Preparando a próxima publicação
No arquivo CHANGELOG.MD crie a nova versão para ir adicionando as alterações futuras a medida que elas forem acontecendo
Como nomear os commits de forma organizada
Seguindo o padrão de conventional commits os commits devem ser nomeados da seguinte forma:
[escopo]: descrição
Por exemplo:
- Feature/Funcionalidades: Usado para criação de novas funcionalidades, endpoints, services e et
- Fix/Correções: Usado para correção de bugs
- Refactor/Refatorações: Usado para refatoração (melhorias) de código
- Chore/Melhorias: Usado para melhorias que não afetam o código em si, como adição de comentários, alterações no .gitignore, README.md, .htaccess e etc
- Perf/Performance: Usado para alterações que impactam no desempenho do projeto
- Build/Build: Usado para alterações que impactam apenas o build do projeto, como criação de arquivos de configuração de deploy, etc
- Style/Layout: Usado para alterações que não afetam o código em si, como espaçamentos, indentação, etc
- Test/Testes: Usado para criação ou modificação de testes automatizados
- Docs/Documentação: Usado para alterações na documentação do projeto