Welcome to MkDocs
Git e Github
Git e Github são ferramentas de versionamento de código. Assista e esse vídeo e leia isso aqui para entendermais sobre github e como instalar a CLI do Github.
Dessa forma conseguimos configurar nosso projeto com o comando
gh repo create
Pyenv
O Pyenv é uma ferramenta poderosa para gerenciar múltiplas versões do Python. Com ela, é possível instalar várias versões do Python e alternar entre elas de maneira flexível e eficiente. Isso é especialmente útil em projetos que exigem versões específicas do Python, garantindo compatibilidade e evitando conflitos. A instalação e o uso do Pyenv são simples, tornando a gestão de versões do Python uma tarefa descomplicada para desenvolvedores de todos os níveis.
Os principais comandos são:
pyenv versions
pyenv local 3.11.5
pyenv global 3.11.5
Poetry (tipo PIP)
Poetry simplifica o gerenciamento de dependências e pacotes no Python, substituindo o PIP. Os principais comandos são:
Inicia um novo projeto interativamente
poetry init
Inicia um novo projeto interativamente
poetry add [pacote]
Remove uma dependência do projeto.
poetry remove [pacote]
Ativa o ambiente virtual do projeto.
poetry shell
Arquivo .gitignore e versionando o que temos até aqui
Aquecimento
Crie um arquivo
- Git add
- Git commit
- Git push
- Git pull
Seu chefe mandou deletar
- Git rm
Seu chefe mandou voltar
- Git log
- Git revert
Adicionar arquivo CSV
- Git add
- Git commit
E agora?
Mudar o nome disso tudo
- Git reset -hard
- Git rebase -i --root
- Git commit –amend
- Git rebase –continue
Pre-commit
- check-yaml
- black (formatador) Nomes bonito-s
- check-added-large-files
- commitizen
# .pre-commit-config.yaml
repos:
- repo: https://github.com/pre-commit/pre-commit-hooks
rev: v4.5.0
hooks:
- id: check-yaml
- repo: https://github.com/psf/black
rev: 23.12.1
hooks:
- id: black
- repo: https://github.com/pre-commit/pre-commit-hooks
rev: v4.5.0 # Use a versão mais recente
hooks:
- id: check-added-large-files
args: ['--maxkb=500'] # Define o tamanho máximo permitido
- repo: https://github.com/commitizen-tools/commitizen
rev: v3.13.0
hooks:
- id: commitizen
stages: [commit-msg]
Boas práticas de commit
1) Commits atômicos: evite dar git add .
A prática de criar commits atômicos consiste em criar um commit para cada modificação no projeto, por exemplo, vamos imaginar que estamos trabalhando em um projeto e fizemos duas ações: - criamos um novo componente - fizemos alterações em um já existente
Em vez de criarmos um único commit para guardar as alterações que fizemos, faremos dois commits, seguindo um padrão de commits atômicos. O primeiro commit será com os arquivos envolvidos na criação do novo componente, e o segundo com as alterações feitas em um componente já existente.
Dessa maneira conseguimos escrever uma mensagem mais descritiva para o commit, as ações na linha do tempo ficam mais descritivas e é mais prático navegar pelos commits visualizando as modificações. Na ocorrência de um bug no projeto, é bem mais fácil de encontrar em qual commit ele foi inserido e reverter o que foi feito.
2) Padronização dos commits
Outra prática muito importante e que está ligada a anterior é a padronização das mensagens dos commits, dessa maneira seguimos uma estrutura na hora de escrevermos as mensagens, o que deixa os commits estruturados e padronizados.
Exemplos para feat (novas funcionalidades ou adições):
Adicionando uma nova funcionalidade a um script Python: feat(script): adicionar capacidade de processamento de dados em batch no process_data.py feat(api): implementar nova rota de autenticação no server.py Adicionando novos componentes em um projeto frontend: feat(frontend): adicionar novo componente de slider na homepage feat(ui): introduzir botão de compartilhamento social no post_view.jsx Incluindo scripts de automação ou utilitários: feat(utils): adicionar script para limpeza automática de logs feat(automation): criar ferramenta de deployment automatizado Expandindo funcionalidades de um aplicativo móvel: feat(mobile): implementar notificações push para iOS feat(app): adicionar suporte para tema escuro
Exemplos para fix (correções de bugs ou problemas):
Corrigindo um bug em um script Python: fix(parser): corrigir erro de parsing de datas no import_data.py fix(api): resolver falha na autenticação em casos específicos no auth.py Resolvendo problemas de interface de usuário: fix(frontend): ajustar layout quebrado em telas pequenas na homepage.css fix(ui): corrigir cor de texto ilegível no modo escuro em settings.css Correções em scripts de automação ou utilitários: fix(build): resolver dependência faltante no script de build fix(deploy): corrigir caminho de acesso no script de deployment Correções de bugs em aplicativos móveis: fix(mobile): corrigir crash ao abrir notificações no Android fix(app): resolver problema de sincronização de dados em background
Lembrando que é importante que a mensagem do commit seja clara e descreva especificamente o que foi alterado e por que a alteração foi necessária. Isso ajuda outros colaboradores do projeto a entender o contexto e o propósito das mudanças feitas.
Mudanças no .gitignore
Quando você está adicionando algo ao .gitignore: chore(gitignore): adicionar arquivos de log chore(gitignore): ignorar arquivos de ambiente virtual Quando você está removendo algo do .gitignore: chore(gitignore): remover entradas obsoletas chore(gitignore): permitir arquivos de configuração de IDE
Mudanças no pyproject.toml
Para atualizações de dependências: build(deps): atualizar dependências fix(deps): corrigir versões de dependências para compatibilidade Para adicionar novas dependências: feat(deps): adicionar biblioteca requests feat(deps): incluir pytest para testes Para mudanças na configuração do projeto: build(pyproject): configurar ferramentas de linting build(pyproject): ajustar configurações de empacotamento
Explicando os Prefixos:
feat: Uma nova funcionalidade para o usuário, não uma nova funcionalidade para scripts de build. fix: Correção de bug para o usuário, não uma correção para scripts de build. build: Mudanças que afetam o sistema de build ou dependências externas (exemplo: scopes: gulp, broccoli, npm). chore: Atualizações no processo de build, alterações em ferramentas auxiliares e bibliotecas como documentação gerada. Esses prefixos ajudam a categorizar o tipo de mudança que está sendo feita, tornando mais fácil para outros desenvolvedores entenderem rapidamente o impacto de cada commit no projeto.
Mkdocs
1. Instalação do MkDocs
Primeiro, você precisa instalar o MkDocs. Como seu projeto usa Poetry para gerenciamento de dependências, você pode adicionar o MkDocs como uma dependência de desenvolvimento:
poetry add mkdocs --dev
Isso garantirá que o MkDocs seja instalado no ambiente virtual do seu projeto.
2. Configuração Inicial
Após a instalação, você pode criar um novo site de documentação com MkDocs:
poetry run mkdocs new .
Isso criará um novo arquivo mkdocs.yml e uma pasta docs no diretório raiz do seu projeto. O arquivo mkdocs.yml é usado para configurar seu site de documentação, enquanto a pasta docs conterá os arquivos Markdown da sua documentação.
3. Personalização da Configuração
Edite o arquivo mkdocs.yml para personalizar a configuração do seu site de documentação. Por exemplo:
site_name: Nome do seu Projeto
nav:
- Home: index.md
- Sobre: about.md
4. Adicionando Conteúdo
Adicione ou edite arquivos Markdown na pasta docs para criar o conteúdo da sua documentação. Por exemplo, você pode começar editando docs/index.md.
5. Visualização Local
Para visualizar a documentação localmente, execute:
poetry run mkdocs serve
Isso iniciará um servidor local, e você poderá visualizar sua documentação navegando para http://127.0.0.1:8000/ no seu navegador.
6. Construção do Site
Quando estiver pronto para construir o site da documentação, use:
poetry run mkdocs build
Isso gerará uma versão estática do seu site na pasta site que pode ser hospedada em qualquer servidor web.
7. Atualização do README
Não se esqueça de atualizar o README.md do seu projeto para incluir informações sobre a documentação e como visualizá-la ou construí-la localmente.
8. Commit e Push
Finalmente, faça commit das mudanças no seu repositório Git e faça push para o GitHub:
git add mkdocs.yml docs/
git commit -m "feat: adicionar mkdocs para documentação do projeto"
git push
9. Deploy
Agora faça o Deploy
mkdocs gh-deploy
Project layout
mkdocs.yml # The configuration file.
docs/
index.md # The documentation homepage.
... # Other markdown pages, images and other files.