4. Controle de Versão

O controle de versão é fundamental para gerenciar o código-fonte de nossos projetos de forma eficiente e colaborativa. Utilizamos o Git como nosso sistema de controle de versão distribuído.

4.1. Sistema de controle de versão (Git)

Git é uma ferramenta poderosa que nos permite rastrear mudanças no código, colaborar com outros desenvolvedores e gerenciar diferentes versões de nosso software.

Conceitos básicos do Git:

• Repositório: O local onde o Git armazena todo o histórico do projeto.
• Commit: Uma "fotografia" do seu código em um determinado momento.
• Branch: Uma linha independente de desenvolvimento.
• Remote: Uma versão do repositório hospedada em um servidor (como GitHub ou GitLab).

Comandos essenciais do Git:

git clone <url>           # Clonar um repositório
git status                # Verificar o estado atual do repositório
git add <arquivo>         # Adicionar arquivos para serem commitados
git commit -m "mensagem"  # Criar um novo commit
git push                  # Enviar commits para o repositório remoto
git pull                  # Atualizar o repositório local com mudanças do remoto
git branch                # Listar branches
git checkout -b <branch>  # Criar e mudar para uma nova branch

4.2. Fluxo de trabalho com branches (GitFlow)

Adotamos uma versão modificada do GitFlow para gerenciar nossos branches. Este fluxo de trabalho nos ajuda a organizar o desenvolvimento, especialmente considerando nossos múltiplos ambientes.

Estrutura de branches:

• prod: Representa o código em produção.
• hom: Branch principal de desenvolvimento.
• feature/*: Branches para novas funcionalidades.
• hotfix/*: Branches para correções urgentes em produção.
• release/*: Branches para preparação de novas releases.

Fluxo de trabalho:

1. Desenvolvedores criam feature branches a partir de hom.
2. Ao concluir, abrem um Pull Request para hom.
3. Após revisão e aprovação, a feature é mesclada em hom.
4. Para preparar uma release, cria-se um branch release a partir de hom.
5. Após testes em homologação, a release é mesclada em prod e hom.
6. Para correçes urgentes, cria-se um hotfix a partir de prod, que é mesclado de volta para prod e hom.

4.3. Convenções para mensagens de commit (Conventional Commits)

Adotamos o padrão Conventional Commits para nossas mensagens de commit. Isso ajuda a manter um histórico claro e facilita a geração automática de changelogs.

Estrutura básica:

<tipo>[escopo opcional]: <descrição>

[corpo opcional]

[rodapé(s) opcional(is)]

Tipos comuns:

• feat: Nova funcionalidade
• fix: Correção de bug
• docs: Alterações na documentação
• style: Alterações que não afetam o significado do código (espaços em branco, formatação, etc.)
• refactor: Refatoração de código
• test: Adição ou correção de testes
• chore: Alterações no processo de build ou ferramentas auxiliares

Exemplo:

feat(auth): implementar autenticação via Google

- Adiciona endpoint para autenticação OAuth
- Integra com o serviço Google Identity

Closes #123

4.4. Estratégias de merge e rebase

Utilizamos diferentes estratégias dependendo do contexto:

1. Merge: Usado para integrar feature branches em hom. Preserva o histórico completo.

   git checkout hom
   git merge --no-ff feature/nova-funcionalidade

2. Rebase: Recomendado para atualizar feature branches com as últimas mudanças de hom. Mantém o histórico linear.

   git checkout feature/nova-funcionalidade
   git rebase hom

3. Squash and merge: Usado ao mesclar release branches em prod, condensando todos os commits da release em um único commit.

   git checkout prod
   git merge --squash release/1.0.0
   git commit -m "Release 1.0.0"

4.5. Gerenciamento de tags e releases

Tags são usadas para marcar pontos específicos no histórico, geralmente releases.

Processo de release:

1. Criar e finalizar o branch release/x.y.z.

2. Mesclar em prod e hom.

3. Criar uma tag na prod:

   git checkout prod
   git pull
   git tag -a v1.0.0 -m "Release 1.0.0"
   git push origin v1.0.0

4. Atualizar a versão nos arquivos de configuração do projeto.

Nomenclatura de tags: Seguimos o Semantic Versioning (SemVer): v<major>.<minor>.<patch>

• major: Mudanças incompatíveis com versões anteriores
• minor: Novas funcionalidades compatíveis com versões anteriores
• patch: Correções de bugs compatíveis com versões anteriores

Observações importantes:

1. Sincronização de ambientes: É responsabilidade do líder técnico garantir que os ambientes (homologação, staging e produção) estejam sincronizados e funcionando corretamente.

2. Code review: Todas as mudanças destinadas à produção devem passar por um processo de revisão de código. A aprovação final para subir para produção é responsabilidade do CTO.

3. Boas práticas:

   • Faça commits frequentes e pequenos.
   • Mantenha os brancheFs atualizados com hom.
   • Sempre faça pull antes de começar a trabalhar.
   • Não faça force push em branches compartilhados.
   • Use .gitignore para excluir arquivos desnecessários.

4. Resolução de conflitos: Ao encontrar conflitos durante um merge ou rebase, resolva-os localmente e teste bem antes de fazer push.

5. Proteção de branches: Configurar proteções no GitHub/GitLab para prod e hom, exigindo pull requests e aprovações antes de merges.

Lembre-se, o Git é uma ferramenta poderosa, mas requer prática. Não hesite em pedir ajuda a colegas mais experientes se encontrar dificuldades. Manter um fluxo de trabalho Git consistente é crucial para o sucesso de nossos projetos e a eficiência de nossa equipe.

** Avise o RH imediatamente com o seguinte codigo: OMP-01 via Discord ao ler esta mensagem**