| ... | ... | @@ -46,4 +46,20 @@ No exemplo acima, o verbo "Adiciona" é utilizado para indicar que uma nova func |
|
|
|
|
|
|
|
### Recursos Adicionais
|
|
|
|
|
|
|
|
Para saber mais sobre Conventional Commits, visite o site oficial dos Conventional Commits. |
|
|
\ No newline at end of file |
|
|
|
Para saber mais sobre Conventional Commits, visite o site oficial dos Conventional Commits.
|
|
|
|
|
|
|
|
## Padrões de Branch
|
|
|
|
Para nosso fluxo de trabalho, usamos a branch `main` como a branch de produção principal. Nenhuma alteração direta deve ser feita nessa branch, exceto quando estivermos prontos para fazer um release.
|
|
|
|
Para desenvolver novas funcionalidades e corrigir bugs, usamos a branch `develop` como nossa branch principal de desenvolvimento. A partir daqui, criamos novas branches para cada tarefa que precisa ser trabalhada.
|
|
|
|
|
|
|
|
* **feat**: Features novas.
|
|
|
|
* **fix**: Ajustes na aplicação.
|
|
|
|
* **chore ou arch**: Atualizações que não impactam na parte lógica da aplicação, e sim na arquitetura e organização.
|
|
|
|
|
|
|
|
O nome dessas branches devem seguir o padrão `feat/id-task/nome-da-feature`, `fix/id-task/nome-do-fix` ou `chore/id-task/objetivo-da-atualização`.
|
|
|
|
|
|
|
|
Exemplo: `feat/1234/adiciona-botao`.
|
|
|
|
|
|
|
|
**Importante:** Caso você não siga esses padrões, seus commits serão automaticamente rejeitados.
|
|
|
|
|
|
|
|
Ao final da sprint, todas as branches de feature e fixes devem ser revisadas e mescladas com a branch `develop` para integrar todas as alterações realizadas. Então, quando estamos prontos para fazer um release, a branch `main` é atualizada com a última versão de `develop` e o código é lançado para produção. |
|
|
\ No newline at end of file |
