From 5477c0aa38a0bb670e80e3884623d0b0bfbfb14b Mon Sep 17 00:00:00 2001 From: daniel_tadashi Date: Tue, 2 Sep 2025 20:51:15 -0300 Subject: [PATCH 1/2] =?UTF-8?q?Anota=C3=A7=C3=B5es=20de=20aula=20-=20regis?= =?UTF-8?q?tradas=20no=20MD?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- anotacoes_aula.md | 448 ++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 448 insertions(+) create mode 100644 anotacoes_aula.md diff --git a/anotacoes_aula.md b/anotacoes_aula.md new file mode 100644 index 0000000..94b1349 --- /dev/null +++ b/anotacoes_aula.md @@ -0,0 +1,448 @@ +Controle de Versionamento (Processos) +O que são ferramentas de controles de versão? +Com certeza. Já que estabelecemos o conceito de controle de versão, agora vamos falar sobre as aplicações que colocam esse conceito em prática. +Ferramentas de Controle de Versão (ou VCS - Version Control Systems) são os programas de software que os desenvolvedores usam para gerenciar o histórico e a colaboração em um projeto. São as aplicações que executam todas as tarefas que discutimos: rastrear mudanças, permitir o trabalho em equipe e manter um registro completo de cada versão. +Pense nelas como a "caixa de ferramentas" do engenheiro de software para a construção e manutenção do código. Em vez de gerenciar arquivos manualmente (ex: codigo_v1.java, codigo_v2.java), o desenvolvedor usa comandos específicos dessas ferramentas para interagir com o repositório do projeto de forma segura e organizada. +O que Essas Ferramentas Fazem? +As funcionalidades essenciais que todas essas ferramentas oferecem são: +1. Inicializar um Repositório: Transformar uma pasta comum em um repositório rastreado. +2. Registrar Alterações (Commit): Salvar um "snapshot" (uma foto) do estado atual dos arquivos no histórico. +3. Visualizar o Histórico (Log): Listar todos os commits feitos, mostrando quem os fez, quando e por quê. +4. Criar Ramificações (Branch): Criar linhas de desenvolvimento paralelas para trabalhar em novas funcionalidades ou correções sem afetar a versão principal. +5. Fundir Ramificações (Merge): Integrar o trabalho de um branch de volta à linha principal. +6. Reverter para Versões Anteriores: Desfazer alterações ou voltar o projeto inteiro para um estado anterior. +7. Sincronizar com Outros (Push/Pull): Em sistemas distribuídos, enviar suas alterações para um repositório compartilhado ou baixar as alterações de outros membros da equipe. + Exemplos das Ferramentas Mais Importantes + As ferramentas são divididas nos dois modelos que discutimos: centralizado e distribuído. +1. Ferramentas Distribuídas (DVCS) - O Padrão Moderno +- Git: + - Descrição: É a ferramenta de controle de versão mais dominante e popular do mundo. Lançado em 2005 por Linus Torvalds (o criador do Linux), o Git é conhecido por sua velocidade, eficiência e, principalmente, por suas capacidades extraordinárias de branching e merging, que o tornam ideal para projetos de qualquer tamanho, desde um trabalho individual até colaborações com milhares de desenvolvedores. + - Quem usa: Praticamente toda a indústria de software moderna. Google, Microsoft, Facebook, Amazon e milhões de outros. +- Mercurial (Hg): + - Descrição: Outro sistema distribuído poderoso e o principal concorrente do Git no passado. É conhecido por ter uma curva de aprendizado um pouco mais suave e comandos mais intuitivos para iniciantes. + - Quem usa: Era usado por grandes empresas como o Facebook (que contribuiu muito para seu desenvolvimento), mas hoje seu uso diminuiu significativamente em favor do Git. +2. Ferramentas Centralizadas (CVCS) - O Modelo Legado +- Apache Subversion (SVN): + - Descrição: Foi o rei do controle de versão antes da ascensão do Git. Como um sistema centralizado, seu modelo é mais simples de entender, mas menos flexível. O branching e merging no SVN são operações muito mais lentas e complexas do que no Git. + - Quem usa: Ainda é encontrado em empresas mais antigas, projetos de longa data e em ambientes corporativos que preferem seu modelo de controle de acesso mais rígido. + Ferramentas vs. Plataformas de Hospedagem + É crucial fazer uma distinção importante: +- A Ferramenta: Git é o software que você instala e executa no seu computador. +- A Plataforma de Hospedagem: GitHub, GitLab e Bitbucket são serviços web que hospedam repositórios Git. + Essas plataformas são construídas em cima do Git e adicionam uma camada de funcionalidades essenciais para a colaboração, como: +- Interface gráfica na web para visualizar o código. +- Ferramentas de revisão de código (Pull Requests / Merge Requests). +- Gerenciamento de projetos (kanban boards, issue tracking). +- Integração com sistemas de automação (CI/CD). + Em resumo, as ferramentas de controle de versão como o Git são o motor fundamental que rastreia as mudanças, enquanto as plataformas como o GitHub são o "clube social" e a "oficina" onde as equipes se reúnem para usar esse motor e construir software juntas. + Quais são os objetivos da ferramenta de controle de versão? + Excelente pergunta. Chegamos ao "porquê" fundamental da existência dessas ferramentas. Enquanto a função delas é o que elas fazem (commits, branches, merges), os objetivos são a razão pela qual essas funções são tão indispensáveis. + Os objetivos das ferramentas de controle de versão podem ser organizados em cinco pilares estratégicos que sustentam todo o processo de desenvolvimento de software moderno. +1. Facilitar a Colaboração em Larga Escala + Este é o objetivo primordial. Antes dos VCS, o desenvolvimento de software por mais de uma pessoa era um pesadelo logístico. +- O Objetivo: Permitir que múltiplos desenvolvedores, possivelmente distribuídos geograficamente, trabalhem no mesmo projeto de forma simultânea, paralela e segura, sem interferir negativamente no trabalho uns dos outros. +- Como é Alcançado: Através de funcionalidades como branching, que cria ambientes de trabalho isolados, e merging, que fornece um processo estruturado para integrar as contribuições de todos em uma base de código unificada e coerente. +2. Manter um Histórico Completo e Rastreável + O desenvolvimento de software é um processo evolutivo. Entender essa evolução é crucial para a manutenção e a qualidade do produto. +- O Objetivo: Criar um registro imutável, detalhado e auditável de cada mudança já feita no projeto. O sistema deve ser capaz de responder, para qualquer linha de código, às perguntas: quem a escreveu, quando foi escrita e, mais importante, por que foi escrita. +- Como é Alcançado: Cada commit atua como uma entrada em um diário. Ele armazena o "quê" (a mudança no código), o "quem" e o "quando". A mensagem de commit fornece o "porquê", que é o contexto de negócio ou técnico da alteração. +3. Prover uma Rede de Segurança e Mitigar Riscos + Erros são inevitáveis no desenvolvimento de software. O que diferencia uma equipe amadora de uma profissional é como ela lida com esses erros. +- O Objetivo: Garantir que o projeto possa ser rapidamente recuperado de erros, falhas ou decisões ruins. O sistema deve funcionar como uma "máquina do tempo", permitindo que a equipe desfaça alterações problemáticas ou retorne a um estado anterior sabidamente estável. +- Como é Alcançado: Como todo o histórico é salvo, o VCS permite reverter um commit específico ou restaurar o projeto inteiro para um ponto no tempo anterior com comandos simples. Isso transforma um erro potencialmente catastrófico em um inconveniente gerenciável. +4. Suportar o Desenvolvimento Não Linear + O desenvolvimento de software raramente é uma linha reta. É preciso gerenciar múltiplas versões, correções de bugs e novas funcionalidades ao mesmo tempo. +- O Objetivo: Permitir que a equipe gerencie múltiplas "realidades" do código simultaneamente. Por exemplo, manter a versão estável que está em produção (ex: v1.0) enquanto, ao mesmo tempo, aplica uma correção de segurança urgente nessa versão (hotfix) e desenvolve as novas funcionalidades da próxima grande versão (v2.0). +- Como é Alcançado: O uso estratégico de branches e tags (marcadores de versão) permite que a equipe organize e isole essas diferentes linhas de desenvolvimento, garantindo que uma correção urgente possa ser lançada sem levar junto funcionalidades incompletas da próxima versão. +5. Servir como Fundação para a Automação + No desenvolvimento moderno (DevOps), a velocidade e a confiabilidade das entregas dependem da automação. +- O Objetivo: Atuar como a "fonte única da verdade" e o ponto de partida confiável para todos os processos automatizados de construção, teste e implantação de software. +- Como é Alcançado: O VCS se integra a ferramentas de Integração Contínua/Entrega Contínua (CI/CD). Uma ação no repositório, como um push para o branch principal, serve como um gatilho que inicia automaticamente o pipeline: a ferramenta de CI/CD detecta a mudança, baixa o código, compila, executa os testes e, se tudo passar, implanta a nova versão. + Em resumo, o objetivo final de uma ferramenta de controle de versão é trazer ordem, segurança, rastreabilidade e eficiência para o processo inerentemente complexo e caótico de criar e manter software. + O que são branches? + Com certeza. Chegamos ao conceito que é, sem dúvida, a funcionalidade mais poderosa e transformadora dos sistemas de controle de versão modernos como o Git. Entender o que é um branch é a chave para entender como o desenvolvimento de software colaborativo funciona hoje. + O que é um Branch? + Um branch (que se traduz como "ramificação" ou "galho") é uma linha de desenvolvimento paralela e independente dentro de um repositório. + Pense no histórico do seu projeto como o tronco principal de uma árvore. Cada commit é um novo anel de crescimento nesse tronco. Em vez de adicionar todas as novas mudanças diretamente no tronco principal (o que seria arriscado), você pode criar um novo galho (branch) que brota a partir de um ponto específico do tronco. + Nesse novo galho, você pode trabalhar livremente, adicionando novas folhas e galhos menores (commits), sem afetar em nada o tronco principal. Quando seu trabalho no galho estiver maduro e pronto, você pode "fundi-lo" (merge) de volta ao tronco, incorporando todas as suas inovações à versão principal do projeto. + Para que Serve um Branch? (O Problema que Ele Resolve) + O principal objetivo de um branch é isolar o trabalho. Ele resolve vários problemas de uma só vez: +1. Desenvolvimento de Novas Funcionalidades: Este é o uso mais comum. Se você precisa desenvolver uma nova funcionalidade (ex: "login com Google"), você cria um branch chamado feature/login-com-google. Você pode levar dias ou semanas trabalhando nele, quebrando o código, experimentando, sem que a versão principal e estável do software (chamada de main ou master) seja afetada. Os usuários continuam usando a versão estável sem interrupções. +2. Correção de Bugs: Quando um bug é reportado na versão em produção, você não o corrige diretamente no código principal. Você cria um branch a partir da versão exata que está com o problema (ex: fix/calculo-incorreto-juros). Nele, você pode investigar e aplicar a correção de forma isolada e segura. Após testar, você integra essa correção de volta à linha principal. +3. Experimentação Segura: Tem uma ideia radical para refatorar uma parte do código, mas não tem certeza se vai funcionar? Crie um branch experimental/nova-arquitetura-cache. Se a ideia for boa, você a integra. Se for ruim, você simplesmente descarta o branch, e é como se ele nunca tivesse existido. Nenhum dano foi feito ao projeto principal. +4. Manutenção de Múltiplas Versões: Permite que equipes mantenham uma versão mais antiga do software (ex: em um branch v1-legacy) para clientes que ainda a utilizam, enquanto o desenvolvimento principal continua a todo vapor no branch main para a v2. + Como Funciona Tecnicamente? + O que torna os branches no Git tão especiais e diferentes de sistemas mais antigos (como o SVN) é que eles são extremamente leves e rápidos. + Um branch no Git não é uma cópia de todos os arquivos do projeto. Na verdade, ele é apenas um ponteiro móvel que aponta para um commit específico. Quando você cria um novo branch, tudo o que o Git faz é criar um novo ponteiro. É uma operação quase instantânea. Conforme você faz novos commits nesse branch, apenas o ponteiro se move para frente. + Essa leveza incentiva os desenvolvedores a usar branches para tudo. O fluxo de trabalho moderno é: vai fazer qualquer alteração, por menor que seja? Crie um branch. + O Fluxo de Trabalho Básico com Branches (Git Flow Simplificado) +1. Criar o Branch: Você começa a partir do branch main e cria seu novo branch. + git checkout -b feature/novo-relatorio +2. Trabalhar: Você faz seu trabalho: edita arquivos, adiciona novos arquivos e faz quantos commits forem necessários nesse branch. Seu trabalho está completamente isolado. +3. Integrar: Quando a funcionalidade está pronta e testada, você volta para o branch principal e "funde" o seu trabalho. + git checkout main + git merge feature/novo-relatorio +4. Limpar: Após a fusão, o branch da funcionalidade já cumpriu seu papel e pode ser deletado para manter o repositório organizado. + git branch -d feature/novo-relatorio + Em resumo, um branch é a ferramenta que permite o desenvolvimento paralelo e não linear, sendo o pilar central que habilita a colaboração, a segurança e a organização no desenvolvimento de software moderno. + O que é um workflow? + Excelente pergunta. Agora que entendemos o que é uma ferramenta de controle de versão (Git) e o que é uma funcionalidade poderosa como o branch, o próximo passo lógico é definir como usamos essas ferramentas de forma organizada. Isso é exatamente o que um workflow faz. + No nosso contexto, um workflow (ou "fluxo de trabalho") é um conjunto de regras, convenções e passos prescritos que uma equipe de desenvolvimento concorda em seguir ao usar um sistema de controle de versão. + Se o Git é a "caixa de ferramentas" e os branches são uma das ferramentas mais importantes, o workflow é o "manual de instruções" ou a "metodologia de construção" que diz à equipe como usar essas ferramentas de forma consistente e eficiente para construir e manter o software. + Para que Serve um Workflow? (O Problema que Ele Resolve) + Ter ferramentas poderosas como o Git não é suficiente. Se cada desenvolvedor usar branches e commits de uma maneira diferente e caótica, o resultado será um histórico confuso, merges difíceis e um processo de lançamento de software imprevisível. + Um workflow resolve isso ao responder a perguntas cruciais para a equipe: +- Qual é o propósito de cada branch? (ex: main é para produção, develop é para integração, feature/* é para novas funcionalidades). +- A partir de qual branch devemos criar um novo branch? +- Para qual branch devemos enviar nossas mudanças quando terminamos? +- Como nomeamos nossos branches e commits para que todos entendam? +- Como lidamos com correções urgentes em produção? +- Como gerenciamos o lançamento de uma nova versão? + Ao padronizar as respostas para essas perguntas, um workflow garante que todos na equipe "falem a mesma língua", tornando o processo de desenvolvimento mais previsível, escalável e menos propenso a erros. + Exemplos de Workflows Famosos + Existem vários modelos de workflow populares, cada um com suas próprias regras e adequado para diferentes tipos de projetos. +1. GitFlow (O Clássico Estruturado) +- Descrição: É um dos workflows mais conhecidos e estruturados. Ele utiliza dois branches principais de longa duração e vários branches de suporte. + - master (ou main): Representa o código que está em produção. É estável e cada commit nele é uma nova versão lançada. + - develop: É o branch de integração. Novas funcionalidades são fundidas aqui. Representa o estado da próxima versão a ser lançada. + - Branches de Suporte: + - feature/*: Criados a partir do develop para desenvolver novas funcionalidades. São fundidos de volta no develop. + - release/*: Criados a partir do develop quando a próxima versão está pronta para ser lançada. Permite preparar a versão (testes finais, documentação) sem parar o desenvolvimento de novas features no develop. + - hotfix/*: Criados a partir do master para correções urgentes em produção. São fundidos tanto no master quanto no develop. +- Ideal para: Projetos com ciclos de lançamento programados (ex: uma nova versão a cada 3 meses), onde a estabilidade da versão em produção é crítica. +2. GitHub Flow (O Simplificado) +- Descrição: Um workflow muito mais simples, popularizado pelo GitHub. A ideia central é que o branch main é sempre estável e pronto para ser implantado. + - main: Contém a versão mais recente e estável. Tudo que está no main pode ir para produção a qualquer momento. + - feature/* (ou qualquer nome descritivo): Todo o trabalho, seja uma nova funcionalidade ou uma correção, é feito em um branch criado a partir do main. + - Pull Request: Quando o trabalho no branch está pronto, ele não é fundido (merge) diretamente. O desenvolvedor abre uma Pull Request, que é um mecanismo para propor e discutir as mudanças com a equipe antes de integrá-las ao main. +- Ideal para: Projetos que praticam Entrega Contínua (CD), onde novas versões são lançadas com muita frequência (várias vezes ao dia). +3. Trunk-Based Development (O de Alta Velocidade) +- Descrição: Um workflow onde os desenvolvedores trabalham diretamente ou em branches de vida muito curta (horas ou poucos dias) a partir de um único branch principal chamado de "trunk" (o main). +- Foco: A ênfase é em integrar o código ao tronco principal o mais rápido e frequentemente possível para evitar grandes e complexos merges. Requer uma suíte de testes automatizados muito robusta para garantir que o "trunk" nunca quebre. +- Ideal para: Equipes de alta performance que praticam CI/CD e têm uma cultura de testes muito forte. + Em resumo, um workflow é a camada de processo e disciplina aplicada sobre a tecnologia do controle de versão. Ele transforma o poder bruto de uma ferramenta como o Git em uma metodologia organizada que permite que as equipes construam software de forma colaborativa, segura e eficiente. + O que é gitflow? + Quais são os branches principais? + Ótima pergunta, focada no coração de qualquer workflow. Embora as equipes possam nomear branches como quiserem, existem convenções muito fortes na indústria. Os branches que costumam ser os principais, ou de longa duração, são geralmente dois: master (ou main) e develop. + A presença de um ou de ambos define o tipo de workflow que a equipe está usando. +1. master / main + Este é o branch mais importante e universal. Praticamente todo repositório Git terá um branch com este papel, independentemente do workflow. +- Propósito: Representar a fonte única da verdade do código que está estável e em produção. Tudo o que está neste branch deve ser considerado "ouro": testado, aprovado e pronto para ser entregue aos usuários a qualquer momento. +- Histórico: Cada commit no branch main é, efetivamente, um novo ponto de release na história do projeto. O histórico deste branch é o diário oficial dos lançamentos. +- Como é atualizado: As atualizações no main são feitas de forma muito controlada. Geralmente, nada é enviado (commitado) diretamente para ele. As mudanças chegam através da fusão (merge) de outros branches (como branches de release ou hotfix no GitFlow, ou branches de feature aprovados em Pull Requests no GitHub Flow). + Uma Nota Importante: master vs. main + Historicamente, o nome padrão para este branch sempre foi master. No entanto, a partir de 2020, a indústria de software começou a se afastar desse termo por suas conotações com a escravidão. A comunidade, liderada por plataformas como o GitHub, adotou main como o novo nome padrão. Funcionalmente, eles são idênticos; a mudança é puramente para usar uma terminologia mais inclusiva. Projetos novos hoje quase sempre usam main, enquanto projetos mais antigos podem ainda usar master. +2. develop + Este branch não é universal. Ele é a peça central de workflows mais estruturados, sendo o mais famoso deles o GitFlow. Em workflows mais simples, como o GitHub Flow, este branch simplesmente não existe. +- Propósito: Servir como um branch de integração para todas as novas funcionalidades. Enquanto o main reflete o que está em produção, o develop reflete o estado mais recente do desenvolvimento e o que estará na próxima versão. É um branch que está em constante evolução. +- Histórico: O histórico do develop é muito mais movimentado e detalhado que o do main. Ele mostra a integração diária do trabalho de toda a equipe. +- Como é atualizado: Desenvolvedores criam branches de funcionalidade (feature branches) a partir do develop. Quando terminam, eles fundem (merge) seu trabalho de volta no develop. + Tabela Comparativa + | Característica | main (ou master) | develop | + | :------------------------ | :----------------------------------------------- | :------------------------------------------------------------------- | + | Representa | O código em produção. A versão estável. | O código da próxima versão. A vanguarda do desenvolvimento. | + | Estabilidade | Altíssima. Deve estar sempre pronto para deploy. | Instável por natureza. É onde as coisas "quebram" e são consertadas. | + | Uso | Universal (quase todos os workflows). | Específico de workflows mais complexos (ex: GitFlow). | + | Atualizado por | Merges de branches de release ou hotfix. | Merges de branches de feature. | + | Frequência de Atualização | Menos frequente (apenas em novos lançamentos). | Muito frequente (diariamente, várias vezes ao dia). |Em resumo: +- Se você vir apenas um branch principal chamado main ou master, a equipe provavelmente usa um workflow simples onde a estabilidade é mantida através de Pull Requests e testes rigorosos. +- Se você vir tanto main quanto develop, a equipe certamente usa um workflow mais estruturado como o GitFlow, mantendo uma separação clara entre o código em desenvolvimento e o código em produção. + O que são branches de suporte? + Com certeza. O conceito de "branches de suporte" é o que torna um workflow estruturado como o GitFlow tão robusto e organizado. + Enquanto os branches principais (main e develop) são permanentes e têm uma vida longa, os branches de suporte são temporários. Eles são criados para cumprir um propósito específico e, uma vez que sua tarefa é concluída e seu código é integrado, eles são deletados. + Eles são os "operários" do seu repositório, enquanto main e develop são os "supervisores". Existem três tipos principais de branches de suporte, cada um com uma missão clara: +1. Branches de Funcionalidade (Feature Branches) +- Propósito: Desenvolver uma nova funcionalidade específica para uma futura versão do software. Este é o tipo de branch mais comum e onde os desenvolvedores passam a maior parte do tempo. +- Convenção de Nomenclatura: Geralmente começam com o prefixo feature/, seguido por um nome descritivo (ex: feature/login-com-google ou feature/novo-relatorio-vendas). +- Origem: São sempre criados a partir do branch develop. +- Destino: Quando a funcionalidade está completa, eles são sempre fundidos (merged) de volta no branch develop. Eles nunca interagem diretamente com o main. +- Ciclo de Vida: Podem viver por dias ou semanas, dependendo da complexidade da funcionalidade. + Workflow: +1. Começar uma nova tarefa. +2. Criar um branch feature/minha-feature a partir do develop. +3. Trabalhar e fazer commits nesse branch. +4. Funcionalidade pronta? Fundir feature/minha-feature de volta no develop. +5. Deletar feature/minha-feature. +2. Branches de Lançamento (Release Branches) +- Propósito: Preparar o lançamento de uma nova versão de produção. Este branch serve como um "ambiente de congelamento", onde o desenvolvimento de novas funcionalidades para (novas features) é interrompido. Apenas correções de bugs de última hora, geração de documentação e outras tarefas relacionadas ao lançamento são permitidas aqui. +- Convenção de Nomenclatura: Geralmente começam com release/, seguido pelo número da versão (ex: release/v1.2.0). +- Origem: São criados a partir do branch develop quando se decide que a próxima versão tem funcionalidades suficientes e está pronta para ser lançada. +- Destino: Quando o branch de lançamento está estável e pronto, ele é fundido em dois lugares: + 1. No branch main, para oficialmente lançar a nova versão. Neste momento, o commit no main é marcado com uma tag (ex: v1.2.0). + 2. De volta no branch develop, para garantir que qualquer correção de bug de última hora feita no branch de lançamento também seja incorporada ao desenvolvimento futuro. +- Ciclo de Vida: Geralmente vivem por um curto período (dias ou poucas semanas) durante a fase final de testes e preparação. + Workflow: +1. develop está pronto para o lançamento v1.2.0. +2. Criar um branch release/v1.2.0 a partir do develop. +3. Neste branch, apenas corrigir bugs. Enquanto isso, a equipe pode continuar desenvolvendo novas funcionalidades (para a v1.3.0) no develop. +4. release/v1.2.0 está estável. +5. Fundir em main e criar a tag v1.2.0. +6. Fundir também de volta em develop. +7. Deletar release/v1.2.0. +3. Branches de Correção Urgente (Hotfix Branches) +- Propósito: Corrigir um bug crítico na versão que está em produção e que precisa ser resolvido imediatamente, sem esperar pelo próximo ciclo de lançamento. +- Convenção de Nomenclatura: Geralmente começam com hotfix/, seguido por um descritivo do problema ou número da versão (ex: hotfix/problema-seguranca-login). +- Origem: São sempre criados a partir do branch main, pois precisam partir exatamente do código que está em produção. +- Destino: Assim como os branches de release, quando a correção está pronta, eles são fundidos em dois lugares: + 1. No branch main, para lançar a correção para os usuários o mais rápido possível (gerando uma nova tag de versão, ex: v1.1.1). + 2. De volta no branch develop, para garantir que a correção também esteja presente no código em desenvolvimento e não seja reintroduzida no futuro. +- Ciclo de Vida: São de vida muito curta (horas ou poucos dias). A urgência é a chave. + Tabela Resumo + | Tipo de Branch | Propósito | Origem | Destino(s) | Exemplo de Nome | + | :------------- | :----------------------------------- | :------ | :------------- | :-------------------- | + | Feature | Desenvolver novas funcionalidades. | develop | develop | feature/novo-cadastro | + | Release | Preparar um novo lançamento. | develop | main e develop | release/v2.0.0 | + | Hotfix | Corrigir um bug crítico em produção. | main | main e develop | hotfix/bug-pagamento |O uso disciplinado desses branches de suporte é o que permite que equipes gerenciem projetos complexos, mantendo a estabilidade da versão em produção enquanto continuam a inovar e a evoluir o software. + O que é semantic version? + Com certeza. O Versionamento Semântico, ou Semantic Versioning (SemVer), é o passo final e crucial que conecta todo o nosso diálogo sobre controle de versão, branches e workflows. Ele é o sistema de rotulagem que dá sentido aos lançamentos que esses processos geram. + O que é Semantic Versioning? + O Versionamento Semântico é uma convenção formal e um conjunto de regras para atribuir números de versão a um software. Seu objetivo principal é transformar o número da versão em uma mensagem clara sobre a natureza das mudanças contidas em uma nova release. + Em vez de números de versão arbitrários como "Versão 2025" ou "Versão 5.1a", o SemVer estabelece um padrão que comunica o tipo e o impacto das alterações. Ele funciona como um contrato entre quem produz o software e quem o consome (outros desenvolvedores, sistemas, etc.). + A Estrutura: MAJOR.MINOR.PATCH + O formato padrão do Versionamento Semântico é composto por três números inteiros, separados por pontos: + MAJOR . MINOR . PATCH + (Maior . Menor . Correção) + Exemplo: v2.1.5 + Cada um desses números tem um significado estrito e só deve ser incrementado de acordo com as seguintes regras: +1. MAJOR (Maior) + - Quando incrementar? Quando você faz alterações incompatíveis na API (breaking changes). + - O que significa? Uma mudança que quebra a compatibilidade com as versões anteriores. Se um usuário do seu software atualizar para uma nova versão MAJOR, ele sabe que o código dele pode quebrar e precisará de adaptações. É um sinal de alerta. + - Exemplo: Você renomeia uma função, muda a ordem dos parâmetros de um método ou remove uma funcionalidade. +2. MINOR (Menor) + - Quando incrementar? Quando você adiciona novas funcionalidades de forma retrocompatível (backward-compatible). + - O que significa? Você adicionou algo novo, mas não quebrou nada que já existia. O código de quem usa seu software continuará funcionando perfeitamente sem nenhuma alteração. + - Exemplo: Você adiciona um novo método a uma classe ou um novo endpoint opcional a uma API. +3. PATCH (Correção) + - Quando incrementar? Quando você faz correções de bugs de forma retrocompatível. + - O que significa? Você não adicionou nada novo, apenas consertou um comportamento incorreto da versão anterior. A atualização é segura e altamente recomendada. + - Exemplo: Você corrige um cálculo que estava dando o resultado errado ou uma falha de segurança. + Regra de Ouro: Ao incrementar um número, os números à sua direita são zerados. Por exemplo, se a versão é 1.7.3 e você lança uma nova funcionalidade (MINOR), a nova versão se torna 1.8.0. Se você lança uma mudança incompatível (MAJOR), a nova versão se torna 2.0.0. + Um Exemplo Prático + Imagine que você gerencia uma biblioteca de software: +- v1.0.0: Lançamento inicial e estável. +- Você descobre um bug no cálculo de impostos. Você o corrige. A nova versão é v1.0.1 (incremento de PATCH). +- Em seguida, você adiciona uma nova função para exportar relatórios em CSV, sem alterar nada que já existia. A nova versão é v1.1.0 (incremento de MINOR, zerando o PATCH). +- Você encontra outro pequeno bug na nova função de exportação e o corrige. A nova versão é v1.1.1 (incremento de PATCH). +- Finalmente, você decide que a função principal, calcularImposto(), deve se chamar calcularTributos(). Isso é uma mudança incompatível, pois o código de todo mundo que usava a função antiga vai quebrar. A nova versão é v2.0.0 (incremento de MAJOR, zerando MINOR e PATCH). + Por que Isso é Tão Importante? + O SemVer é a solução para um problema conhecido como "inferno das dependências" (dependency hell). + No desenvolvimento moderno, os projetos dependem de dezenas ou centenas de pacotes e bibliotecas de terceiros. A questão é: "Como posso atualizar uma dessas dependências para obter uma correção de bug sem quebrar toda a minha aplicação?" + O SemVer resolve isso: +- Gerenciadores de Pacotes (npm, Maven, NuGet, etc.): Essas ferramentas são programadas para entender as regras do SemVer. Você pode configurar seu projeto para aceitar atualizações de PATCH e MINOR automaticamente (ex: ^1.1.1), pois sabe que elas são seguras e não quebrarão seu código. +- Comunicação Clara: Um desenvolvedor que vê uma atualização da versão 4.1.2 para 5.0.0 sabe imediatamente, sem ler uma linha de documentação, que precisará ter cuidado e planejar a atualização, pois existem mudanças incompatíveis. +- Previsibilidade: Ele torna o ciclo de vida e a evolução do software previsíveis e fáceis de gerenciar, tanto para quem desenvolve quanto para quem consome. + Em resumo, o Versionamento Semântico transforma um simples número de versão em uma ferramenta de comunicação poderosa e um contrato de confiança, sendo um pilar fundamental para o ecossistema de software colaborativo e interconectado que temos hoje. + O que é entropia de software? + Com certeza. O conceito de Entropia de Software é uma das metáforas mais importantes e realistas da engenharia de software. Ele descreve um fenômeno que todo desenvolvedor experiente já sentiu na prática. + O que é Entropia de Software? + Entropia de Software é a medida da desordem, complexidade e degradação de um sistema de software. O conceito é uma analogia direta à Segunda Lei da Termodinâmica, que afirma que a entropia (desordem) em um sistema fechado tende a aumentar com o tempo. + No software, isso significa que, à medida que um sistema é modificado ao longo de seu ciclo de vida, sua estrutura interna inevitavelmente se deteriora. Um software que era inicialmente limpo, bem-estruturado e fácil de entender, com o tempo e com sucessivas alterações, tende a se tornar mais complexo, frágil e difícil de manter. + Pense em uma casa nova e bem-organizada. Conforme você vive nela, faz pequenas reformas, adiciona móveis e improvisa soluções (como uma extensão para ligar um novo aparelho), a ordem original se perde. Com o tempo, a casa fica desordenada e encontrar coisas ou fazer novas mudanças se torna cada vez mais difícil. O software se comporta da mesma maneira. Esse processo de "degradação" ou "apodrecimento do código" (code rot) é a entropia em ação. + Por que a Entropia Acontece? + A entropia não é causada por maus programadores, mas é uma consequência natural do ciclo de vida do software. As principais causas são: +1. Mudança Constante: A causa raiz. Cada nova funcionalidade adicionada, cada bug corrigido, cada adaptação a um novo ambiente adiciona uma pequena "cicatriz" ou "remendo" ao design original. Mesmo as mudanças bem-intencionadas, se não forem feitas com extremo cuidado, aumentam a complexidade geral. +2. Pressão de Prazos: A necessidade de entregar rapidamente muitas vezes leva a atalhos e soluções "só para fazer funcionar". Essas soluções, conhecidas como dívida técnica, são como empréstimos: resolvem o problema agora, mas cobram juros altos no futuro na forma de maior complexidade e dificuldade de manutenção. +3. Múltiplos Desenvolvedores: Ao longo dos anos, diferentes pessoas com diferentes estilos de programação e níveis de compreensão da arquitetura original trabalharão no código. Isso pode levar a inconsistências e a um design que parece uma colcha de retalhos. +4. Falta de Refatoração: As equipes raramente têm tempo (ou não priorizam) para "arrumar a casa", ou seja, reestruturar e limpar o código existente para reduzir sua complexidade. + Quais são os Sintomas da Alta Entropia? + Você sabe que um sistema sofre de alta entropia quando a equipe enfrenta os seguintes problemas: +- Efeito Cascata (Ripple Effect): Corrigir um bug em uma parte do sistema inexplicavelmente quebra outra parte que parecia não ter relação. O software é frágil. +- Estimativas Imprevisíveis: Uma mudança que parece simples acaba levando semanas para ser implementada devido a complexidades ocultas e efeitos colaterais. +- Curva de Aprendizagem Lenta: Leva um tempo excessivamente longo para que novos desenvolvedores se tornem produtivos no projeto, pois o código é difícil de entender. +- Medo de Mudar: A equipe tem medo de tocar em certas partes do código porque ninguém entende completamente como funcionam ou quais serão as consequências de uma alteração. + Como Combater a Entropia? + A entropia é uma força da natureza; não pode ser eliminada, mas pode ser gerenciada e combatida ativamente. As práticas de engenharia de software que discutimos são, em grande parte, armas contra a entropia: +1. Refatoração Contínua (Continuous Refactoring): Esta é a principal ferramenta. Refatorar é o ato de reestruturar o código existente para melhorar seu design interno e reduzir a complexidade, sem alterar seu comportamento externo. É a "limpeza e organização" constante da casa. A "Regra do Escoteiro" se aplica aqui: "Deixe o acampamento (o código) mais limpo do que você o encontrou". +2. Aderência a Padrões e Arquitetura: Ter uma arquitetura bem definida e garantir que todas as novas mudanças a respeitem ajuda a manter a ordem e a coerência. +3. Testes Automatizados: Uma suíte de testes robusta age como uma rede de segurança. Ela permite que os desenvolvedores façam refatorações agressivas com a confiança de que, se quebrarem algo, os testes irão alertá-los imediatamente. +4. Revisão de Código (Code Review): Ter outros membros da equipe revisando as mudanças ajuda a garantir a qualidade, a compartilhar conhecimento e a evitar que soluções de baixa qualidade (que aumentam a entropia) sejam introduzidas no código. +5. Gerenciamento da Dívida Técnica: Tratar a dívida técnica como algo real, que precisa ser planejado e "pago" (ou seja, reservar tempo para refatorar e melhorar o código). + Em resumo, Entropia de Software é o reconhecimento de que, se deixado ao acaso, um software sempre tenderá ao caos. Combatê-la exige disciplina, esforço contínuo e a aplicação de boas práticas de engenharia para manter a ordem, a clareza e a manutenibilidade do sistema ao longo do tempo. + O que é o manifesto? + Excelente pergunta. Você chegou ao coração de como o software moderno é construído. O "manifesto" é o que torna o reuso de código e o gerenciamento de dependências algo prático e gerenciável. + Vamos quebrar o conceito em duas partes, como você pediu. +1. O que é um Manifesto? + No contexto de desenvolvimento de software, um manifesto (ou manifest file) é um arquivo de metadados, geralmente em formato de texto (como JSON, XML ou YAML), que descreve um projeto de software e, crucialmente, lista todas as suas dependências externas. + Pense nele como a "lista de ingredientes e a receita" de um bolo. Ele contém: +- Informações sobre o Projeto (Metadados): O nome do projeto, sua versão atual (seguindo o Versionamento Semântico!), o autor, a licença de uso, etc. +- A Lista de Dependências: A parte mais importante. É uma lista de todos os pacotes, bibliotecas ou frameworks de terceiros que o seu projeto precisa para funcionar. +- Scripts e Comandos: Muitas vezes, ele também define comandos úteis para o projeto, como "iniciar o servidor de desenvolvimento" (npm start) ou "executar os testes" (npm test). + Exemplos de Manifestos no Mundo Real + Cada ecossistema de programação tem seu próprio formato de manifesto: +- JavaScript/Node.js: O arquivo package.json. +- Java: O arquivo pom.xml (usado pelo Maven) ou build.gradle (usado pelo Gradle). +- Python: O arquivo requirements.txt ou, mais modernamente, o pyproject.toml. +- Ruby: O arquivo Gemfile. +- Go: O arquivo go.mod. + Exemplo de um package.json (JavaScript): + { + "name": "meu-projeto-web", + "version": "1.2.0", + "description": "Um incrível projeto web.", + "main": "index.js", + "scripts": { + "test": "echo \"Error: no test specified\" && exit 1" + }, + "author": "Seu Nome", + "license": "ISC", + "dependencies": { + "express": "^4.17.1", + "lodash": "^4.17.21" + }, + "devDependencies": { + "jest": "^27.0.6" + } + } + Neste exemplo, o manifesto nos diz que o projeto meu-projeto-web na versão 1.2.0 depende de duas bibliotecas para funcionar em produção (express e lodash) e de uma biblioteca para rodar os testes (jest). +2. O que Isso Tem a Ver com Versionamento de Dependências? + Esta é a conexão fundamental. O manifesto é a peça central que torna o versionamento de dependências possível e resolve o problema conhecido como "inferno das dependências" (dependency hell). + A relação é a seguinte: +1. Declaração Explícita: Em vez de um desenvolvedor dizer "Ah, para rodar meu projeto, você precisa instalar a biblioteca X e a Y", o manifesto declara formalmente todas as dependências e, mais importante, as suas versões. +2. O Contrato do Semantic Versioning: É aqui que o Versionamento Semântico (SemVer) brilha. No exemplo acima, a dependência "express": "^4.17.1" usa o SemVer para criar uma regra. O acento circunflexo ^ significa: "Eu aceito a versão 4.17.1 ou qualquer outra versão menor (MINOR) ou de correção (PATCH) que seja retrocompatível. Mas não aceite a versão 5.0.0 ou superior, pois ela pode ter mudanças incompatíveis (breaking changes)". +3. Reprodutibilidade do Ambiente: O manifesto garante que qualquer desenvolvedor, em qualquer máquina, em qualquer momento, possa recriar o ambiente de desenvolvimento exato do projeto. Ao clonar o projeto do repositório, a pessoa não precisa adivinhar o que instalar. Ela simplesmente executa um comando (como npm install, mvn install ou pip install -r requirements.txt). +4. Ação do Gerenciador de Pacotes: O gerenciador de pacotes (npm, Maven, pip, etc.) é a ferramenta que lê o manifesto. Ele analisa a lista de dependências, interpreta as regras de versionamento semântico, baixa as versões corretas de cada pacote de um repositório central (como npmjs.com ou Maven Central) e as instala no projeto. + Em resumo, a relação é: + O manifesto é o documento onde você escreve as regras do que seu projeto precisa, usando a linguagem do Versionamento Semântico para definir as versões das dependências. Um gerenciador de pacotes então lê esse manifesto e constrói o ambiente de forma automática e previsível. + Sem um manifesto, cada projeto seria uma ilha, e configurar um ambiente de desenvolvimento seria um processo manual, frágil e propenso a erros. Com um manifesto, o gerenciamento de dependências se torna um processo declarativo, automático e, acima de tudo, reprodutível. + O que são ranges de versão? + Com certeza. O conceito de "ranges de versão" (intervalos de versão) é a aplicação prática do Versionamento Semântico dentro de um arquivo de manifesto. É o que dá poder e flexibilidade ao gerenciamento de dependências. + O que são Ranges de Versão? + Ranges de Versão são uma notação especial, usada em arquivos de manifesto (como o package.json), para especificar não apenas uma única e exata versão de uma dependência, mas um intervalo de versões aceitáveis. + Em vez de "prender" ou "cravar" (pinning) seu projeto a uma única versão de uma biblioteca para sempre (ex: 1.2.3), os ranges permitem que você diga: "Meu projeto é compatível com qualquer versão que se encaixe nesta regra...". + Por que Usar Ranges em Vez de Versões Exatas? + Este é o ponto crucial. Há um dilema no gerenciamento de dependências: +- Se você usa uma versão exata (ex: 4.17.1): Seu build é 100% previsível e estável. No entanto, você perde automaticamente correções de bugs importantes e patches de segurança que são lançados em versões futuras (como 4.17.2). +- Se você permite qualquer versão (ex: *): Você recebe todas as atualizações, mas um dia seu projeto pode quebrar repentinamente porque uma nova versão 5.0.0 foi lançada com mudanças incompatíveis. + Os ranges de versão são a solução inteligente para este dilema. Eles permitem que você aceite automaticamente as atualizações seguras e benéficas (correções de bug e novas funcionalidades compatíveis), enquanto rejeita as atualizações perigosas (com breaking changes), tudo com base nas regras do Versionamento Semântico. + Os Operadores de Range Mais Comuns + A sintaxe pode variar um pouco entre os ecossistemas, mas os seguintes, popularizados pelo npm (gerenciador de pacotes do Node.js), são os mais comuns e influentes: + | Símbolo | Nome | Exemplo | Significado | Tradução Técnica | + | :------- | :------------------------- | :------ | :-------------------------------------------------------- | :--------------- | + | ^ | Acento Circunflexo (Caret) | ^1.2.3 | Permite atualizações de PATCH e MINOR. Não permite MAJOR. | >=1.2.3 <2.0.0 | + | ~ | Til (Tilde) | ~1.2.3 | Permite apenas atualizações de PATCH. | >=1.2.3 <1.3.0 | + | (nenhum) | Versão Exata | 1.2.3 | Apenas e exatamente esta versão. | 1.2.3 | + | * ou x | Curinga (Wildcard) | 1.2.x | Qualquer versão com o mesmo MAJOR e MINOR. | >=1.2.0 <1.3.0 | + | > <= | Comparadores | >=1.2.3 | Qualquer versão maior ou igual a 1.2.3. | >=1.2.3 |Qual Usar? O Padrão da Indústria + O operador ^ (Caret) tornou-se o padrão na maioria dos ecossistemas modernos. Quando você executa um comando como npm install express, ele geralmente adiciona "express": "^4.17.1" ao seu package.json por padrão. + Isso acontece porque o ^ representa o melhor equilíbrio: ele confia que os autores das bibliotecas seguem o Versionamento Semântico, permitindo que seu projeto receba automaticamente correções de bugs e novas funcionalidades não-quebráveis, mantendo você protegido contra as grandes e perigosas atualizações de versão MAJOR. + A Peça Final do Quebra-Cabeça: O Arquivo de Lock + Os ranges de versão introduzem um pequeno problema: se um desenvolvedor instala as dependências hoje, ele pode receber a versão 1.2.5 de uma biblioteca. Se outro desenvolvedor instalar as mesmas dependências amanhã, ele pode receber a versão 1.2.6, que acabou de ser lançada. Embora ambas as versões estejam dentro do range ^1.2.3, essa pequena diferença pode, em casos raros, causar o problema de "na minha máquina funciona". + Para resolver isso, os gerenciadores de pacotes modernos criaram o conceito de arquivo de lock (ex: package-lock.json, yarn.lock). +- O que ele faz? Na primeira vez que você instala as dependências, o gerenciador de pacotes resolve todos os ranges e descobre as versões exatas de cada pacote que foram instaladas. Ele então "trava" essas versões, escrevendo uma lista detalhada de cada pacote e sua versão exata no arquivo de lock. +- Qual o resultado? Esse arquivo de lock é salvo no seu controle de versão (Git). Agora, quando outro desenvolvedor clonar o projeto e instalar as dependências, o gerenciador de pacotes verá o arquivo de lock e instalará as mesmas versões exatas que foram instaladas na primeira vez, ignorando os ranges. + Isso lhe dá o melhor dos dois mundos: +1. Os ranges de versão no seu package.json lhe dão a flexibilidade de atualizar para novas versões seguras quando você decidir. +2. O arquivo de lock garante que todos na equipe e nos seus servidores de produção tenham builds 100% reprodutíveis e idênticos. + O que são conventional commits? + Com certeza. Esta pergunta é a cereja do bolo, conectando perfeitamente nossa conversa sobre versionamento, workflows e Versionamento Semântico. Os Conventional Commits (Commits Convencionais) são a disciplina que une o trabalho diário do desenvolvedor à estratégia de lançamento do software. + O que são Conventional Commits? + Conventional Commits é uma especificação, um conjunto de regras simples, sobre como escrever as mensagens de commit. O objetivo é criar um histórico de commits que seja legível tanto por humanos quanto por máquinas. + Em vez de mensagens vagas e inconsistentes como: +- git commit -m "ajustes" +- git commit -m "corrigi o bug do login" +- git commit -m "WIP tela de usuário" + A especificação propõe um formato estruturado que injeta significado e contexto em cada commit. É uma formalização do que já sabemos que é uma boa prática: escrever mensagens de commit claras. + Por que Usar um Padrão Tão Rígido? + A grande vantagem não é apenas a organização, mas a automação. Quando as mensagens de commit seguem um padrão previsível, podemos usar ferramentas para: +1. Determinar Automaticamente a Versão Semântica (SemVer): Esta é a conexão mais importante. As ferramentas podem ler o histórico de commits desde a última versão e decidir qual será o próximo número de versão. + - Se houver commits do tipo fix, ele sabe que deve incrementar o PATCH. + - Se houver commits do tipo feat, ele sabe que deve incrementar o MINOR. + - Se houver um commit que indica uma mudança incompatível (breaking change), ele sabe que deve incrementar o MAJOR. +2. Gerar CHANGELOGs Automaticamente: As ferramentas podem compilar todos os commits e gerar um arquivo CHANGELOG.md (um registro de mudanças) de forma bonita e organizada para cada nova versão, agrupando as alterações por "Novas Funcionalidades", "Correções de Bugs", etc. +3. Melhorar a Comunicação: Facilita para qualquer pessoa (incluindo você no futuro) navegar pelo histórico e entender rapidamente a natureza de cada mudança sem precisar ler o código. + A Estrutura de um Conventional Commit + O formato é simples e poderoso: + [escopo opcional]: + +[corpo opcional] + +[rodapé(s) opcional(is)] +Vamos detalhar as partes: +- tipo (Obrigatório): Uma palavra que descreve a categoria da mudança. Os tipos mais comuns são: + - feat: Para uma nova funcionalidade (feature). -> Corresponde a um MINOR no SemVer. + - fix: Para uma correção de bug. -> Corresponde a um PATCH no SemVer. + - docs: Mudanças apenas na documentação. + - style: Mudanças de formatação que não afetam o código (ponto e vírgula, espaços, etc.). + - refactor: Uma reescrita do código que não corrige um bug nem adiciona uma funcionalidade. + - perf: Uma mudança que melhora o desempenho. + - test: Adição ou correção de testes. + - build: Mudanças no sistema de build ou em dependências externas (ex: package.json). + - ci: Mudanças nos arquivos de configuração de CI/CD. + - chore: Outras tarefas que não modificam o código fonte ou testes (ex: atualizar o .gitignore). +- escopo (Opcional): Um substantivo entre parênteses que descreve a parte do código afetada (ex: (api), (auth), (ui)). +- descrição (Obrigatória): Um resumo conciso, em letra minúscula e no imperativo (ex: "adiciona endpoint" em vez de "adicionado endpoint"). +- corpo (Opcional): Um parágrafo mais longo explicando o contexto e os detalhes da mudança. +- rodapé (Opcional): A parte mágica para automação. Usado principalmente para duas coisas: + - Indicar Breaking Changes: Uma linha que começa com BREAKING CHANGE: seguida da descrição da mudança incompatível. Isso sinaliza para as ferramentas que a versão MAJOR deve ser incrementada. + - Referenciar Issues: Ex: Fixes #123, Closes #456. + Exemplos Práticos +1. Um fix simples: + fix(auth): corrige validação de senha para aceitar caracteres especiais +2. Uma nova feature com mais detalhes: + feat(api): adiciona endpoint para perfis de usuário + +O novo endpoint GET /users/{id} permite a consulta de dados +públicos de um usuário. Dados sensíveis como email não são retornados. + +Closes #78 +3. Um refactor com uma mudança incompatível (BREAKING CHANGE): + refactor(database): substitui o driver do MongoDB pelo do PostgreSQL + +BREAKING CHANGE: A camada de acesso a dados foi completamente +substituída. Os métodos `findUser` e `updateUser` foram removidos +e substituídos por uma nova API baseada em repositórios. +Consulte a documentação para a migração. +Como Tudo se Conecta +Agora, vamos juntar todo o nosso conhecimento em um fluxo automatizado: +1. Um desenvolvedor segue um workflow (ex: GitHub Flow) e cria um branch. +2. Ele faz seu trabalho e escreve seus commits seguindo a especificação dos Conventional Commits. +3. Um dos commits é feat(api): adiciona novo endpoint e outro é fix(ui): corrige bug no formulário. +4. Ele abre uma Pull Request, que é aprovada e integrada ao branch main. +5. O sistema de CI/CD é acionado. Uma ferramenta lê os commits desde a última tag de versão. +6. A ferramenta vê um feat e um fix. Ela sabe que isso justifica uma atualização MINOR no Versionamento Semântico. +7. Se a versão anterior era 1.2.5, a ferramenta calcula que a nova versão é 1.3.0. +8. A ferramenta gera um CHANGELOG automaticamente, com as seções "New Features" e "Bug Fixes". +9. A ferramenta cria uma nova tag Git v1.3.0, publica o pacote e implanta a nova versão. + Em resumo, os Conventional Commits são a disciplina que permite que o trabalho diário de um desenvolvedor alimente diretamente um processo de lançamento de software totalmente automatizado e previsível. + Qual é a diferença entre tags e releases? + Ótima pergunta para finalizarmos nossa jornada pelos conceitos de versionamento. Esta é uma dúvida muito comum, pois os dois termos estão intimamente ligados, mas servem a propósitos diferentes. A distinção fundamental é: um é um conceito técnico do Git, e o outro é um conceito de plataforma (como GitHub ou GitLab). + Pense na seguinte analogia: a produção de um filme. + O que é uma Tag? + Uma tag é um conceito do Git. É um marcador, um ponteiro imutável que aponta para um commit específico no seu histórico. Sua principal função é dar um nome legível e significativo a um ponto na história do seu código, geralmente para marcar uma versão de lançamento. +- O que é na analogia? A tag é o momento em que o diretor grita "CORTA!" na cena final e decide: "Esta é a versão final do filme que vai para a pós-produção". É o carimbo no rolo de filme que diz "versão final, 2 de setembro". +- Onde Vive? Dentro do seu repositório Git. É uma parte do histórico do seu código. +- Conteúdo: Uma tag (especialmente uma "annotated tag") contém um ponteiro para um commit, o nome do autor da tag, a data e uma mensagem. Ela não armazena nada além disso. Ela aponta para o código-fonte naquele momento. +- Propósito: Marcar um ponto de referência técnico. Responder à pergunta: "Qual commit exato corresponde à versão v1.2.0 do nosso software?". +- Como é Criada? Geralmente via linha de comando do Git. + git tag -a v1.2.0 -m "Lançamento da versão 1.2.0" + git push origin v1.2.0 + O que é uma Release? + Uma Release (Lançamento) é um conceito de plataformas de hospedagem como GitHub, GitLab ou Bitbucket. Uma Release é um invólucro ou pacote construído em cima de uma tag. Ela pega o ponto de referência técnico criado pela tag e adiciona uma camada de informações ricas e artefatos de distribuição voltados para o consumidor final. +- O que é na analogia? A Release é o lançamento do Blu-ray do filme. Ela contém o filme final (o código apontado pela tag), mas também vem com muito mais: + - A capa com a sinopse (as notas de lançamento ou release notes). + - Os extras, como cenas deletadas e making-of (os arquivos binários, como .exe, .dmg, .zip). + - Uma lista de capítulos (o changelog). +- Onde Vive? Na interface web da sua plataforma de hospedagem (GitHub, GitLab, etc.). +- Conteúdo: Uma Release é associada a uma tag e contém: + - O código-fonte daquela tag (geralmente em arquivos .zip e .tar.gz gerados automaticamente). + - Notas de Lançamento: Um texto formatado descrevendo o que há de novo, quais bugs foram corrigidos e quais as principais mudanças. + - Ativos (Assets) ou Binários: Arquivos compilados e prontos para uso que você pode anexar manualmente (instaladores, pacotes, etc.). +- Propósito: Empacotar e distribuir uma versão para o público. Responder à pergunta: "O que mudou na versão v1.2.0 e onde posso baixar os arquivos para instalá-la?". +- Como é Criada? Através da interface gráfica da plataforma, após a tag já ter sido enviada para o repositório. + Tabela Comparativa + | Característica | Tag | Release | + | :------------- | :----------------------------------- | :--------------------------------------------- | + | O que é? | Um ponteiro para um commit. | Um pacote de distribuição associado a uma tag. | + | Onde Vive? | No repositório Git (histórico). | Na plataforma de hospedagem (GitHub, GitLab). | + | Conteúdo | Um marcador no código-fonte. | Código-fonte + Notas de Lançamento + Binários. | + | Propósito | Marcar um ponto técnico na história. | Distribuir uma versão para os usuários finais. | + | Foco | Desenvolvedores. | Usuários finais e consumidores do software. |Como Eles Trabalham Juntos? + O fluxo de trabalho é sequencial e lógico: +1. Sua equipe termina o desenvolvimento da próxima versão no Git. +2. Você cria uma tag localmente para marcar o commit final como, por exemplo, v1.2.0. +3. Você envia (push) essa tag para o seu repositório remoto no GitHub. +4. No GitHub, você navega até a seção de "Releases" e cria uma nova Release. +5. Ao criar a Release, você seleciona a tag v1.2.0 que acabou de enviar. +6. Você escreve as notas de lançamento detalhando as novidades e anexa os arquivos de instalação (se houver). +7. Você publica a Release, e ela se torna a "página oficial" de download e informação daquela versão. + Em resumo: a tag é o marcador técnico no código; a release é a embalagem de distribuição pública para essa versão. Você não pode ter uma Release sem uma tag. From 59a33c6f6d339a0ba202cb297bafcc580f78303f Mon Sep 17 00:00:00 2001 From: malcomwooMAL Date: Tue, 9 Sep 2025 10:31:16 -0300 Subject: [PATCH 2/2] =?UTF-8?q?Commit=20para=20pr=C3=A1tica=20da=20ativida?= =?UTF-8?q?de?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- anotacoes_aula.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/anotacoes_aula.md b/anotacoes_aula.md index 94b1349..f14f3fb 100644 --- a/anotacoes_aula.md +++ b/anotacoes_aula.md @@ -1,4 +1,4 @@ -Controle de Versionamento (Processos) +Controle de Versionamento (Processos) - Alteração O que são ferramentas de controles de versão? Com certeza. Já que estabelecemos o conceito de controle de versão, agora vamos falar sobre as aplicações que colocam esse conceito em prática. Ferramentas de Controle de Versão (ou VCS - Version Control Systems) são os programas de software que os desenvolvedores usam para gerenciar o histórico e a colaboração em um projeto. São as aplicações que executam todas as tarefas que discutimos: rastrear mudanças, permitir o trabalho em equipe e manter um registro completo de cada versão.