Padrões para desenvolvimento
This commit is contained in:
132
README.md
Normal file
132
README.md
Normal file
@ -0,0 +1,132 @@
|
||||
# Conventional Commits + Semantic Release
|
||||
|
||||
Este guia resume como utilizar o padrão **Conventional Commits** em conjunto com o **Semantic Release** para automatizar versionamento, changelog e publicação.
|
||||
|
||||
---
|
||||
|
||||
## ✅ 1. Conventional Commits
|
||||
|
||||
### Formato básico:
|
||||
|
||||
```
|
||||
<tipo>(escopo opcional): <mensagem breve>
|
||||
```
|
||||
|
||||
### Tipos mais comuns:
|
||||
|
||||
- `feat`: nova funcionalidade
|
||||
- `fix`: correção de bug
|
||||
- `chore`: manutenção (sem impacto em produção)
|
||||
- `docs`: mudanças na documentação
|
||||
- `style`: formatação (semântica intacta)
|
||||
- `refactor`: refatoração (sem correções ou novas features)
|
||||
- `test`: testes adicionados/modificados
|
||||
- `perf`: melhorias de performance
|
||||
- `build`: mudanças no processo de build
|
||||
- `ci`: mudanças em CI/CD
|
||||
|
||||
### Exemplos:
|
||||
|
||||
```bash
|
||||
feat(api): adiciona endpoint de login
|
||||
fix(login): corrige bug de token inválido
|
||||
docs(readme): atualiza instruções de instalação
|
||||
```
|
||||
|
||||
> Padrão essencial para ferramentas como Semantic Release funcionarem corretamente.
|
||||
|
||||
---
|
||||
|
||||
## 🚀 2. Semantic Release
|
||||
|
||||
### O que faz:
|
||||
|
||||
1. Analisa commits com base em Conventional Commits
|
||||
2. Determina tipo de release (`major`, `minor`, `patch`)
|
||||
3. Gera changelog
|
||||
4. Publica release (npm, GitHub, etc.)
|
||||
5. Atualiza `package.json` com nova versão
|
||||
|
||||
### Regras de versionamento:
|
||||
|
||||
- `fix` → `patch` (ex: 1.0.0 → 1.0.1)
|
||||
- `feat` → `minor` (ex: 1.0.0 → 1.1.0)
|
||||
- `BREAKING CHANGE` → `major` (ex: 1.0.0 → 2.0.0)
|
||||
|
||||
---
|
||||
|
||||
## ⚙️ 3. Configuração prática
|
||||
|
||||
### 1. Instalar dependências
|
||||
|
||||
```bash
|
||||
npm install --save-dev semantic-release @semantic-release/changelog @semantic-release/git @semantic-release/github
|
||||
```
|
||||
|
||||
### 2. Arquivo `release.config.js`
|
||||
|
||||
```js
|
||||
module.exports = {
|
||||
branches: ['main'],
|
||||
plugins: [
|
||||
'@semantic-release/commit-analyzer',
|
||||
'@semantic-release/release-notes-generator',
|
||||
'@semantic-release/changelog',
|
||||
'@semantic-release/npm',
|
||||
'@semantic-release/github',
|
||||
[
|
||||
'@semantic-release/git',
|
||||
{
|
||||
assets: ['CHANGELOG.md', 'package.json'],
|
||||
message: 'chore(release): ${nextRelease.version} [skip ci]\n\n${nextRelease.notes}'
|
||||
}
|
||||
]
|
||||
]
|
||||
};
|
||||
```
|
||||
|
||||
### 3. GitHub Actions: `.github/workflows/release.yml`
|
||||
|
||||
```yaml
|
||||
name: Release
|
||||
|
||||
on:
|
||||
push:
|
||||
branches:
|
||||
- main
|
||||
|
||||
jobs:
|
||||
release:
|
||||
runs-on: ubuntu-latest
|
||||
steps:
|
||||
- uses: actions/checkout@v4
|
||||
- uses: actions/setup-node@v4
|
||||
with:
|
||||
node-version: '20'
|
||||
- run: npm ci
|
||||
- run: npx semantic-release
|
||||
env:
|
||||
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 📌 Dicas finais
|
||||
|
||||
- Evite `git commit -m "atualização"` — use `feat`, `fix`, etc.
|
||||
- Facilite com o **Commitizen**:
|
||||
|
||||
```bash
|
||||
npm install --save-dev commitizen
|
||||
npx commitizen init cz-conventional-changelog --save-dev --save-exact
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 🧩 Recursos opcionais
|
||||
|
||||
- Monorepos: use `@semantic-release/monorepo` ou ferramentas como `nx-release`
|
||||
- Changelog manual: configure o plugin `@semantic-release/changelog`
|
||||
|
||||
---
|
||||
|
||||
Reference in New Issue
Block a user