You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Seja bem-vindo e obrigado por considerar contribuir com este projeto! Ler e seguir nossas diretrizes vai te ajudar a entrar com mais rapidez em nosso fluxo de trabalho, além tornar o processo de contribuição mais fácil e eficaz. Contamos com seu apoio!
15
+
Obrigado por considerar contribuir com este projeto! Seguir nossas diretrizes facilitará seu onboarding e tornará sua colaboração mais eficaz.
16
+
17
+
# Sumário
18
+
19
+
<details>
20
+
<summary><strong>Expandir</strong></summary>
14
21
15
-
# Summary
22
+
<!-- START doctoc generated TOC please keep comment here to allow auto update -->
23
+
<!-- DON'T EDIT THIS SECTION, INSTEAD RE-RUN doctoc TO UPDATE -->
16
24
17
-
-[Summary](#summary)
18
-
-[Práticas](#práticas)
25
+
-[Práticas](#pr%C3%A1ticas)
26
+
-[Geral](#geral)
27
+
-[Comunicação](#comunica%C3%A7%C3%A3o)
19
28
-[Setup](#setup)
20
29
-[DevBox](#devbox)
21
30
-[Direnv](#direnv)
@@ -29,16 +38,20 @@ Seja bem-vindo e obrigado por considerar contribuir com este projeto! Ler e segu
29
38
-[Reviewing](#reviewing)
30
39
-[Versioning Process](#versioning-process)
31
40
41
+
<!-- END doctoc generated TOC please keep comment here to allow auto update -->
42
+
32
43
<palign="right">(<ahref="#readme-top">back to top</a>)</p>
33
44
45
+
</details>
46
+
34
47
# Práticas
35
48
36
-
**Geral**
49
+
## Geral
37
50
38
51
- Se você não conseguir continuar uma tarefa, informe imediatamente sua equipe. A comunicação rápida evita atrasos e permite que outras pessoas te ajudem a resolver os problemas com mais rapidez.
39
52
- Não reinvente a roda. Se você pesquisou e viu que já existe uma solução bem estabelecida para o seu problema, use-a. Isso economiza tempo e recurso.
40
53
41
-
**Comunicação**
54
+
## Comunicação
42
55
43
56
- Minimize o uso de IA na comunicação diária com a equipe. Valorizamos interações reais e genuínas.
44
57
- Seja objetivo na sua comunição quando precisa de ajuda (isso não significa ser rude rsrs).
@@ -54,22 +67,24 @@ Para você começar a contribuir, é essencial configurar seu ambiente de trabal
54
67
-**Configurar variáveis de ambiente**: Ajuste as variáveis de ambiente para garantir que seu sistema esteja preparado para rodar o projeto.
55
68
-**Executar scripts de automação**: Rode os scripts fornecidos para configurar dependências, inicializar bancos de dados e outras tarefas automatizadas.
56
69
57
-
> [!NOTE] Lembre-se: cada projeto tem seu próprio contexto e necessidades!
70
+
> [!NOTE]
71
+
> Lembre-se: cada projeto tem seu próprio contexto e necessidades!
58
72
59
73
Pensando nisso, elaboramos as etapas abaixo para te guiar.
60
74
61
75
## DevBox
62
76
63
77
O **DevBox** é uma ferramenta CLI que cria ambientes de desenvolvimento isolados e reproduzíveis, sem precisar usar containers Docker ou a linguagem Nix de forma nativa.
64
78
65
-
> [!NOTE] Use essa opção se você não quiser instalar muitas ferramentas CLI diretamente em seu ambiente de trabalho.
79
+
> [!NOTE]
80
+
> Use essa opção se você não quiser instalar muitas ferramentas CLI diretamente em seu ambiente de trabalho.
66
81
67
82
Siga essas etapas para configurar seu ambiente:
68
83
69
84
- Instale o [devbox](https://www.jetify.com/devbox/docs/installing_devbox/):
70
85
71
86
```bash
72
-
curl -fsSL <https://get.jetpack.io/devbox>| bash
87
+
curl -fsSL https://get.jetpack.io/devbox | bash
73
88
```
74
89
75
90
- Inicialize seu projeto:
@@ -101,7 +116,8 @@ devbox shell
101
116
102
117
Com isso, podemos garantir que todos no projeto tenham as mesmas ferramentas nas mesmas versões, necessárias para o processo de desenvolvimento.
103
118
104
-
> [!NOTE] Se você precisar de mais detalhes sobre essa configuração, verifique o arquivo [devbox.json](devbox.json) do seu projeto. Caso não exista, crie ele seguindo o passo a passo descrito acima.
119
+
> [!NOTE]
120
+
> Se você precisar de mais detalhes sobre essa configuração, verifique o arquivo [devbox.json](devbox.json) do seu projeto. Caso não exista, crie ele seguindo o passo a passo descrito acima.
105
121
106
122
## Direnv
107
123
@@ -131,21 +147,24 @@ direnv allow
131
147
132
148
Seguindo essas etapas, quando você navegar para a pasta do seu projeto, as variáveis de ambiente serão carregadas automaticamente e o **DevBox** será inicializado.
133
149
134
-
> [!NOTE] Se você precisar de mais detalhes sobre esse configuração, verifique o arquivo [.envrc](.envrc) do seu projeto.
150
+
> [!NOTE]
151
+
> Se você precisar de mais detalhes sobre esse configuração, verifique o arquivo [.envrc](.envrc) do seu projeto.
135
152
136
153
## Task
137
154
138
155
A ferramenta **task** oferece uma maneira conveniente de definir e gerenciar tarefas específicas do projeto, facilitando a automatização de scripts comuns e simplificando os fluxos de trabalho de desenvolvimento.
139
156
140
-
> [!NOTE] É semelhante à ferramenta `make`, que é utilizada principalmente para automatizar tarefas.
157
+
> [!NOTE]
158
+
> É semelhante à ferramenta `make`, que é utilizada principalmente para automatizar tarefas.
141
159
142
160
Siga essas etapas para configurar seu ambiente:
143
161
144
162
- Certifique-se de que você instalou o comando `task` seguindo as etapas de configuração do **DevBox**.
145
163
- Caso não tenha seguido, acesse a documentação do [task](https://taskfile.dev/installation/) e siga as instruções para instalá-lo.
146
164
- Execute o comando `task` no diretório raiz do projeto para ver todos os comandos disponíveis.
147
165
148
-
> [!NOTE] Se você precisar de mais detalhes sobre cada tarefa definida, verifique o arquivo [Taskfile.yaml](Taskfile.yaml) do seu projeto. Caso não exista, crie ele seguindo o passo a passo descrito acima.
166
+
> [!NOTE]
167
+
> Se você precisar de mais detalhes sobre cada tarefa definida, verifique o arquivo [Taskfile.yaml](Taskfile.yaml) do seu projeto. Caso não exista, crie ele seguindo o passo a passo descrito acima.
149
168
150
169
<palign="right">(<ahref="#readme-top">back to top</a>)</p>
151
170
@@ -171,19 +190,19 @@ Veja como é organizado esse formato de commits:
171
190
172
191
Descreve o tipo de alteração do commit. Temos as seguintes opções:
173
192
174
-
| Tipo | Descrição |
175
-
| --- | --- |
176
-
|**feat**| Um novo recurso (adição de um novo componente, fornecimento de novas variantes para um componente existente, etc.). |
177
-
|**fix**| Uma correção de bug (correção de um problema de estilo, resolução de um bug na API de um componente etc.). Ao atualizar dependências que não sejam de desenvolvimento, marque suas alterações como `fix`. |
178
-
|**docs**| Alterações somente na documentação. |
179
-
|**style**| Alterações que não afetam o significado do código (espaços em branco, formatação, falta de ponto e vírgula etc.). Não deve ser usado para alterações na interface do usuário, pois essas são alterações significativas; em vez disso, considere usar `feat` ou `fix`. |
180
-
|**refactor**| Uma alteração de código que não corrige um bug nem adiciona um recurso. |
181
-
|**perf**| Uma alteração de código que melhora o desempenho. |
182
-
|**test**| Adição de testes ausentes ou correção de testes existentes. |
183
-
|**build**| Alterações que afetam o sistema de build. |
184
-
|**ci**| Alterações em arquivos e scripts de configuração de CI/CD. |
185
-
|**chore**| Outras alterações que não modificam arquivos de origem ou de teste. Use esse tipo ao adicionar ou atualizar dependências de desenvolvimento. |
|**feat**| Um novo recurso (adição de um novo componente, fornecimento de novas variantes para um componente existente, etc.).|
196
+
|**fix**| Uma correção de bug (correção de um problema de estilo, resolução de um bug na API de um componente etc.). Ao atualizar dependências que não sejam de desenvolvimento, marque suas alterações como `fix`.|
197
+
|**docs**| Alterações somente na documentação.|
198
+
|**style**| Alterações que não afetam o significado do código (espaços em branco, formatação, falta de ponto e vírgula etc.). Não deve ser usado para alterações na interface do usuário, pois essas são alterações significativas; em vez disso, considere usar `feat` ou `fix`. |
199
+
|**refactor**| Uma alteração de código que não corrige um bug nem adiciona um recurso. |
200
+
|**perf**| Uma alteração de código que melhora o desempenho.|
201
+
|**test**| Adição de testes ausentes ou correção de testes existentes.|
202
+
|**build**| Alterações que afetam o sistema de build.|
203
+
|**ci**| Alterações em arquivos e scripts de configuração de CI/CD.|
204
+
|**chore**| Outras alterações que não modificam arquivos de origem ou de teste. Use esse tipo ao adicionar ou atualizar dependências de desenvolvimento.|
205
+
|**revert**| Reverte um commit anterior.|
187
206
188
207
## Scope
189
208
@@ -193,24 +212,28 @@ Descreve o tipo de alteração do commit. Temos as seguintes opções:
193
212
feat(login): add route
194
213
```
195
214
196
-
> [!NOTE] Use a convenção [PascalCase](https://www.dio.me/articles/camel-case-vs-pascal-case) na hora de definir seu escopo (`scope`).
215
+
> [!NOTE]
216
+
> Use a convenção [PascalCase](https://www.dio.me/articles/camel-case-vs-pascal-case) na hora de definir seu escopo (`scope`).
197
217
198
218
## Description
199
219
200
220
É o campo onde você diz o que foi feito no commit, porém de forma breve. Para isso, recomendamos que:
201
221
202
222
- Priorize descrições em inglês.
203
-
- Use o imperativo, tempo presente: "change", não "changed" ou "changed".
223
+
- Use o imperativo, tempo presente: "change", não "changed" ou "changing".
204
224
- Não coloque a primeira letra em maiúscula.
205
225
- Não coloque ponto (.) no final.
206
226
207
-
> [!NOTE] Cada tipo de commit tem um efeito sobre a próxima release que você for lançar.
227
+
> [!NOTE]
228
+
> Cada tipo de commit tem um efeito sobre a próxima release que você for lançar.
229
+
230
+
Existem mais opções, porém essas são as mais comuns. Para mais detalhes, consulte a [documentação oficial](https://www.conventionalcommits.org/en/v1.0.0/).
208
231
209
232
<palign="right">(<ahref="#readme-top">back to top</a>)</p>
210
233
211
234
# MR Process
212
235
213
-
Ao criar um MR (merge request), é uma boa ideia definir o seu título seguindo a mesma convenção utilizada nas mensagens de commit. Dessa forma, se seu MR for sofrer um **squash** após a mesclagem, o maintainer poderá usar o título como a mensagem final do commit, criando um histórico formato, enxuto e linear.
236
+
Ao criar um Merge Request (MR), recomenda-se definir o título conforme a mesma convenção adotada para mensagens de commit. Isso garante que, em caso de **squash merge**, o título do MR possa ser diretamente utilizado como a mensagem final do commit, preservando a padronização do histórico. Essa prática contribui para um log de alterações mais estruturado, conciso e linear, facilitando a rastreabilidade e automação de releases em fluxos de desenvolvimento que seguem padrões como **Conventional Commits**.
Seguir este processo garante que as alterações sejam revisadas adequadamente e que o código de produção permaneça estável e com qualidade.
260
283
261
-
> [!NOTE] Se você tiver vários commits em seu PR que resolvem o mesmo problema, **squash os commits**.
284
+
> [!NOTE]
285
+
> Se você tiver vários commits em seu PR, é recomendável usar a opção de squash para manter um histórico limpo e organizado.
262
286
263
287
## Reviewing
264
288
265
289
Durante o processo de revisão do MR, siga essas políticas:
266
290
267
291
- Seja respeitoso e construtivo.
268
-
-Sempre realize a revisão em pares.
292
+
-Busque realizar um code review completo, verificando a lógica, a qualidade do código e a conformidade com os padrões estabelecidos.
269
293
- Sugira alterações em vez de simplesmente comentar os problemas encontrados.
270
294
- Exigimos pelo menos um aprovador no MR, que não seja o autor.
271
295
- Se não tiver certeza sobre algo, pergunte ao autor do MR.
272
296
- Se você estiver satisfeito com as alterações, aprove o MR.
297
+
- Preze por pair programming, sempre que possível.
273
298
274
299
<palign="right">(<ahref="#readme-top">back to top</a>)</p>
275
300
276
301
# Versioning Process
277
302
278
-
Este projeto segue a especificação [SemVer](https://semver.org/). Consulte a documentação para obter mais detalhes.
303
+
Esse projeto segue a especificação [SemVer](https://semver.org/). Ou seja, utilizamos um sistema de versionamento semântico para controlar as versões do projeto. Isso nos ajuda a comunicar melhor as mudanças feitas no código e a garantir a compatibilidade entre as versões. Esse sistema é composto por três números (`x.x.x`), que representam respectivamente:
304
+
305
+
1.**Major**: Quando fazemos alterações incompatíveis com a versão atual. Ex: `1.2.0 → 2.0.0`
306
+
2.**Minor**: Quando adicionamos funcionalidades de forma compatível com a versão atual. Ex: `1.2.0 → 1.3.0`
307
+
3.**Patch**: Quando corrigimos bugs de forma compatível com a versão atual. Ex: `1.2.0 → 1.2.1`
308
+
309
+
Nós usamos o [Semantic Release](https://semantic-release.gitbook.io/semantic-release/) para automatizar esse processo de versionamento. Ele analisa os commits desde a última versão e determina automaticamente o próximo número da versão com base nas alterações feitas. Isso garante que as versões sejam consistentes e sigam as regras do SemVer.
310
+
311
+
Vale ressaltar que o Semantic Release é acionado automaticamente quando um MR é mesclado na branch `main` ou quando existe um commit direto na branch `main`. Portanto, é importante seguir as convenções de commit para garantir que as versões sejam geradas corretamente.
312
+
313
+
> [!NOTE]
314
+
> O Semantic Release é um ferramental poderoso, e possui um sistema de plugins que podem ser configurados para atender as necessidades específicas do projeto. Para mais detalhes, consulte a [documentação oficial](https://semantic-release.gitbook.io/semantic-release/).
279
315
280
316
<palign="right">(<ahref="#readme-top">back to top</a>)</p>
0 commit comments