Introdução

Este é um curso intermediário de Git ministrado por Tobias Günther. Ele ajudará você a ir além dos conceitos básicos do Git e melhorar seu fluxo de trabalho com o Git.

Sobre o Curso

Olá, amigos do Free Code Camp, meu nome é Tobias, e hoje vou expandir o seu conhecimento sobre o Git. Existem muitos tutoriais para iniciantes sobre controle de versão com Git. Mas eu vou ajudar você a compreender os conceitos por trás de muitas coisas no Git, como criar o commit perfeito, escolher uma estratégia de branch ou resolver conflitos de merge. Meu objetivo é dar a você mais confiança ao trabalhar com o Git e torná-lo um usuário avançado do Git.

Antes de começarmos, gostaria de agradecer à equipe do Free Code Camp, muito obrigado por estar nessa missão de ensinar as pessoas a codificar. E obrigado por me permitir contribuir um pouco. Um pouco sobre minha formação, faço parte da equipe por trás do Tower, que é uma interface gráfica de desktop para o Git para Mac e Windows. Estamos há mais de 10 anos ajudando mais de 100.000 desenvolvedores e designers a trabalhar de forma mais fácil, produtiva e com menos erros com o Git. Para a sessão de hoje, você não precisa ter o Tower instalado, pode seguir no terminal, sem problemas. Vamos começar.

Criando o Commit Perfeito

Portanto, vamos falar um pouco sobre como criar o commit perfeito. A primeira parte é adicionar as alterações corretas. E a segunda parte é compor uma boa mensagem de commit. Vamos começar adicionando as alterações ao commit. Nosso objetivo aqui é criar um commit que faça sentido, que inclua apenas alterações de um único tópico. Em contraste com o método fácil, onde às vezes juntamos todas as alterações locais atuais no próximo commit. Isso é ruim e não devemos fazer. Mas ser seletivo e decidir com cuidado o que deve ir para o próximo commit é realmente importante. Este é um exemplo de como um commit melhor deveria parecer, porque separa diferentes tópicos. Por outro lado, quanto maior um commit e mais tópicos estiverem misturados no commit, mais difícil fica de entender, tanto para seus colegas quanto para você mesmo no futuro. O conceito de área de preparação do Git é realmente útil nesse contexto, permite que você selecione arquivos específicos ou até partes desses arquivos para o próximo commit. Então, esse é o poder da área de preparação, você pode selecionar arquivos individuais para um commit e até partes dos arquivos para um commit e deixar outros para um futuro commit.

Vamos dar uma olhada em um exemplo prático. Nos últimos horas ou talvez até dias, criamos um monte de alterações, vamos dizer git status aqui. Mas vamos supor que nem todas essas alterações se refiram ao mesmo tópico. Vamos seguir a regra de ouro do controle de versão e apenas combinar alterações do mesmo tópico em um único commit. Você provavelmente já sabe que para incluir um arquivo específico, podemos simplesmente digitar git add e o nome do arquivo. Então, vamos adicionar esse arquivo CSS aqui. E voilà, vamos dar uma olhada mais de perto em outro arquivo index HTML e ver quais alterações ele contém no momento. Para isso, podemos usar git diff. E podemos ver que existem dois trechos de alterações no momento. Vamos dizer que o primeiro pertence ao tópico do próximo commit, mas não o segundo. Portanto, vamos adicionar a primeira parte à área de preparação. Podemos fazer isso com a flag git add -p. P nos leva ao nível de patch, queremos decidir no nível de patch o que incluir e o que não. E queremos fazer isso com index HTML. Agora, o Git passa por cada trecho de alterações e nos pergunta simplesmente se queremos adicionar esse trecho à área de preparação ou não. Portanto, não se preocupe com todas as outras respostas possíveis que você pode dar nessa situação. Eu não as conheço e quero dormir à noite sem estresse. Um simples s para Sim, ou n para Não é suficiente. Vamos dizer que este é realmente o tópico que queremos cometer. Então, digamos que sim, queremos incluir isso. E para o segundo, este não é o mesmo tópico. Então, vamos deixar isso fora da área de preparação por enquanto. Se agora dermos outra olhada em git status, podemos ver que partes do index HTML serão incluídas nas próximas alterações do próximo commit, e outras partes serão deixadas para um commit futuro novamente. Assim, index HTML é listado duas vezes, incrível. Criar um commit dessa maneira muito granular ajudará você a criar um histórico de commit muito valioso, fácil de ler e entender. E isso é crucial se você quiser estar por dentro das coisas.

Agora, vamos falar sobre a segunda parte de criar o commit perfeito, que é fornecer uma ótima mensagem de commit. Vamos começar com a linha de assunto. Claro, as convenções são diferentes entre as equipes, mas geralmente, o conselho é escrever algo muito conciso, com menos de 80 caracteres, se possível. E a linha de assunto deve ser um resumo muito breve do que aconteceu. E aqui está uma pequena dica, se você tem dificuldade em escrever algo curto e conciso, isso pode ser um indicativo de que você colocou muitos tópicos diferentes nesse commit, certo. Então, vamos para o terminal. E se eu digitar git commit agora, eu vou abrir uma janela do editor onde posso inserir uma mensagem de commit. E vamos escrever algo simples, adicionado captura para inscrição por e-mail. Se adicionarmos uma linha em branco após o assunto, o git saberá que estamos escrevendo o corpo da mensagem e terá espaço para uma explicação muito mais detalhada. Portanto, aqui estão algumas perguntas que você pode querer responder com o corpo da mensagem de commit. O que é diferente do antes, qual é a razão para a mudança? E há algo a se observar ou algo particularmente notável sobre esse commit. Vou escrever minha versão disso no editor de texto aqui. E voilà, então vamos salvar e fechar isso. E o commit está feito. Vamos dar uma olhada rápida em git log, e podemos ver. Okay, então este é o último commit que acabamos de fazer. Esta é a linha de assunto, e este é o corpo da mensagem. Respondendo a essas perguntas, você está fazendo um grande favor aos seus colegas e a si mesmo no futuro, porque ajuda a entender o que exatamente aconteceu nesta revisão e o que observar.

Estratégias de Branch

Este é um tópico importante porque o Git deixa completamente a seu critério como você quer trabalhar com branches. Ele fornece apenas a ferramenta, mas você e sua equipe são responsáveis por usá-la da melhor maneira possível. Isso nos leva ao primeiro item: convenções. Se você trabalha em equipe, é necessário criar uma convenção clara sobre como deseja trabalhar com branches. E você precisa escrever isso em algum lugar onde todos possam acessar. Por que sua equipe precisa de uma convenção escrita, você pergunta, porque o Git permite que você crie branches, mas não diz como usá-los, você precisa de uma prática recomendada por escrito sobre como o trabalho deve ser idealmente estruturado em sua equipe para evitar erros e colisões. Isso depende muito do tamanho da sua equipe e do projeto, de como você lida com as versões do seu software. Por último, mas não menos importante, ajuda a integrar novos membros da equipe. Quando novas pessoas se juntam à sua equipe, você pode apontar para a convenção documentada e elas rapidamente entenderão como os branches são tratados em sua equipe. Quando você pensa sobre como deseja trabalhar com branches, você automaticamente pensa em como integrar as alterações e estruturar as versões. Esses tópicos estão intimamente relacionados. Para ajudá-lo a entender melhor suas opções, vamos simplificar um pouco. Vou mostrar duas versões extremas de como você poderia projetar seus fluxos de trabalho de branches. O lema do primeiro é sempre integrar o desenvolvimento da linha principal. Sempre integre seu trabalho com o trabalho da equipe. Esse é o lema aqui. E é assim que poderia ser. Neste exemplo, temos apenas um branch onde todos contribuem com seus commits. Esse é um exemplo realmente simples, duvido que alguma equipe no mundo real tenha uma estrutura de branch tão simples. Mas para ilustração, esse exemplo extremamente simplificado nos ajuda a entender as vantagens e desvantagens desse modelo. Em um modelo de sempre estar integrando, você tem muito poucos branches. Isso facilita o acompanhamento das coisas em seu projeto. Claro, os commits também devem ser relativamente pequenos, esta é uma exigência natural porque você não pode arriscar grandes commits inchados em um ambiente onde as coisas são constantemente integradas no código de produção. E isso também significa que você deve ter um ambiente de teste de alta qualidade configurado. Novamente, a premissa neste modelo é que o código é integrado muito rapidamente em sua linha principal, seu código de produção. E isso significa que os padrões de teste e QA em sua equipe devem ser excelentes. Se você não tiver isso, esse modelo não funcionará para você. O outro extremo do espectro é quando vários tipos diferentes de branches entram em cena. Aqui, os branches são usados para cumprir diferentes funções. Novas funcionalidades e experimentos são mantidos em seus próprios branches. As versões podem ser planejadas e gerenciadas em seus próprios branches. E até diferentes estados no fluxo de desenvolvimento, como produção e desenvolvimento, podem ser representados por branches. Lembre-se de que tudo isso depende das necessidades e requisitos de sua equipe e projeto, é difícil dizer que uma abordagem é melhor que a outra. Embora um modelo como este pareça complicado, na maior parte é uma questão de prática e se acostumar com ele. E como já mencionei, na realidade, a maioria das equipes está trabalhando em algum lugar entre esses extremos.

Agora vamos dar uma olhada mais de perto em dois tipos principais de branches e como eles são usados. Esses dois tipos são branches de longa duração e branches de curta duração. A distinção entre um branch de longa duração e um branch de curta duração é uma das mais amplas que você pode fazer e muito útil. Vamos falar sobre os branches de longa duração primeiro. Todo repositório Git contém pelo menos um branch de longa duração, normalmente algo chamado main ou master. Mas pode haver também outros branches de longa duração em seu projeto, como desenvolver, produção ou teste. Esses branches têm algo em comum, eles existem durante todo o ciclo de vida do projeto. Já mencionei um exemplo típico de tal branch de longa duração. Todo projeto tem um branch principal, como master ou main. E outro tipo de branch de longa duração são os chamados branches de integração, geralmente chamados de desenvolver ou teste. Tipicamente, esses branches representam estados em um processo de lançamento ou implantação do projeto. Se seu código passa por diferentes estados, por exemplo, de desenvolvimento para teste para produção, faz muito sentido refletir a estrutura em seus branches também. E, finalmente, muitas equipes têm uma convenção relacionada a branches de longa duração. Tipicamente, os commits nunca são adicionados diretamente a esses branches. Os commits só devem chegar ao branch de longa duração por meio de integração, em outras palavras, por meio de um merge ou rebase. Há várias razões para essa regra. Uma tem a ver com qualidade. Você não quer adicionar código não testado e revisado ao seu ambiente de produção, por exemplo. E é por isso que o código passa por diferentes estados, testes e revisões antes de chegar finalmente à produção. Outra razão pode ser a empacotamento e agendamento de lançamentos, você pode querer lançar novo código em lotes, talvez até agendados minuciosamente. E sem essa regra, quando o código é diretamente commitado nos branches de longa duração como main, monitorar o que está sendo lançado se torna bastante difícil.

Agora, o outro tipo de branches são os branches de curta duração. Em contraste com os branches de longa duração, eles são criados para fins específicos e depois excluídos após serem integrados. Existem muitos motivos diferentes para criar branches de curta duração. Por exemplo, quando você começa a trabalhar em uma nova funcionalidade, uma correção de bug ou uma refatoração ou um experimento. Tipicamente, um branch de curta duração será baseado em um branch de longa duração. Por exemplo, quando você inicia uma nova funcionalidade, pode basear essa nova funcionalidade no seu branch principal de longa duração, por exemplo, e após fazer alguns commits e finalizar seu trabalho, você provavelmente vai querer integrá-lo de volta ao principal. E depois de fazer isso com segurança, após mesclar ou rebaseá-lo, seu branch de funcionalidade pode ser excluído. E já mencionei que as estratégias de branch serão diferentes para cada equipe e projeto. Depende muito de suas preferências, tamanho da equipe, tipo de projeto. Mas gostaria de te dar uma visão de duas estratégias de branch bastante populares e levar ambas como inspiração para sua própria estratégia de branch individual. Vamos começar com o fluxo do GitHub. O GitHub advoga por um fluxo de trabalho extremamente enxuto e simples. Ele possui apenas um branch de longa duração, o branch principal padrão, e tudo o que você está trabalhando é feito em um branch separado, um branch de curta duração, seja uma nova funcionalidade, uma correção de bug ou uma refatoração. Então, esta é uma configuração muito simples, muito enxuta. Outro modelo muito popular é chamado Git flow. E este oferece um pouco mais de estrutura, mas também mais regras a seguir. Então, o branch principal é um reflexo do estado atual de produção. O outro branch de longa duração é tipicamente chamado de desenvolver e quaisquer branches de funcionalidade começam a partir deste e serão mesclados de volta para ele. O desenvolver também é o ponto de partida para novos lançamentos, você abriria um novo branch de lançamento, faria seus testes, cometeria quaisquer correções de bugs nesse branch de lançamento. E depois de ter certeza de que está pronto para produção, você o mesclaria de volta ao principal, você então adicionaria uma tag para esse lançamento, commitaria no main e fecharia o branch de lançamento. Como você pode ver, o Git flow define vários trabalhos e etapas no processo. No Tower, a interface gráfica de desktop para Git que fazemos, apoiamos os usuários oferecendo essas tarefas como atalhos no aplicativo. E assim, posso te mostrar aqui, para que você tenha todas as ações mais importantes que o Git flow traz a você. Então você não precisa lembrar de todos os detalhes e o que você tem que fazer e o que vem a seguir, que compõem essas diferentes etapas. Então, se você perguntar a diferentes equipes como elas estão usando branches, você receberá muitas respostas diferentes. Não há um modelo de branch perfeito que todos devam adotar. É mais sobre entender seu projeto, seu fluxo de lançamento e sua equipe e, em seguida, modelar um fluxo de trabalho de branch que o apoie da melhor maneira possível.

Pull Requests

Antes de mais nada, é importante entender que pull requests não são uma funcionalidade central do Git. Eles são fornecidos pela sua plataforma de hospedagem Git, o que significa que funcionam e parecem um pouco diferentes no GitHub, GitLab, Bitbucket, Azure DevOps ou o que você estiver usando. Mas os princípios e ideias básicas são sempre os mesmos. Vamos começar falando sobre por que você gostaria de usar pull requests. Em essência, eles são uma maneira de comunicar sobre o código e revisá-lo. O exemplo perfeito é quando você terminou de trabalhar em uma funcionalidade, sem um pull request, você simplesmente mesclaria seu código no main, master ou em algum outro branch. E em alguns casos, isso pode ser totalmente aceitável. Mas especialmente quando suas alterações são um pouco mais complexas ou um pouco mais importantes, você pode querer ter um segunda opinião sobre seu código. E é exatamente para isso que os pull requests foram feitos. Com os pull requests, você pode convidar outras pessoas para revisar seu trabalho e dar feedback. E após uma conversa sobre o código, seu revisor pode aprovar o pull request e mesclá-lo em outro branch. Além disso, há outro caso de uso importante para os pull requests. É uma maneira de contribuir com o código de repositórios para os quais você não tem acesso direto. Pense em um repositório de código aberto popular, você pode ter uma ideia para melhorar algo, mas você não é um dos

Tutorial Git para Profissionais – Ferramentas e Conceitos para Dominar o Controle de Versão com Git

O Git é uma ferramenta essencial para qualquer desenvolvedor profissional que deseja controlar o versionamento de seus projetos de forma eficiente e segura. Neste tutorial, vamos abordar algumas das principais ferramentas e conceitos do Git que ajudarão você a se tornar um mestre no controle de versão.

O que é o Git e por que é importante para profissionais?

O Git é um sistema de controle de versão distribuído que permite aos desenvolvedores rastrear as alterações em seus códigos-fonte ao longo do tempo. Ele oferece uma série de benefícios, como o registro de alterações, a possibilidade de trabalhar em paralelo com outros desenvolvedores e a facilidade de reverter para versões anteriores em caso de problemas.

Para profissionais de desenvolvimento de software, o Git é uma ferramenta indispensável que ajuda a garantir a integridade e a colaboração nos projetos, além de proporcionar um histórico detalhado de todas as alterações realizadas.

Principais ferramentas do Git para profissionais

1. Repositórios Git

Os repositórios Git são onde todo o código-fonte e histórico de alterações de um projeto são armazenados. Através dos repositórios, é possível clonar, fazer commit, pull e push das alterações, garantindo a sincronização entre os desenvolvedores e as diferentes versões do projeto.

2. Branches e Merges

As branches no Git permitem que os desenvolvedores trabalhem em novas funcionalidades de forma isolada, sem interferir no código principal do projeto. Após o desenvolvimento e teste das novas funcionalidades, é possível fazer o merge das branches para incorporar as alterações ao código principal.

3. Commits e Log

Os commits são fundamentais no Git, pois representam cada alteração feita no código-fonte. É importante adicionar mensagens descritivas e concisas em cada commit, para facilitar o entendimento das alterações realizadas. O comando git log permite visualizar o histórico de commits do projeto.

4. Revert e Reset

Em caso de erros ou problemas no código, o Git oferece as opções de revert e reset para desfazer alterações indesejadas. O comando git revert cria um novo commit que desfaz as alterações especificadas, enquanto o git reset permite voltar para commits anteriores.

Conceitos avançados do Git para profissionais

1. Rebasing

O rebasing é uma técnica avançada para reorganizar e simplificar o histórico de commits de um projeto. Ele permite reescrever o histórico de commits de uma branch, tornando-o mais limpo e linear, facilitando o entendimento das alterações realizadas.

2. Stashing

O stashing é útil quando você precisa guardar temporariamente alterações não finalizadas em um projeto. Isso permite que você mude de contexto ou resolva outros problemas antes de retornar e aplicar as alterações guardadas no momento oportuno.

3. Submódulos

Os submódulos no Git permitem incluir repositórios externos dentro de um projeto, facilitando o gerenciamento de dependências e bibliotecas em um projeto. Isso ajuda a manter as dependências atualizadas e sincronizadas com o código-fonte principal.

Com as ferramentas e conceitos abordados neste tutorial, você estará mais bem preparado para dominar o controle de versão com o Git e se tornar um profissional mais eficiente e colaborativo no desenvolvimento de software. Experimente aplicar esses conhecimentos em seus projetos e veja como o Git pode melhorar sua produtividade e qualidade de trabalho.

Importância da educação para profissionais de TI

A educação é fundamental para a formação de profissionais de Tecnologia da Informação que desejam se destacar no mercado de trabalho. No caso do Git for Professionals Tutorial – Tools & Concepts for Mastering Version Control with Git, o conhecimento aprofundado em controle de versão com Git pode ser adquirido por meio de cursos e treinamentos especializados. A constante atualização e capacitação são essenciais para acompanhar as inovações tecnológicas e se manter competitivo na área.

Desenvolvimento de habilidades e competências

O aprendizado de novas ferramentas e conceitos, como o Git for Professionals, contribui para o desenvolvimento de habilidades técnicas e competências profissionais. A prática constante e a busca por aperfeiçoamento são cruciais para a evolução na carreira de um profissional de TI. Além disso, a educação proporciona a oportunidade de adquirir conhecimentos específicos e se aprofundar em áreas de interesse, como controle de versão com Git.

Investimento em educação como diferencial competitivo

O investimento em educação é um diferencial competitivo para profissionais de TI que buscam se destacar no mercado de trabalho. O Git for Professionals Tutorial – Tools & Concepts for Mastering Version Control with Git oferece a oportunidade de adquirir conhecimentos especializados e se tornar um especialista em controle de versão com Git. A atualização contínua e o aprimoramento profissional são essenciais para acompanhar as demandas do mercado e se destacar como um profissional de TI de sucesso.

O papel da educação na formação de profissionais de TI e sua importância para o mercado de trabalho

Em um cenário cada vez mais competitivo, a educação se torna um diferencial fundamental para profissionais de Tecnologia da Informação que buscam se destacar. O Git for Professionals Tutorial – Tools & Concepts for Mastering Version Control with Git é uma ferramenta essencial para aprimorar as habilidades e competências necessárias para atuar com excelência na área. Investir em educação é investir em si mesmo e no futuro da carreira profissional.

Fonte Consultada: Texto gerado a partir do Vídeo https://www.youtube.com/watch?v=Uszj_k0DGsg do Canal freeCodeCamp.org .