Suas instrutoras nesse curso serão: Camila Maia e Maria Antônia Maia - caso você não tenha percebido as semelhanças: somos primas e parceiras nesse projeto incrível chamado Cumbuca Dev.

O projeto nasceu de uma demanda pessoal, Camila estava mentorando a Maria para fazer a transição de carreira para o mercado de TI. Acontece que nada era tão simples quanto parecia, e mesmo com algum tempo de estudo a Maria não conseguia enxergar um panorama em que alcançaria alguma vaga real de emprego na área de T.I. Passou em alguns bootcamps, cursos imersivos, programas de iniciação... mas a vaga de emprego sempre ia para pessoas com o mesmo perfil.

Desanimada e brocochô, a Maria até pensou em desistir de tudo e continuar nos empregos convencionais - que na região além de serem escassos, não permitiam o desenvolvimento e crescimento pessoal. Foi então que a Camila resolveu mostrar como todo esse conteúdo que a Maria havia aprendido não servia só para ocupar espaço na memória, e usou (pausa dramática).... OPEN SOURCE para mostrar para ela que o conhecimento que tinha já poderia ser usado e dessa forma ela poderia aprender como seria trabalhar nesse mercado de trabalho.

Esse tipo de abordagem foi um divisor de águas para a Maria e , a partir deste momento, tudo começou a mudar. Os conteúdos que a Maria aprendia, além de conseguir fixar com mais qualidade e facilidade de aprendizagem, ela conseguiu se conectar ainda mais com a possibilidade de migrar totalmente para a área de T.I. Foi então que começaram a pensar: se conseguimos mudar a vida de uma pessoa, porquê não ajudar a mudar a realidade de tantas outras que precisam?

Assim nasceu a Cumbuca Dev: uma organização que se dedica apaixonadamente a promover a diversidade e a igualdade na área de Tecnologia da Informação (TI). Através de programas educacionais abrangentes, capacitamos e apoiamos ativamente grupos minoritários, visando não apenas sua inclusão, mas também o desenvolvimento de líderes em potencial dentro de cada setor.

Utilizamos a metodologia desenvolvida de aprendizado constante com uso de Código Aberto para poder romper o ciclo vicioso que impede muitos indivíduos de conquistarem oportunidades no setor de TI: a falta de experiência que dificulta a obtenção de emprego e a impossibilidade de adquirir experiência sem trabalho na área.

Acreditamos na importância de colaboração, transparência e igualdade de oportunidades, e estamos comprometidas em promover um ambiente de T.I. mais justo e inclusivo, onde o compartilhamento de conhecimento e recursos é incentivado e valorizado, tudo isso através da abordagem de código aberto: nossos materiais, estudos e até mesmo nosso site é Open Source, sendo assim todos podem acessar, compartilhar e contribuir.

Boas-vindas a todas as pessoas participantes do curso GitHub Essentials: um curso pensado especialmente para quem nunca teve contato com esta ferramenta tão poderosa. Este treinamento é composto de alguns fundamentos básicos e muita prática, para que você possa aprender entendendo o que está fazendo e, aos poucos, ganhe ainda mais confiança na colaboração e gestão de projetos.

Como o foco do curso é o próprio GitHub, suas ferramentas, o fluxo de trabalho e todas as facilidades que ele oferece, não se preocupe: não focaremos em nenhuma linguagem de programação. Para participar do curso só é necessário ter acesso à internet, conhecimentos básicos de uso do computador e uma conta de e-mail válida, que você possua acesso.

Apesar de esta ser uma ferramenta muito utilizada no dia a dia de pessoas Desenvolvedoras, não há restrições para o uso da plataforma, que disponibiliza na conta gratuita várias funções relevantes até mesmo para quem não trabalha com T.I. Então acaba sendo muito interessante para qualquer tipo de profissional que precise:

• Controlar versões de arquivos;

• Colaborar em projetos com outras pessoas;

• Compartilhar seu trabalho com a comunidade;

• Aprender com outros profissionais;

E muito mais... Além de ser uma grande plataforma, que usa parâmetros de segurança avançados e sempre acompanha as novidades em tecnologia. Aqui, é possível usar a sua criatividade para melhorar sua produtividade, seja qual for sua profissão.

Geralmente pessoas iniciantes em TI são apresentadas à plataforma apenas como um ambiente onde podem incluir seus portfólios, quando estão à procura da primeira oportunidade na área. Mas, queremos te mostrar que o GitHub é muito mais do que somente a sua carta de apresentação; ele pode, também, ser um forte aliado nos seus estudos, networking e até mesmo no aprendizado das soft skills necessárias para o trabalho.

Estamos muito felizes com sua presença aqui e prontas para guiar essa jornada de aprendizado e colaboração em uma ampla rede de troca de conhecimentos. Bora iniciar nossos estudos?

Mas, Open Source não se limita apenas por essa definição. Ele é um grande ecossistema que conta com comunidades super ativas, que encontram soluções diferentes para (quase) tudo! É muito comum que existam versões Open Source de vários tipos de softwares, bibliotecas, frameworks e é incrível ver o que a comunidade cria para devolver justamente para a comunidade. Todos saem ganhando, não importa o nível de complexidade do desenvolvimento. Simplesmente incrível!

Mas... se os conteúdos são de acesso gratuito, qual a vantagem em termos "corporativos"?

Vantagens corporativas do Open Source:

1. Adaptabilidade:

   • A flexibilidade do Open Source permite que as empresas adaptem e personalizem os softwares de acordo com suas necessidades específicas, sem as limitações impostas pelos fornecedores de software proprietários.

2. Código Sempre Atualizado:

   • Um software Open Source dificilmente ficará obsoleto, pois a comunidade global de desenvolvedores está continuamente identificando problemas, corrigindo bugs e implementando novas funcionalidades. Essa dinâmica de constante atualização garante que o software permaneça relevante, seguro e eficiente ao longo do tempo, adaptando-se rapidamente às mudanças tecnológicas e às novas necessidades dos usuários.

3. Colaboração Competitiva:

   • Empresas que competem em outras áreas colaboram no desenvolvimento de softwares Open Source. Essa colaboração não se limita apenas ao sistema operacional; ela se estende a uma vasta gama de projetos, bibliotecas e frameworks que são fundamentais para a infraestrutura de TI. Além disso, a colaboração permite que as empresas compartilhem custos de desenvolvimento e beneficiem-se das melhorias feitas por outros participantes, o que resulta em uma base de código mais rica e confiável. A competição é mantida nos produtos e serviços finais, mas a colaboração no desenvolvimento das ferramentas básicas cria um ecossistema mais saudável e dinâmico. Um exemplo é o GNU/Linux, onde a colaboração melhora tanto o software quanto o hardware, garantindo máxima performance e otimização.

4. Economia:

   • O fato de não ter gastos com licenciamento é importante e deve ser levado em conta. A redução de custos permite que a empresa invista em outras áreas, como infraestrutura e hospedagem em nuvem, melhorando a disponibilidade, segurança e desempenho dos seus sistemas.

5. Escalabilidade:

   • Softwares de código aberto à medida que uma empresa expande suas operações, ele pode ser ajustado para lidar com um aumento no volume de usuários, dados e transações sem comprometer o desempenho. A flexibilidade do Open Source permite que os sistemas sejam adaptados e otimizados continuamente, garantindo que a infraestrutura de TI possa crescer de forma eficiente e econômica, acompanhando todas as fases do crescimento de uma empresa.

6. Resolução Rápida de Problemas:

   • Diferente dos softwares proprietários, onde o suporte pode ser lento e centralizado, o Open Source disponibiliza de forma imediata uma vasta base de conhecimento e experiência contidos nas comunidades, onde é normal encontrar pessoas que já passaram pelo mesmo problema ou caso parecido, e ali vão trocando informações e trabalhando em conjunto para poder encontrar a melhor solução.

7. Transparência e Segurança:

   • E por último, mas não menos importante: com o código aberto, é possível saber exatamente quais dados estão sendo transferidos e para onde. A segurança dos softwares Open Source é reforçada pela transparência de seu código, permitindo que qualquer pessoa possa inspecioná-lo para identificar e corrigir vulnerabilidades rapidamente. Além disso, como muitos desenvolvedores e especialistas em segurança estão constantemente revisando o código, problemas podem ser detectados e resolvidos de forma mais ágil do que em softwares proprietários. Esta é inclusive uma das maiores vantagens observadas pelas empresas.

Mas não para por aí: além de ser super vantajoso para as empresas, o Código Aberto pode ser um grande aliado no seu aprendizado e carreira!

Conhecer um pouco mais sobre esse movimento e entender o tipo de impacto que ele causa tanto nas pessoas quanto nas empresas, no estilo de desenvolvimento e até mesmo na economia global foi, particularmente, um divisor de águas no meu processo de aprendizagem. Foi a primeira vez que me senti efetivamente "fazendo parte" de algo relacionado a tecnologia e é por isso que decidimos te apresentar para esse mundo mágico: onde a colaboração é regra e o crescimento é compartilhado.

Quando se trata de aprendizado, principalmente quando se é iniciante, há muita teoria para se aprender. Paradigmas de programação, conceitos, lógica e tantos outros assuntos que servem de base para qualquer que seja a linguagem escolhida, não há como fugir. Mas o Open Source pode ser seu aliado na hora de fixar e principalmente visualizar esses conteúdos na prática - mesmo que você ainda não trabalhe na área.

Vantagens Open Source no Aprendizado:

1. Aprendizado Prático: Iniciantes podem aprender examinando códigos de alta qualidade, além de contribuir em projetos reais. Sendo assim: toda contribuição é válida e não necessariamente pode ser feita em alguma linguagem de programação específica, há projetos que precisam de ajuda na escrita da documentação, tradução, organização e tantas outras tarefas simples de serem efetuadas.

2. Comunidade e Colaboração: Participar deste tipo de projeto oferece a oportunidade de receber feedback, colaborar com outros desenvolvedores e aprender com a experiência de profissionais mais experientes. Além disso, ao colaborar com projetos Open Source consequentemente sua rede de contatos (network) pode aumentar consideravelmente, e conhecer pessoas do meio pode ser um bom caminho para conseguir novas oportunidades.

3. Experiência Real: Trabalhar em projetos open source ajuda a ganhar experiência prática, o que é altamente valorizado no mercado de trabalho. Somando-se à tudo isso você ainda contribui para uma comunidade gigante, e pode gerar impacto na vida e trabalho de outras pessoas, não é demais!?

"Ah, mas eu não acho que desenvolver 'de graça' vai me trazer benefícios"

Então aqui vão as vantagens para a sua carreira - lembrando que, se as empresas estão ganhando dinheiro com todo esse ecossistema é altamente provável que elas também estarão de olho em profissionais que colaboram nesse meio.

Impacto do Open Source na Carreira

• Portfólio e Visibilidade: Contribuições para projetos de Código Aberto podem ser exibidas como portfólio, demonstrando habilidades e comprometimento tanto com a comunidade quanto com os projetos.

• Oportunidades de Emprego: Dificilmente a empresa irá fazer uma contratação se a pessoa desenvolvedora não tiver experiência alguma, seja para sua primeira oportunidade, ou quem sabe uma mudança de carreira dentro do próprio mercado de TI. Contribuir em projetos pode quebrar esse ciclo da não experiência e abrir portas para experimentações.

• Desenvolvimento de Habilidades: Trabalhar em projetos open source ajuda a desenvolver habilidades técnicas e de colaboração, essenciais para qualquer desenvolvedor. As famosas "soft-skills" hoje super em alta no mercado.

Conclusão

Seja para você ampliar seus estudos, experimentar novos caminhos, conseguir aquela experiência prática ou se sentir parte de uma comunidade e impactar outras pessoas... Open Source é o caminho. Te encorajamos a seguir nesse caminho para melhorar o aprendizado contínuo e continuar a trazer muito mais inovação para o nosso dia a dia.

Antes de colocarmos a "mão na massa" é muito importante que você conheça alguns dos principais conceitos que utilizamos no Git, assim você já vai se ambientando e compreendendo os próximos passos!

Primeira Metade: Dia 1 ao Dia 5

Dia 1 - Introdução

• Apresentação do Curso

• Mapa do Curso

• Qual a importância de conhecer a plataforma

• Aprendizado constante com Open Source

Dia 2 - Controle de Versão Básico com Git

Seção 1:

• O que é? o que resolve?

• A importância de se saber pelo menos o básico de Git

• Ferramentas Associadas

• O que é um controle de versionamento?

• Controle de versão distribuído

Seção 2:

• Instalação do Git

• Principais comandos

• Extensões

• Indicação: Jogo “Oh my git” para entender sobre a linha do tempo (demo)

Dia 3 - Prazer, GitHub

• Qual a diferença entre Git e GitHub?

• Apresentar a plataforma: o que podemos encontrar nela?

• GitHub Features: ferramentas para desenvolvimento e manutenção de código

Dia 4 - Contas e Planos

• GitHub Free - contas pessoais (mostrar que apenas com a conta grátis há uma infinidade de ferramentas e opções)

• GitHub Free - para organizações

• Criação de uma conta pessoal no GitHub (demonstrativo)

• Apresentação conta: settings, autenticação de 2F, barra lateral

• Apresentação Home e notificações

Dia 5 - Tudo sobre repositórios

• O que são, porque existem

• Criar um primeiro repositório (README, .gitignore) - demonstrativo na plataforma

• Tópicos, labels, issues, geral (Repos)

• Overview repositório já antigo

• Overview aba CODE

• Overview aba settings

Segunda Metade: Dia 6 ao Dia 10

Dia 6 - Markdown

• Demonstração utilizando a README do profile criado

• O que é Markdown?

• Documentação oficial

Dia 7 - Clonando um repositório

• Git clone

• Adicionando a chave SSH

• Qual a utilidade…

• Como participar de outros projetos usando o git clone

Dia 8 - Minha primeira issue

• Demonstrar como funciona e a importância

• Explicar sobre as labels

• Mostrar como funcionam as issues em projetos BRs existentes

Dia 9 - Meu primeiro PR

• Nomenclatura da Branch

• Como abrir um Pull Request, review, merge (exemplo: primeiro repositório criado)

• Assign

Dia 10 - Desafio final - Contribuindo em um repositório Open Source

• Criaremos alguns repositórios sem linguagem de programação alguma, para que os participantes possam treinar e colocar em prática tudo o que foi ensinado.

1. Antes de Começar

2. Fundamentos de Controle de Versão e Git

3. Operações Locais Básicas no Git

4. Ajuste de Mudanças Locais no Git

5. Introdução ao GitHub

6. Repositórios no GitHub

7. Documentação de Projetos

8. Issues no GitHub

9. Git Remoto

10. Pull Requests no GitHub

11. Fluxo de Trabalho

12. O Caminho Continua

Sistemas Distribuídos

Os Sistemas de Controle de Versão Distribuídos (DVCS - Distributed Version Control Systems) são uma evolução dos sistemas centralizados. Neles, cada pessoa colaboradora faz a cópia do repositório central integralmente, obtendo assim o histórico completo do projeto em seu próprio computador.

Diferentemente dos sistemas centralizados, onde apenas a versão mais recente é disponibilizada, neste modelo, cada cópia (clone) contém não apenas os arquivos do projeto, mas também todos os metadados associados ao repositório original.

A estrutura distribuída foi criada para endereçar a maior parte dos problemas percebidos nos sistemas centralizados.

Motivação: endereçar problemas dos sistemas centralizados

Um único ponto de falha coloca em risco os dados

No sistema centralizado, caso algo venha a acontecer com o servidor e o repositório central for comprometido, isso resulta em uma perda definitiva do código.

Já no sistema distribuído, como cada pessoa colaboradora possui uma cópia completa do repositório em seu computador, tendo acesso a todo o histórico, é possível restaurar o projeto a partir de suas cópias locais.

Necessidade de conexão com o servidor

As pessoas dependem do acesso contínuo ao servidor central para realizar operações de controle de versão no sistema centralizado. Se o servidor ficar inacessível, por exemplo, todas as atividades de trabalho ficam interrompidas.

No sistema distribuído, entretanto, não há essa dependência de conexão com o servidor. Isso significa que a maior parte do desenvolvimento pode ser realizada offline. Apenas as operações de enviar (push) e receber (pull) modificações que ficam restringidas a necessidade de uma conexão.

As pessoas colaboradoras têm acesso ao histórico completo do projeto em seus próprios computadores, permitindo que façam alterações diretamente em seus repositórios locais. Isso possibilita que realizem suas modificações como um conjunto de alterações, adiando o envio para quando estiverem online novamente.

Conexão lenta atrasa o desenvolvimento

Em sistemas centralizados, os usuários enfrentam dificuldades ao realizar mudanças devido à comunicação necessária com o servidor remoto, o que torna o processo mais lento, especialmente em conexões de rede lentas.

Por outro lado, em sistemas distribuídos, os usuários podem fazer alterações de forma ágil e autônoma em seus repositórios locais, permitindo trabalhar sem depender constantemente do servidor remoto, realizando suas modificações como um conjunto de alterações, adiando o envio para quando estiverem online novamente.

Poucos momentos estáveis para enviar mudanças (push)

Quando muitos pessoas precisam trabalhar na mesma parte do código, fica complicado decidir quando fazer as alterações. Se as mudanças ainda não estão estáveis, não podem ser enviadas para o local onde todos compartilham o código, então cada desenvolvedor precisa mantê-las guardadas no seu próprio computador até que estejam prontas.

Essa demora em compartilhar as mudanças pode atrasar o projeto e causar conflitos quando diferentes partes do código são mescladas. Isso acontece porque outros membros da equipe não conseguem ver as alterações que só existem no computador das outras pessoas. Quando finalmente as mudanças são enviadas para o local compartilhado, é preciso resolver esses conflitos rapidamente para que todos possam continuar trabalhando juntos.

Nos sistemas de controle de versão distribuído é mais fácil criar diferentes versões do código, chamadas de ramificações (branches). Isso porque cada pessoa tem uma cópia completa do histórico do projeto no seu próprio computador. Elas podem experimentar novas ideias rapidamente e pedir opiniões sobre o código antes de unir suas mudanças ao projeto principal.

Com menos pessoas trabalhando na mesma parte do código, os conflitos são menos comuns. Além disso, ter acesso ao histórico completo torna-se mais fácil encontrar erros, ver o que foi modificado e até voltar para uma versão anterior do código, se necessário.

Visão Geral

Um sistema de controle de versão distribuído descentraliza o processo de gerenciamento de projetos, passando de um único repositório central ou servidor para um modelo onde cada membro da equipe possui uma cópia completa do projeto em seu próprio repositório local. Isso não apenas aprimora o fluxo de trabalho de desenvolvimento por meio de mesclagens e ramificações rápidas, mas também mitiga significativamente os riscos associados a uma falha no banco de dados central, garantindo que cada participante tenha uma cópia de backup do histórico completo.

Os DVSCs oferecem mais flexibilidade, segurança e eficiência em comparação com os sistemas centralizados. A integração deles no processo de desenvolvimento de software marcou um avanço fundamental na forma como as equipes colaboram e gerenciam seu histórico de controle de versão.

Adquirido pela Microsoft em 2008, o GitHub é muito mais do que apenas uma plataforma de hospedagem de código-fonte. Atualmente, é amplamente reconhecido como a plataforma líder para colaboração em desenvolvimento de software, sendo utilizada pelas principais empresas de tecnologia do mundo.

Com mais de 100 milhões de pessoas desenvolvedoras e mais de 420 milhões de repositórios, o GitHub é um verdadeiro hub global para a comunidade de desenvolvimento. Empresas como Meta, Spotify, Dell, Ford, 3M, entre tantas outras, confiam no GitHub para hospedar e colaborar em seus projetos de software.

Além disso, o GitHub se orgulha de ser a maior comunidade de código aberto do mundo. Seus repositórios abrigam muitas das principais soluções open source, como Mozilla, Linux, Python, entre outros. Essa vasta coleção de projetos open source oferece acesso ilimitado e gratuito, permitindo qualquer pessoa desenvolvedora aprenda, contribua e colabore - isso tudo em uma escala global.

Através do GitHub, pessoas desenvolvedoras têm a oportunidade não apenas de acessar uma enorme variedade de projetos, mas também de aprimorar suas habilidades, aprender com os melhores projetos e contribuir para o avanço da comunidade de software livre.

E não para por aí. O GitHub é mais do que uma plataforma de tecnologia - é um defensor da diversidade, inclusão e pertencimento. Com iniciativas como o MLH Fellowship e a GitHub Education, estão pavimentando o caminho para a próxima geração de desenvolvedores, tornando o desenvolvimento de software acessível para todos, independentemente de quem você é ou de onde vem.

Então, por que você deve investir seu tempo para aprender sobre o GitHub? Porque é mais do que apenas aprender uma ferramenta - é se tornar parte de uma comunidade global de inovadores, criadores e solucionadores de problemas. É abrir as portas para um mundo de oportunidades e adquirir habilidades que são valorizadas pelas principais empresas de tecnologia e fazer parte de uma comunidade que está moldando o futuro do desenvolvimento de software. É sobre aprender, colaborar e construir um futuro melhor juntos. Vamos?!

Motivação

Você consegue se lembrar ou imaginar como era pedir para alguém revisar um documento antes do surgimento de plataformas de edição de textos colaborativa, como Google Docs e Microsoft Word online?

A colaboração em documentos muitas vezes exigia o envio de versões por e-mail ou compartilhamento físico de arquivos em dispositivos de armazenamento, como pen drives. Isso tornava o processo de edição em equipe demorado e propenso a erros de versão.

E quando você precisava voltar para uma versão anterior? O processo era bastante inconveniente, pois você era obrigado a abrir individualmente cada um dos documentos antigos até encontrar a versão correta.

Ou você lembra como era quando se precisava escrever um documento em conjunto com uma ou mais pessoas?

Um dos artifícios mais utilizados era cada pessoa escrever de uma cor diferente para facilmente identificar o quê foi incluído por quem e ficar reenviando os arquivos ao longo da escrita. Um pouco rudimentar, não acha?

Ferramentas como o Google docs surgiram para facilitar estes tipos de tarefas. Com elas, fica muito fácil colaborar e revisar documentos em tempo real com muitas pessoas.

Essas plataformas mantêm um histórico detalhado de revisões, permitindo que os usuários vejam quem fez quais alterações e quando. Isso é útil para rastrear o progresso do trabalho, identificar quem fez determinadas edições e reverter para versões anteriores, se necessário.

Exatamente os mesmo problemas citados para escrita de documentos de texto ocorriam na escrita de documentos de código antes da existência dos sistemas de controle de versão (Version Control Systems - VCS).

O quê são

Sistemas de controle de versão são ferramentas que rastreiam alterações em qualquer conjunto de arquivos de computador. É comumente utilizado no desenvolvimento de software para gerenciar e controlar as mudanças no código-fonte e na documentação de um projeto ao longo do tempo.

Eles permitem que várias pessoas trabalhem simultaneamente no mesmo projeto, facilitando a colaboração, rastreamento de alterações, identificação de problemas e reversão de modificações, entre outras funcionalidades.

Sistemas de controle de versão são essenciais para o desenvolvimento de software em equipe, pois ajudam a manter a integridade do código-fonte, facilitam a colaboração e aumentam a eficiência do desenvolvimento.

Funcionalidades

As principais funcionalidades oferecidas por sistemas de controle de versão incluem:

• Reversão de alterações: Permite reverter para versões anteriores do código, útil para corrigir bugs ou desfazer alterações problemáticas.

• Colaboração: Facilita o trabalho em equipe, permitindo que vários desenvolvedores contribuam para o mesmo projeto simultaneamente.

• Auditoria e Rastreamento de alterações: Registra quem fez o que, quando e por quê em relação ao código e à documentação.

• Ramificação e mesclagem: Permite que os desenvolvedores criem ramificações (cópias separadas do código) para desenvolver novos recursos ou corrigir bugs sem interferir no código principal. Posteriormente, as ramificações podem ser mescladas de volta ao código principal.

Criação

Definição

O Git é um sistema de controle de versão distribuído (DVCS) gratuito e de código aberto, desenvolvido para gerenciar iniciativas de todos os tamanhos com rapidez e eficiência.

Gratuito refere-se ao fato de que o usuário não precisa efetuar nenhum tipo de pagamento para utilizar o software. Já código aberto, significa que:

• O código está disponível para consulta pública;

• Recebe melhorias constantes por meio da colaboração;

• Pode ser adaptado para necessidades diferentes;

Popularidade

Desde a sua criação, o Git se tornou extremamente popular e é amplamente usado por desenvolvedores em todo o mundo, tanto em projetos de código aberto quanto comerciais. Plataformas como GitHub, GitLab e Bitbucket, que hospedam os repositórios Git, contribuíram significativamente para essa popularidade, facilitando a colaboração e o compartilhamento de código.

• Colaboração Efetiva: o Git permite uma colaboração organizada em projetos de software. Cada desenvolvedor pode trabalhar em diferentes partes do projeto sem se preocupar com conflitos, graças aos branches e merges.

• Rastreamento de Mudanças: O Git mantém um histórico completo de todas as alterações feitas no projeto. Isso permite que desenvolvedores revertam mudanças, identifiquem problemas e entendam a evolução do software. A possibilidade de reverter mudanças e corrigir erros facilmente aumenta a confiança ao trabalhar em projetos complexos.

• Segurança: Git armazena uma cópia completa do projeto em cada máquina que usa a ferramenta, garantindo que o projeto esteja seguro, mesmo se um servidor central falhar. Além disso, o uso do algoritmo SHA-1 garante a integridade dos dados, assegurando que todas as alterações são registradas e que o histórico de mudanças é rastreável e protegido contra alterações acidentais ou maliciosas.

• Adaptabilidade: Conhecer Git demonstra que você está atualizado com as ferramentas modernas de desenvolvimento, um diferencial positivo no mercado de trabalho. Dominar essa ferramenta pode aumentar suas chances de conseguir um emprego ou uma promoção.

• Eficiência no Desenvolvimento: Git facilita a experimentação de novas ideias sem comprometer o projeto principal, incentivando a inovação e o desenvolvimento de soluções criativas, além de que o uso frequente do Git contribui para o aprendizado contínuo, aprimorando habilidades de desenvolvimento.

Hoje, o Git é a melhor escolha para a maioria das equipes de software devido à sua funcionalidade, desempenho, segurança e flexibilidade. Ele se tornou um padrão de fato, amplamente adotado e suportado por uma vasta comunidade, além de contar com uma grande quantidade de ferramentas e serviços de software. Por esses motivos, escolhemos essa poderosa ferramenta para você aprender e utilizar junto com o GitHub. Juntos, Git e GitHub proporcionarão uma base sólida e versátil, abrindo inúmeras possibilidades para o seu crescimento e sucesso!

O Git, sistema de controle de versão que iremos utilizar nesse curso, é um sistema distribuído (Distributed Version Control System - DVCS). Para entender a motivação de como o Git foi construído e de como ele funciona, vale a pena conhecer primeiro como era feito antes dele.

Entendendo os Sistemas de Controle de Versão Centralizados

A primeira solução para Sistemas de Controle de Versão consistiu em uma arquitetura centralizada, com um único repositório central onde todo o histórico de alterações e versões do código era armazenado.

Pense nesse repositório central como uma pasta gigante que contém todos os documentos do seu projeto. Não só a versão mais recente, mas também todas as versões anteriores e informações sobre cada uma delas. É como se fosse uma pasta que guarda toda a linha do tempo do seu projeto.

Agora, você pode estar se perguntando como várias pessoas poderiam trabalhar nesse projeto ao mesmo tempo. Bem, o repositório central normalmente fica em um outro computador (servidor), para que mais pessoas possam acessá-lo. Caso contrário, todos teriam que compartilhar o mesmo computador.

Cada pessoa que irá trabalhar no projeto precisa fazer uma cópia da versão mais recente para seu próprio computador, fazer suas mudanças e, em seguida, enviar de volta para o repositório central que está no servidor.

Vamos entender como seria o fluxo de trabalho com um exemplo.

Exemplo de Fluxo de Trabalho

Uma pessoa A e uma pessoa B decidem criar um blog. A pessoa A cria uma estrutura inicial do blog em seu computador e envia ("PUSH") essa versão para o repositório central.

A pessoa B se anima com o projeto e também quer contribuir, criando o seu primeiro blog post. Para isso, B precisa ter acesso à versão criada por A, que já está no repositório central no momento. B precisa fazer um "PULL", que nada mais é que fazer uma cópia da última versão do projeto que está no repositório central para a sua máquina local.

Agora, B tem acesso, em seu computador, ao projeto em sua versão mais atual. B escreve seu primeiro blog post e precisa enviar as mudanças de volta para o repositório central, para que A também possa ver o seu belo trabalho. B faz um "PUSH" do seu código, ou seja, envia uma cópia da sua versão para o repositório central

Tudo pronto! Temos no repositório central a versão mais recente do blog, a qual contém o post de B. A versão inicial de A também está lá, guardada caso alguém precise consultá-la para comparar diferenças, ou até mesmo para reverter alguma alteração.

Mas, e se A também estiver empolgado e não conseguir esperar por B? Ao mesmo tempo que B, A começa a escrever seu próprio post. Quando A tenta enviar seu código para o repositório central, percebe que B já enviou antes a sua versão.

E para piorar, A e B modificaram o mesmo arquivo! E agora?

Bom, é aí que entra em jogo umas das principais funcionalidades de um sistema de controle de versão: o auxílio no Gerenciamento de Conflitos. O sistema lida com as mudanças feitas por diferentes colaboradores no mesmo arquivo, evitando conflitos e garantindo uma integração suave das alterações. Isso é feito por meio de um processo chamado 'mesclagem', que combina o trabalho de todos de forma harmoniosa e mantém a consistência do projeto.

Dessa forma, A consegue tranquilamente enviar suas modificações sem comprometer em nada as mudanças feitas por B.

1. Repositório Centralizado: É o ponto central onde todo o código-fonte e histórico de versões são armazenados. Todos os desenvolvedores trabalham diretamente com este repositório para obter versões atualizadas do código e para enviar suas alterações.

2. PUSH e PULL: Os desenvolvedores fazem um PULL - "puxam" para si uma cópia do código do repositório central para trabalhar localmente em suas máquinas. Após fazerem suas alterações, eles dão PUSH e mandam suas modificações de volta para o repositório central.

3. Auxílio no Gerenciamento de Conflitos: Os sistemas centralizados gerenciam as mudanças concorrentes feitas por múltiplos desenvolvedores. Se dois desenvolvedores tentarem modificar o mesmo arquivo ao mesmo tempo, o sistema de controle de versão pode detectar e gerenciar essas conflitos.

4. Histórico de Versões: Um aspecto fundamental dos sistemas de controle de versão é a capacidade de acompanhar o histórico de alterações em um arquivo ao longo do tempo. Isso permite que os desenvolvedores voltem a versões anteriores do código, se necessário.

Exemplos de sistemas centralizados de controle de versão incluem o Subversion (SVN) e o Microsoft Team Foundation Version Control (TFVC). Embora os sistemas centralizados tenham sido amplamente utilizados no passado, muitas equipes estão migrando para sistemas de controle de versão distribuídos, como o Git, devido à sua flexibilidade, desempenho e recursos avançados que iremos começar a desvendar aos poucos daqui para frente.

Se os códigos antes foram isolados, agora é hora de juntar! O merge permite integrar as alterações feitas em uma branch de desenvolvimento de volta à branch principal (master ou main). Isso garante que as novas funcionalidades, correções ou melhorias feitas em branches secundárias estejam disponíveis na branch principal do projeto.

Mas as branches não param por aí, pois a maior função delas é serem linhas independentes de desenvolvimento em um repositório, assim podem conter versões paralelas do código sem afetar a branch principal (main). Além disso, as branches ajudam a organizar e gerenciar o fluxo de trabalho de uma equipe de desenvolvimento. Aqui estão algumas das funções mais comuns quando o assunto é branch:

• Desenvolvimento Paralelo: As branches permitem que diferentes desenvolvedores trabalhem em diferentes funcionalidades ou correções simultaneamente, sem interferir no trabalho um do outro. Cada desenvolvedor pode ter sua própria branch para implementar e testar suas alterações.

• Isolamento de Funcionalidades ou Correções: Cada branch representa uma unidade de trabalho isolada. Isso significa que as mudanças feitas em uma branch não afetam diretamente o código em outras branches até que essas mudanças sejam mescladas de volta à branch principal.

• Testes e Experimentações: As branches também podem ser usadas para testar novas funcionalidades ou experimentações sem comprometer o código da branch principal. Se uma experimentação não der certo, ela pode ser descartada sem afetar o código principal.

• Gerenciamento de Versões: As branches também podem ser usadas para gerenciar diferentes versões de um projeto. Por exemplo, uma branch pode ser usada para manter a versão atual do software enquanto outra branch é usada para desenvolver uma versão futura.

Antes de começar a usar o Git, você precisará instalá-lo no seu computador. A instalação varia de acordo com o sistema operacional que você está usando. Abaixo, você encontrará instruções para os três sistemas operacionais mais comuns. Siga apenas as instruções que correspondem ao seu caso:

1. 2.4.1 Instalando no Linux

2. 2.4.2 Instalando no macOS

3. 2.4.3 Instalando no Windows

Um commit é uma "foto" do estado atual do repositório. Ele registra quais mudanças foram feitas, por quem e quando. Sendo uma parte fundamental do fluxo de trabalho do Git, permite o registro, acompanhamento e reversão de alterações no código-fonte de um projeto. Os commits são a base para o versionamento de código e colaboração eficaz entre desenvolvedores.

Repositório

É a maior unidade de armazenamento, um local de que contém todos os seus códigos, arquivos e o histórico da revisão de cada arquivo - como se fosse uma grande pasta com todos esses arquivos e metadados. Ele pode ser conhecido também como repo, e ser local (no seu computador) ou remoto (em um servidor, como o GitHub).

Seu uso pode ser individual ou compartilhado com vários outros colaboradores, além de ter a possibilidade de ser privado (empresas, projetos pessoais...) ou público (uma das principais características de qualquer projeto que seja Open Source). Mas não se engane: mesmo quando a visualização do código é aberta ao público, para acessar o repositório principal você precisa ter uma permissão para poder fazer alterações nele, mas falaremos disso mais à frente!

Você pode instalar o Git no Linux de maneira simples usando o Terminal. Basta usar a ferramenta de gerenciamento de pacotes da sua distribuição.

1. Verificar o Git

Procure por um aplicativo de prompt de comando chamado "Terminal".

Depois de abrir seu aplicativo de terminal, digite:

git version

A saída irá dizer qual versão do Git está instalada, ou irá alertar que o git é um comando desconhecido. Se for um comando desconhecido, continue lendo para descobrir como instalar o Git.

Como você pode perceber: a minha versão está um pouco desatualizada, mas não há problemas quanto a isso: o interessante é se preocupar sempre no primeiro número da versão, onde entram as maiores mudanças - chamadas de "Majors". Então V 2.34.1 não irá causar um problema tão grande quanto se no meu computador eu estivesse com a V 1.1.0!

Feita a verificação, se o Git ainda não está instalado na sua máquina você precisará instalá-lo. você precisa seguir as instruções nos próximos passos. Caso contrário, pode pular direto para a próxima seção 2.5 Interagindo com o Git.

2. Identificar a Distribuição Linux

Se você não sabe qual distribuição do Linux está usando, siga estes passos:

a. lsb_release

Digite o comando: No terminal, digite o seguinte comando e pressione Enter:

lsb_release -a

b. Interprete o Output

O comando lsb_release -a fornecerá informações sobre a distribuição. Veja um exemplo de output:

Distributor ID: Ubuntu
Description:    Ubuntu 20.04.3 LTS
Release:        20.04
Codename:       focal

Distribuições Comuns:

• Ubuntu: O campo Distributor ID mostrará "Ubuntu".

• Debian: O campo Distributor ID mostrará "Debian".

• Fedora: O campo Distributor ID mostrará "Fedora".

• Arch Linux: Pode não ter lsb_release instalado por padrão. Caso não tenha, siga as intruções do próximo passo (c).

c. Alternativa para Arch Linux

Se você estiver usando Arch Linux ou uma distribuição que não tenha lsb_release instalado por padrão, use este comando:

cat /etc/os-release

O output será algo assim:

NAME="Arch Linux"
PRETTY_NAME="Arch Linux"
ID=arch

3. Instalar o Git

Depois de identificar a sua distribuição, use o comando apropriado para instalar o Git:

Ubuntu ou Debian:

sudo apt update
sudo apt install git

Fedora:

Até o Fedora 21:

yum install git

A partir do Fedora 22:

dnf install git

Arch Linux:

sudo pacman -S git

4. Verificar a Instalação

Para verificar se o Git foi instalado corretamente, digite:

git --version

Isso deve exibir a versão do Git instalada, como por exemplo:

git version 2.36.1

Pronto! O Git está instalado e pronto para uso no seu sistema Linux.

1. Verificar o Git

Abra o Terminal, você pode encontrá-lo em Finder > Aplicativos > Utilitários > Terminal

Depois de abrir seu aplicativo de terminal, digite:

A saída irá dizer qual versão do Git está instalada, ou irá alertar que o git é um comando desconhecido. Se for um comando desconhecido, continue lendo para descobrir como instalar o Git.

Como você pode perceber: a minha versão está um pouco desatualizada, mas não há problemas quanto a isso: o interessante é se preocupar sempre no primeiro número da versão, onde entram as maiores mudanças - chamadas de "Majors". Então V 2.34.1 não irá causar um problema tão grande quanto se no meu computador eu estivesse com a V 1.1.0!

Execute o seguinte comando no terminal:

Siga as instruções no Terminal para concluir a instalação.

3. Instalar o Git com Homebrew:

Ainda no Terminal, execute o seguinte comando:

O Homebrew irá baixar e instalar a versão mais recente do Git para você.

4. Verificar a Instalação:

Após a instalação, verifique se o Git foi instalado corretamente executando:

O Terminal deve exibir a versão do Git instalada, como por exemplo:

git

O comando git é o ponto de entrada para todas as operações do Git. Ele é utilizado para invocar quaisquer outros comandos disponíveis no Git. Para utilizá-lo, basta digitar no terminal de comando git seguido pelo nome do comando que deseja executar e quaisquer argumentos necessários.

A estrutura básica para utilizar o comando git é a seguinte:

git comando [opções] [argumentos]

• git: A palavra-chave que inicia todos os comandos do Git.

• comando: A ação específica que você deseja executar. Por exemplo, para inicializar um novo repositório Git, você digita gitinit. Isso cria um novo repositório Git vazio.

• [opções]: São como ajustes extras que você pode usar com um comando. Por exemplo, quando você quer adicionar todas as mudanças feitas nos arquivos ao índice do Git, você usa o comando git add com a opção all: gitadd--all. Isso significa que você está dizendo ao Git para adicionar todas as mudanças, não importa quais arquivos foram modificados.

• [argumentos]: São as entradas sobre as quais você quer que o comando aja. Por exemplo, se você quer adicionar um arquivo específico para o próximo commit, você diz ao Git qual arquivo usar como um argumento. Então, o Git sabe exatamente com o que você está lidando: gitaddarquivo.txt

A partir de agora, vamos adotar a seguinte convenção de cores para facilitar a identificação:

• roxo para identificar git

• laranja para identificar o comando

• azul para identificar [opções]

• verda para identificar [argumentos]

Os colchetes [ ] indicam que tanto opções quanto argumentos são opcionais, ou seja, podem haver casos em que nem um nem outro são necessários. Um exemplo é o git init, que veremos logo em seguida.

Em resumo, toda interação com o Git é feita através do comando git. Ele é o seu meio de comunicação com o Git e permite que você execute uma ampla variedade de tarefas de controle de versão em seu projeto.

IMAGEM

1. Verificar o Git

Depois de abrir seu aplicativo de terminal, digite:

git version

A saída irá dizer qual versão do Git está instalada, ou irá alertar que o git é um comando desconhecido. Se for um comando desconhecido, continue lendo para descobrir como instalar o Git.

Como você pode perceber: a minha versão está um pouco desatualizada, mas não há problemas quanto a isso: o interessante é se preocupar sempre no primeiro número da versão, onde entram as maiores mudanças - chamadas de "Majors". Então V 2.34.1 não irá causar um problema tão grande quanto se no meu computador eu estivesse com a V 1.1.0!

Feita a verificação, se o Git ainda não está instalado na sua máquina você precisará instalá-lo. você precisa seguir as instruções nos próximos passos. Caso contrário, pode pular direto para a próxima seção 2.5 Interagindo com o Git.

2. Baixar o Instalador do Git:

• Clique no botão de download para Windows.

• O download deve começar automaticamente. Aguarde até que o arquivo seja baixado completamente.

3. Executar o Instalador:

• Após o download, abra o arquivo executável (.exe) do instalador do Git.

• Siga as instruções do assistente de instalação. Você pode deixar as opções padrão ou personalizar de acordo com suas preferências.

4. Configurar o Instalador:

• Durante a instalação, você será solicitado a fazer algumas escolhas, como a localização de instalação e a seleção de componentes.

• Para a maioria dos usuários, as opções padrão funcionam bem. Basta seguir as instruções na tela.

5. Concluir a Instalação:

• Após concluir a instalação, você pode fechar o instalador.

• O Git agora está instalado no seu sistema Windows.

6. Verificar a Instalação:

Após a instalação, verifique se o Git foi instalado corretamente executando:

git --version

O Terminal deve exibir a versão do Git instalada, como por exemplo:

git version 2.36.1

git init

O comando git init cria um novo repositório Git. Ele pode ser utilizado principalmente para dois fins:

• Para converter um projeto existente, não versionado, em um repositório Git ou;

• Para inicializar um novo repositório vazio.

Imagens 1 e 2 init

A maioria dos outros comandos do Git não está disponível fora de um repositório inicializado, então este é geralmente o primeiro comando que você executa em um novo projeto.

O quê o comando git init faz por debaixo dos panos é criar uma pasta oculta chamada .git dentro da pasta de trabalho atual.

Essa pasta é onde o Git armazenará todos os dados sobre as versões dos arquivos, as alterações feitas e outras informações importantes para o controle de versão.

imagem: pasta .git apontando para várias coisas que ela contém

Se você excluir essa pasta, o Git perderá a capacidade de acessar e gerenciar todas as informações essenciais do seu repositório. Portanto, é crucial que essa pasta sempre esteja presente para garantir o funcionamento adequado do Git.

No exemplo acima, primeiro usamos o comando ls, que lista os arquivos e diretórios no diretório atual. Como você pode ver, inicialmente não há nada listado.

Depois, usamos o comando ls -a, que mostra todos os arquivos e diretórios, incluindo os ocultos (aqueles que começam com um ponto), e vemos apenas . e ...

Então, executamos o comando git init, que inicializa um repositório Git vazio e cria o diretório oculto .git.

Quando usamos novamente o comando ls, não vemos nada de diferente, pois .git é oculto. Mas ao usar ls -a novamente, a pasta .git aparece!

Estrutura

O formato base do comando git init é:

git init [opções] [diretório]

em que diretório (opcional) se refere ao caminho do diretório onde você quer inicializar o repositório. Se você omitir o diretório, o Git inicializará um repositório no diretório atual.

O Git é essencialmente um sistema de controle de versão. No entanto, não oferece uma maneira direta para que os usuários interagirem com ele. É necessária uma ferramenta adicional, chamada de cliente (Git Client), que provenha essa ponte entre o usuário e o Git em si.

Imagem: git <--> git client <--> usuário

Existem várias clientes que facilitam a comunicação entre o Git e o usuário. Alguns deles fornecem uma interface de linha de comando (CLI), enquanto outros oferecem uma interface gráfica do usuário (GUI):

Interface de Linha de Comando (Command Line Interface - CLI): Neste formato, os usuários interagem com o Git digitando comandos diretamente em um terminal ou prompt de comando. Aqui, os comandos são textuais e exigem que o usuário escreva para executar várias tarefas.

Interface Gráfica do Usuário (Graphical User Interface - GUI): Esta abordagem é mais visual, permitindo que os usuários interajam com o Git clicando em botões, ícones e menus em um aplicativo gráfico. Aqui, as ações são realizadas de forma mais intuitiva, sem a necessidade de digitar comandos.

Imagem: capturas de telas de diferentes clientes GUI com seus repectivos nomes/links

Git CLI

1. Por ser a solução oficial, ela será sempre a mais atual e a única que fornecerá a capacidade de executar todos os comandos do Git. A maioria dos clientes com interfaces gráficas, por exemple, implementam apenas um subconjunto das funcionalidades do Git com o intuito de simplificar a utilização.

2. Se uma pessoa souber como utilizar a Git CLI, provavelmente também conseguirá facilmente entender como utilizar outros cliente com interfaces gráficas, enquanto o contrário nem sempre é verdadeiro.

3. Embora a escolha do cliente seja uma questão de preferência pessoal, optar pela CLI oficial também significa que todos os usuários já terão as ferramentas de linha de comando prontas para uso, sem a necessidade de qualquer outra instalação ou configuração.

Caso, ainda sim, opte-se por utilizar um cliente com interface gráfica, aqui se encontram várias opções disponíveis:

Neste capítulo, vamos explorar como usar o Git localmente, sem a necessidade de uma conexão com a internet. Ao aprender a usar o Git apenas no seu ambiente local, você entenderá os conceitos fundamentais que são essenciais para trabalhar com o código antes de interagir com repositórios remotos, como o GitHub.

Git: Trabalhando sem Internet

Uma das grandes vantagens do Git é que ele pode funcionar sem estar conectado à internet. Isso acontece porque o Git é um sistema de controle de versão distribuído (DVCS), o que significa que cada repositório é uma cópia completa de todo o histórico de alterações do projeto. Com isso, você pode realizar operações como commits, branches e merges localmente, sem depender de servidores externos.

Por Que Usar Git Localmente?

Existem várias razões pelas quais você pode querer trabalhar com Git apenas no seu computador, sem interagir com um repositório remoto:

• Trabalho Offline: Em muitas situações, como em viagens ou quando há problemas de conexão, o Git permite que você continue trabalhando sem depender de servidores externos.

• Desenvolvimento Inicial: Quando você começa um projeto, talvez não precise de colaboração imediata. Você pode desenvolver localmente e, quando o projeto estiver pronto, decidir enviá-lo para um repositório remoto.

• Testar Funcionalidades: Trabalhar localmente te permite testar e experimentar novas funcionalidades sem impactar outras versões ou usuários até que esteja pronto para compartilhar com a equipe.

Git Pode Funcionar Completamente Sem o GitHub

O Git é independente do GitHub, ou qualquer outro serviço remoto. Mesmo sem uma conta no GitHub, GitLab ou Bitbucket, você pode usar o Git para versionar o código e controlar o histórico de alterações do seu projeto localmente. O GitHub apenas fornece uma plataforma para hospedar repositórios remotos, mas o Git, em si, pode ser totalmente operado no seu computador.

A Importância de Dominar o Git Local Antes do Git Remoto

Para trabalhar remotamente, é essencial que você tenha um bom domínio das operações locais do Git. Quando você interage com um repositório remoto, está basicamente sincronizando alterações feitas localmente com um servidor, e isso exige um entendimento claro de como funcionam os commits, branches, merges, e como você organiza o código no seu ambiente local.

Além disso, muitos problemas ao trabalhar com repositórios remotos surgem justamente da falta de compreensão das operações locais. Você precisa ser capaz de resolver conflitos, revisar o histórico de alterações e fazer commits corretamente antes de enviar seu código para um repositório remoto. Portanto, dominar as operações locais do Git é o primeiro passo para aproveitar ao máximo o Git, seja de forma local ou remota.

Neste capítulo, vamos dar os primeiros passos para entender como controlar o seu código no seu ambiente local, preparando você para avançar para o uso de repositórios remotos no futuro.

O comando git add é usado para preparar mudanças feitas nos arquivos do seu projeto para serem incluídas no próximo commit.

Como Funciona

1. Modificar arquivos

   Primeiro, você faz alterações nos arquivos do seu projeto. Essas mudanças podem incluir a edição de arquivos existentes, a adição de novos arquivos ou a exclusão de arquivos.

2. Adicionar à Área de Preparação Quando você está satisfeito com as alterações e deseja incluí-las no próximo commit, você usa o comando git add para mover essas mudanças para a área de preparação (staging area). Exemplo: Se você editou um arquivo chamado index.html, você usaria git add index.html para preparar essas alterações.

Estrutura

O formato base do comando git add é:

git add arquivo

Exemplos de uso

• Adicionar um arquivo específico:

  • git add index.html

  • Prepara as mudanças feitas em index.html para o próximo commit.

• Adicionar uma pasta específica:

  • git add images/

  • Prepara todas as mudanças feitas dentro da pasta images/ para o próximo commit.

• Adicionar vários arquivos de uma vez:

  • git add index.html style.css script.js

  • Prepara as mudanças feitas em index.html, style.css e script.js para o próximo commit.

• Adicionar todos os arquivos modificados

  • git add .

  • Prepara todas as mudanças feitas em todos os arquivos do diretório atual e seus subdiretórios para o próximo commit.

O comando git add não altera o repositório de maneira significativa; ele apenas move as mudanças para a área de preparação (staging area). Isso informa ao Git que você deseja incluir essas alterações no próximo commit. No entanto, as mudanças não são realmente registradas no repositório até que você execute o comando git commit.

Portanto, git add é uma etapa intermediária que permite que você revise e selecione as mudanças antes de salvá-las permanentemente no repositório.

Como Funciona

O comando git commit é utilizado para salvar as alterações feitas no repositório. Pense no git commit como um comando para salvar, mas ele é especial porque pode salvar várias alterações de uma vez, não apenas uma.

O commit funciona como uma câmera que tira uma "foto" (ou "snapshot") do seu projeto naquele exato momento. Essa "foto" captura todas as mudanças que foram preparadas (ou "staged") usando o comando git add, além de tudo que já estava presente no repositório anteriormente. Esses "fotos" podem ser consideradas versões "seguras" do projeto — o Git nunca as alterará, a menos que você solicite explicitamente.

Antes da execução do git commit, o comando git add é utilizado para promover ou "preparar" as alterações no projeto que serão armazenadas em um commit. Esses dois comandos, git commit e git add, estão entre os mais frequentemente utilizados.

As alterações são locais

Quando você faz um commit, as mudanças são salvas localmente no seu computador. Isso significa que elas ainda não estão disponíveis para outras pessoas. As mudanças ainda não estão presentes no repositório central.

imagem:

Vantagens de alterações locais:

1. Independência: Você pode trabalhar de forma independente e fazer quantas mudanças precisar sem afetar o trabalho de outras pessoas.

2. Segurança: Você tem controle total sobre quando e como compartilhar suas alterações, permitindo que você refine e teste seu trabalho antes de disponibilizá-lo.

Snapshots, não diferenças

Uma das características mais importantes do Git é que ele salva "snapshots" (fotos) do projeto, não apenas as diferenças entre as versões. Isso significa que cada commit é uma cópia completa do estado do projeto naquele momento.

Benefícios dos snapshots:

1. Segurança: Cada commit é uma versão completa e segura do projeto. Se algo der errado, você pode sempre voltar a um estado anterior.

2. Histórico Claro: Ter snapshots completos facilita entender o estado do projeto em qualquer ponto no tempo.

3. Restauração Simples: Se precisar voltar a um estado anterior, você tem uma imagem completa do projeto, sem precisar recompor todas as mudanças uma por uma.

Estrutura

O formato base do comando git commit é:

git commit [opções]

Exemplos de uso

• Realizar o commit do snapshot preparado

  • git commit

  • Isso abrirá um editor de texto solicitando uma mensagem de commit. Após inserir uma mensagem, salve o arquivo e feche o editor para criar o commit real.

• Criar imediatamente um commit com uma mensagem de commit fornecida

  • git commit -m "mensagem do commit"

  • Por padrão, git commit abrirá o editor de texto localmente configurado e solicitará a inserção de uma mensagem de commit. Passar a opção -m irá dispensar o prompt do editor de texto em favor de uma mensagem inline.

git config

O comando git config é usado para configurar o Git no seu computador. Neste contexto, entenda configurar como customizar ou personalizar o Git de acordo com suas preferências.

Existem duas maneiras de configurar o Git no seu computador:

1. Configuração Global: Essas configurações se aplicam a todos os seus projetos Git no sistema. Elas são armazenadas no arquivo .gitconfig no diretório do usuário. No Windows, você pode encontrá-lo em C:\Users\maria, no macOS em /Users/maria, e no Linux em /home/maria, onde "maria" é o nome do usuário neste exemplo. Configurações globais são úteis para definir preferências pessoais que se aplicam a todos os seus projetos.

2. Configuração Local: Essas configurações são específicas para um projeto Git individual. Elas são armazenadas no arquivo .git/config dentro do diretório do projeto. Configurações locais sobrescrevem as configurações globais quando ambas são definidas, permitindo personalização por projeto.

Você pode escolher entre aplicar uma configuração globalmente para todos os seus projetos ou/e localmente para um projeto específico, oferecendo flexibilidade na personalização das configurações do Git de acordo com suas necessidades.

imagem: configs globais vs locais. Onde o arquivo fica localizado e a que se aplica

Estrutura

O formato base do comando git config é:

git config [opções] chave valor

Em que:

• [opções] (opcional): define o escopo do comando ou fornecem outros modificadores. O escopo pode ser, por exemplo,--global para aplicar a configuração a nível global ou --local para aplicar a configuração apenas ao repositório atual.

• chave: se refere ao nome da configuração que você deseja definir ou modificar. Exemplos: user.name, user.email, core.editor.

• valor: se refere ao valor que você deseja atribuir à chave. Exemplos: "Seu Nome", "seu.email@exemplo.com", "nome-do-editor".

Exemplos de Uso

Exemplos de Configurações

Essas são algumas das propriedades que podem ser configuradas:

1. user.name: Define o nome de usuário associado aos commits. É como você se identifica nos commits, então outros sabem quem fez as alterações. Exemplo definindo nome do usuário global como maria: git config --global user.name "Maria"

2. user.email: Define o email associado aos commits. É o seu endereço de email associado aos commits para que outros possam contatá-lo se necessário. Exemplo definindo email do usuário global como maria@exemplo.com: git config --global user.email "maria@exemplo.com"

3. core.editor: Define o editor de texto usado para mensagens de commit. É o programa que você usa para escrever mensagens de commit. Exemplo definindo o editor de texto padrão global como o Visual Studio Code: git config --global core.editor "code --wait"

4. color.ui: Ativa ou desativa a coloração na saída do Git. Deixa as mensagens do Git mais coloridas para que você possa identificar informações mais facilmente. Exemplo ativando globalmente a coloração na saída do Git: git config --global color.ui true

5. alias.*: Define atalhos personalizados para comandos Git. São atalhos personalizados para que você possa digitar menos ao usar certos comandos Git. Exemplo criando um atalho global "ci" para o comando 'commit': git config --global alias.ci commit

6. init.defaultBranch: Define o nome padrão do branch inicial. Define o nome padrão do branch inicial quando você cria um novo repositório. Exemplo definindo o nome padrão do branch inicial como 'dev' para um projeto específico: git config --local init.defaultBranch dev

Exemplo Configurando Dois Emails

Configurar diferentes e-mails no Git pode ser super útil, especialmente quando você tem uma conta pessoal e outra da empresa. Vamos ver como essa configuração global e local pode fazer a diferença no seu dia a dia!

Imagine que você trabalha em vários projetos, tanto pessoais quanto profissionais. Usar a configuração global do Git permite que você configure um e-mail padrão que será usado em todos os repositórios. Isso é ótimo para simplificar as coisas, mas e se você quiser separar suas identidades? É aqui que a configuração local entra em cena, e é super fácil de fazer!

Vamos começar com a configuração global. Digamos que você queira usar seu e-mail pessoal como padrão. Basta abrir o terminal e digitar:

git config --global user.email "seu-email@pessoal.com"

Agora, todos os seus commits em qualquer repositório vão usar este e-mail. Mas o que acontece quando você está trabalhando em um projeto da empresa e precisa usar seu e-mail corporativo? Sem problemas! Você pode configurar um e-mail específico apenas para esse projeto.

Aqui está como fazer isso. Vá para o diretório do seu projeto da empresa:

cd ~/workspace/projeto-da-empresa
git config user.email "seu-email@empresa.com"

Pronto! Agora, todos os commits feitos nesse repositório usarão seu e-mail corporativo.

Por exemplo este commit será associado ao e-mail "seu-email@empresa.com":

cd ~/workspace/projeto-da-empresa
git commit -m "Implementação da nova funcionalidade"

E este ao e-mail "seu-email@pessoal.com":

cd ~/workspace/projeto-pessoal
git commit -m "Adicionado novo recurso ao blog pessoal"

Assim, você mantém suas identidades digitais separadas e claras, tanto no ambiente pessoal quanto no profissional. Configurar esses e-mails é fácil e faz toda a diferença na organização do seu trabalho.

O comando git log serve para mostrar o histórico de commits de um repositório. Ele exibe uma lista de commits no histórico atual do branch, incluindo detalhes como o autor, a data, a mensagem do commit e o identificador único (hash) do commit. É comumente usado para navegar pelo histórico de commits do projeto e entender as mudanças ao longo do tempo.

Estrutura

O formato base do comando git log é:

git log [opções]

Exemplos de uso

• Exibir o histórico completo de commits:

  • git log

  • Lista todos os commits do repositório com detalhes como autor, data e mensagem do commit.

git log
▶ commit a1b2c3d4e5f67890123456789abcdef12345678 (HEAD -> main)
Author: Nome do Autor <email@exemplo.com>
Date:   Mon Feb 19 10:00:00 2024 -0300

    Mensagem do segundo commit, o mais recente

commit f6e5d4c3b2a190876543210fedcba9876543210
Author: Outro Autor <outro@exemplo.com>
Date:   Sun Feb 18 15:30:00 2024 -0300

    Mensagem do primeiro commit

• Exibir o histórico de commits de forma resumida::

  • git log --oneline

  • Mostra uma versão compacta do histórico, exibindo apenas o hash abreviado e a mensagem do commit.

git log --oneline
▶ a1b2c3d Mensagem do segundo commit, o mais recente
f6e5d4c Mensagem do primeiro commit

Os comandos: git add, git status e git commit são usados em conjunto para salvar uma foto do estado atual de um projeto Git. Os comandos git status e git log são utilizados para entender a evolução do repositório, mostrando o estado atual e o histórico de commits, respectivamente.

Conceitos

Estados de um arquivo

• tracked (rastreado): um arquivo que já foi preparado ou confirmado;

  • Estados de um arquivo tracked:

    • Committed: Tracked e sem mudanças - salvo.

    • Modified: Tracked e com mudanças.

    • Staged: Tracked, com mudanças prontas para commit.

• untracked (não rastreado): um arquivo que não foi preparado nem confirmado.

Fazendo Alterações

• git add é usado para selecionar quais mudanças serão incluídas no próximo commit. Ele prepara as alterações para serem registradas no histórico do projeto.

• git commit após utilizar o git add para preparar as mudanças, o git commit salva essas alterações no repositório como uma "foto" do estado atual do projeto. Isso permite que você mantenha um registro claro do progresso do seu trabalho.

• As alterações são salvas localmente, permitindo que você trabalhe de forma independente.

• Git usa "snapshots" completos em vez de apenas diferenças, oferecendo mais segurança e um histórico claro do projeto.

Visualização e Inspeção

São operações que podem ser executadas a qualquer momento e que auxiliam a entender o estado atual e o histórico do seu repositório

• git status exibe o estado atual do diretório de trabalho e da área de stage, mostrando quais arquivos foram modificados, quais estão prontos para serem confirmados (staged) e quais não estão sendo rastreados pelo Git.

• git log mostra o histórico de commits do repositório, exibindo detalhes como o autor, a data, a mensagem do commit e o identificador único (hash) do commit. É útil para navegar pelo histórico de commits do projeto e entender as mudanças ao longo do tempo.

• git diff exibe as diferenças entre as alterações feitas nos arquivos em relação ao último commit. É útil para visualizar as mudanças antes de prepará-las para um commit

Em seguida, veremos um exemplo prático de como esses comandos funcionam.

Passo a Passo

1. Inicializar um Repositório Vazio

Crie uma pasta no seu computador chamada de meu-repo .

mkdir meu-repo

Confira que a pasta foi criada com sucesso. A pasta meu-repo deve estar listada no resultado do comando.

🔹 Linux/macOS

ls -la

🔹 Windows (CMD/PowerShell)

dir /a

Entre na pasta recém criada.

cd meu-repo

Inicialize essa pasta como um repositório com o comando git init.

git init
▶ Initialized empty Git repository in /.../meu-repo/.git/

Confira que a pasta oculta .git foi criada. A pasta .git deve estar listada no resultado do comando.

🔹 Linux/macOS

ls -la

🔹 Windows (CMD/PowerShell)

dir /a

2. Verificar o Status do Repositório

Execute o comando git status para verificar o estado atual do diretório de trabalho e da área de stage.

git status
▶ On branch main

No commits yet

nothing to commit (create/copy files and use "git add" to track)

O resultado deve mostrar que não consta nada para ser commitado, nada na área de stage e não há nada que não está sendo rastreado.

3. Verificar o Histórico de Commits

Execute o comando git log para verificar o histórico de commits do repositório

git log
▶ fatal: your current branch 'main' does not have any commits yet

Um erro será mostrado, uma vez que nenhum commit foi realizado ainda neste repositório.

4. Criar um Arquivo

Crie um arquivo chamada arquivo.txt contendo a palavra "cumbuca". Você pode fazer isso via comando de terminal ou via um editor de texto. Este é o comando para criar via terminal.

echo cumbuca > arquivo.txt

Liste os arquivos na sua pasta novamente. O arquivo arquivo.txt deve estar listada no resultado do comando.

🔹 Linux/macOS

ls -la

🔹 Windows (CMD/PowerShell)

dir /a

Verifique o conteúdo do arquivo. O resultado deve ser cumbuca.

🔹 Linux/macOS

cat arquivo.txt
▶ cumbuca

🔹 Windows (CMD/PowerShell)

type arquivo.txt
▶ cumbuca

5. Verificar o Status do Repositório

Execute o comando git status para verificar o estado atual do diretório de trabalho e da área de stage.

git status
▶ On branch main

No commits yet

Untracked files:
  (use "git add <file>..." to include in what will be committed)
	arquivo.txt

nothing added to commit but untracked files present (use "git add" to track)

Perceba que o arquivo arquivo.txt agora deverá estar sinalizado como "untracked" (não rastreado).

6. Verificar Diferenças para o Último Commit

Execute o comando git diff para ver as diferenças entre o estado atual e o último commit.

git diff

Nada será mostrado, pois o arquivo.txt é um arquivo novo e ainda não foi rastreado pelo Git. Além de não existir commits anteriores.

7. Preparar o Arquivo para Commit

Execute o comando git add arquivo.txt para adicionar o arquivo à área de stage.

git add arquivo.txt

8. Verificar o Status do Repositório

Execute o comando git status para verificar o estado atual do diretório de trabalho e da área de stage.

git status
▶ On branch main

No commits yet

Changes to be committed:
  (use "git rm --cached <file>..." to unstage)
	new file:   arquivo.txt

O arquivo arquivo.txt deve constar na área de stage agora, pronto para ser commitado. O seu estado atual é "tracked" e "staged" (rastreado e em área de preparação).

9. Fazer o Commit

Use o comando git commit -m "Adicionando arquivo arquivo.txt" para salvar a sua alteração.

git commit -m "Adicionando arquivo arquivo.txt"
▶ [main (root-commit) fc34c35] Adicionando arquivo arquivo.txt
 1 file changed, 1 insertion(+)
 create mode 100644 arquivo.txt

10. Verificar o Status do Repositório

Execute o comando git status para verificar o estado atual do diretório de trabalho e da área de stage.

git status
▶ On branch main
nothing to commit, working tree clean

O arquivo arquivo.txt foi salvo no repositório, e o arquivo voltou ao estado "tracked" e "committed" (rastreado e confirmado).

11. Verificar o Histórico de Commits

Execute o comando git log para ver o histórico de commits do repositório.

commit fc34c35c38eb1b4ee19014b82a5572345165affc (HEAD -> main)
Author: Cumbuca Dev <cumbucadev@gmail.com>
Date:   Wed Jun 12 22:03:33 2024 +0200

    Adicionando arquivo arquivo.txt

Agora, o seu primeiro commit no repositório já está sendo listado.

12. Modificar um Arquivo

Adicione uma nova linha ao final do arquivo arquivo.txt contendo a frase "dev". Você pode fazer isso via comando de terminal ou via um editor de texto. Este é o comando para criar via terminal

echo dev >> arquivo.txt

Verifique o conteúdo do arquivo. O resultado deve ser um texto contendo cumbuca na primeira linha e dev na segunda.

🔹 Linux/macOS

cat arquivo.txt
▶ cumbuca
dev

🔹 Windows (CMD/PowerShell)

type arquivo.txt
▶ cumbuca
dev

13. Verificar o Status do Repositório

Execute o comando git status para verificar o estado atual do diretório de trabalho e da área de stage.

git status
▶ On branch main
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
	modified:   arquivo.txt

no changes added to commit (use "git add" and/or "git commit -a")

O arquivo arquivo.txt agora está "tracked" e "modified" (rastreado e modificado).

14. Verificar Diferenças para o Último Commit

Execute o comando git diff para verificar as diferenças entre o estado atual e o último commit.

git diff

diff --git a/arquivo.txt b/arquivo.txt
index 9bbb6ca..cf44cf3 100644
--- a/arquivo.txt
+++ b/arquivo.txt
@@ -1 +1,2 @@
 cumbuca
+dev

15. Preparar o Arquivo para Novo Commit

Execute o comando git add arquivo.txt para adicionar o arquivo novamente à área de stage.

git add arquivo.txt

16. Verificar o Status do Repositório

Execute o comando usa git status para verificar o estado atual do diretório de trabalho e da área de stage.

On branch main
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
	modified:   arquivo.txt

O arquivo arquivo.txt agora está "tracked" e "staged" (rastreado e em área de preparação) novamente.

17. Fazer Novo Commit

Execute o comando git commit -m "Adicionando mais uma linha ao arquivo.txt" para salvar a sua alteração.

git commit -m "Adicionando mais uma linha ao arquivo.txt"
▶ [main 8af53f0] Adicionando mais uma linha ao arquivo.txt
 1 file changed, 1 insertion(+)

18. Verificar o Status do Repositório

Execute o comando git status para verificar o estado atual do diretório de trabalho e da área de stage.

git status
▶ On branch main
nothing to commit, working tree clean

O arquivo arquivo.txt foi salvo no repositório, e o arquivo voltou ao estado "tracked" e "committed" (rastreado e confirmado).

19. Verificar o Histórico de Commits

Execute o comando git log para ver o histórico de commits do repositório. Você deve encontrar dois commits agora.

git log

commit 8af53f08777121067a34aa03269318c103493a79 (HEAD -> main)
Author: Camila Maia <cmaiacd@gmail.com>
Date:   Mon Feb 17 18:54:27 2025 -0300

    Adicionando mais uma linha ao arquivo.txt

commit fc34c35c38eb1b4ee19014b82a5572345165affc
Author: Camila Maia <cmaiacd@gmail.com>
Date:   Mon Feb 17 18:33:17 2025 -0300

    Adicionando arquivo arquivo.txt

Visão Geral dos Estados do Arquivo

O comando git switch é utilizado para alternar entre branches no Git de maneira intuitiva e eficiente, facilitando o fluxo de trabalho.

Estrutura

O formato base do comando git switch é:

git switch [opções] nome-do-branch

Exemplos de uso

• Alternar para um branch existente

  • git switch nova-feature

  • Muda para o branch nova-feature.

• Criar e alternar para um novo branch:

  • git switch -c nova-feature

  • Cria um novo branch chamado nova-feature e muda para ele automaticamente.

O comando git switch melhora a experiência ao alternar entre branches, tornando o fluxo de trabalho mais eficiente e reduzindo erros.

Como visto na seção 2.3.3 Branch, os branches (ou ramificações) são uma das principais funcionalidades do Git, permitindo que você trabalhe em diferentes versões de um projeto sem interferir no código principal. Elas são essenciais para desenvolvimento colaborativo, facilitando a criação de novas funcionalidades, correções de bugs e experimentações sem afetar a versão estável do código.

Nesta seção, você aprenderá como criar, mudar, mesclar e gerenciar branches de forma eficiente, garantindo um fluxo de trabalho organizado e produtivo.

Como Funciona

O comando git status serve para mostrar o estado atual dos arquivos de um projeto.

Ao executar o comando git status, serão listado os arquivos modificados, preparados e não rastreados.

Arquivos modificados

O comando irá mostrar quais arquivos foram modificados desde o último commit. Esses arquivos ainda não estão preparados (staged) para o próximo commit.

Exemplo: Se você editou index.html, o git status mostrará que index.html foi modificado (modified).

Arquivos preparados

O comando irá mostrar a lista dos arquivos que estão na área de preparação (staging area), prontos para serem incluídos no próximo commit.

Exemplo: Se você usou git add index.html, o git status mostrará que index.html está na área de preparação.

Arquivos não rastreados

O comando irá mostrar quais arquivos do diretório de trabalho não estão sendo rastreados pelo Git. Esses são arquivos que ainda não foram adicionados ao repositório.

Exemplo: Se você criou um novo arquivo chamado script.js e não usou git add nele, git status mostrará que script.js é um arquivo não rastreado.

Estrutura

O formato base do comando git status é:

git status [opções]

O quê significa "salvar" no Git?

Quando você trabalha com Git, a função "salvar" funciona de uma maneira um pouco diferente do que estamos acostumados em programas como editores de texto (como Microsoft Word, Google Docs...).

Normalmente, quando salvamos um documento em um editor de texto, estamos apenas atualizando o arquivo com as mudanças feitas. Esse processo é simples e direto: ou você está criando um arquivo novo (geralmente disponível no menu "Salvar Como") ou substituindo o arquivo existente com novas alterações (geralmente disponível no menu "Salvar").

No Git, o termo "salvar", em geral, é chamado de "commit". Fazer um commit é como salvar um conjunto de mudanças em seus arquivos e pastas. Não estamos apenas substituindo um arquivo, mas sim registrando todas as alterações feitas em vários arquivos de uma vez. É como tirar uma "foto" do estado atual de todo o projeto.

Então, sempre que você ouvir "commit" no Git, pense nisso como um "salvar" mais poderoso e abrangente, que acompanha um grupo de arquivos e suas alterações, em vez de apenas um único arquivo.

Rastrear um Arquivo

Os arquivos em sua pasta de trabalho podem estar sendo rastreados pelo Git ("tracked") ou não ("untracked"):

• Não rastreados (Untracked): São arquivos que não estão sendo monitorados pelo Git. Eles existem no diretório de trabalho, mas nunca foram adicionados ao repositório Git. Ou seja, o Git simplesmente não controla o versionamento destes arquivos.

• Rastreados (Tracked): São arquivos que o Git conhece e está rastreando. Isso inclui arquivos que foram adicionados ao repositório e que fazem parte do histórico de commits.

Ao criar um arquivo novo no seu diretório local, ele ainda não estará sendo rastreado pelo Git. Para isso, você precisa explicitamente adicioná-lo com o comando git add. A partir de então, o Git passará a controlar o versionamento do novo arquivo no projeto.

Estados de um Arquivo Rastreado

No Git, os arquivos podem estar em diferentes estados para gerenciar as mudanças de forma mais eficiente, uma vez que "salvar" no Git é mais complexo do que em um editor de texto tradicional. Os estados permitem que você escolha quais mudanças salvar (commit) e quais não. Por exemplo, se você está trabalhando em duas funcionalidades diferentes no mesmo projeto, você pode selecionar quais arquivos ou partes de arquivos deseja incluir no commit de cada funcionalidade.

Portanto, uma vez que o arquivo está sendo rastreado pelo Git, ele pode estar em um dos seguintes estados:

• Modificado (Modified): Quando você faz alterações em um arquivo no seu diretório de trabalho, ele está no estado modificado. Isso significa que você mudou o conteúdo do arquivo, mas ainda não informou ao Git que deseja salvar essas mudanças.

• Preparado (Staged): Depois de modificar um arquivo, você pode usar o comando git add para colocar essas mudanças na área de preparação (staging area ou index). Quando um arquivo está na staging area, ele está no estado preparado. Isso significa que você está dizendo ao Git que essas mudanças devem ser incluídas no próximo commit.

• Salvo / Confirmado (Committed): Quando você está satisfeito com as mudanças que preparou, você usa o comando git commit para salvar essas mudanças no repositório do Git. Um commit é como tirar uma "foto" do estado atual do seu projeto e armazená-la permanentemente no histórico do Git. Quando um arquivo está confirmado, suas mudanças estão salvas de forma segura no repositório.

A preparação seletiva oferece flexibilidade para testar e revisar antes de confirmar as mudanças. Você pode fazer várias alterações, mas só preparar aquelas que estão prontas para serem confirmadas. Isso ajuda a manter um histórico claro e organizado, pois cada commit representa uma "foto" do estado dos arquivos, facilitando a rastreabilidade e a colaboração.

Resumindo:

• Modificado: Arquivo foi alterado, mas as mudanças não foram preparadas.

• Preparado (Staged): Mudanças estão na área de preparação e prontas para serem confirmadas.

• Confirmado / Salvo (Committed): Mudanças foram salvas no repositório do Git.

Possíveis Estados de um Arquivo no Git

O git merge pega as alterações feitas em um branch específico e as aplica no branch em que você está atualmente. Isso acontece de forma automática, quando não há conflitos, ou pode exigir uma intervenção manual, caso ocorram conflitos entre as mudanças feitas.

Quando você realiza um merge, o Git tenta combinar as alterações automaticamente. Se houver diferenças que não podem ser resolvidas automaticamente (conflitos), o Git pedirá sua ajuda para escolher qual versão manter.

Estrutura

Esta é a estrutura base do comando git merge que iremos utilizar neste momento

git merge nome-do-branch

Em que:

• git merge: Este é o comando principal que invoca a ferramenta de mesclagem do Git.

• nome-do-branch: Especifica o branch que você deseja mesclar com o branch atual. Esse pode ser um branch local ou remoto.

Esse comando deve ser executado no branch de destino, ou seja, o branch onde você quer que as alterações sejam aplicadas.

Exemplos de Uso

• Integrar um branch no branch principal

  • git switch main git merge nova-feature

  • O primeiro comando garantirá que o branch atual é o main. No segundo comando, se o merge ocorrer sem conflitos, o Git criará automaticamente um commit de merge para registrar a fusão dos branches. Isso irá aplicar as alterações do nova-feature no main.

O merge funciona perfeitamente quando não há conflitos. No entanto, quando eles ocorrem, é necessário resolvê-los manualmente com atenção. Na próxima seção, vamos aprender como lidar com os conflitos que podem surgir durante o processo de merge.

Conflito

Um conflito no Git ocorre quando ele não consegue mesclar automaticamente as alterações feitas em dois branches diferentes. Isso acontece quando ambos modificam a mesma parte do código e o Git não sabe qual alteração deve ser mantida.

Conflitos são comuns quando várias pessoas colaboram em um projeto. Por exemplo:

• Duas pessoas editam as mesmas linhas de um arquivo.

• Alguém exclui um arquivo enquanto outra pessoa faz alterações nele.

• Arquivos são movidos ou renomeados em diferentes branches.

O Git precisa da sua intervenção para resolver essas situações e decidir qual versão do código será mantida.

Situações em que um conflito pode ocorrer:

• Alterações no mesmo trecho do código: Quando o mesmo trecho de um arquivo é alterado em ambos os branches.

• Alterações conflitantes: Quando um arquivo foi removido em um branch e modificado no outro.

• Mudanças na estrutura de diretórios: Quando há conflitos na estrutura de diretórios, como arquivos movidos ou renomeados em ambos os branches.

Situações em que o Git consegue resolver sozinho:

• Alterações em arquivos diferentes: Quando as mudanças são feitas em arquivos diferentes, o Git pode mesclar automaticamente.

• Alterações em partes diferentes do mesmo arquivo: Quando as alterações acontecem em áreas separadas de um arquivo, o Git pode combinar automaticamente.

• Arquivos adicionados em apenas um branch: Se um arquivo foi adicionado em um branch, mas não existe no outro, o Git pode integrá-lo automaticamente.

Por que o Git não Consegue Resolver o Conflito Sozinho?

O Git não pode decidir qual versão do código é a correta porque ele não entende a intenção e o contexto por trás das mudanças. Imagine um exemplo em que duas pessoas editaram a primeira linha de um mesmo arquivo:

• Alice alterou um texto para "Boas vindas ao nosso sistema!"

• Bob alterou o mesmo texto para "Olá! Esperamos que goste do nosso produto."

O Git não pode simplesmente escolher uma versão sem interferência humana, porque não sabe qual das mensagens é mais apropriada. Essa decisão precisa ser feita por uma pessoa, analisando o contexto.

O Processo de Merge

Quando você executa o comando git merge, o Git tenta combinar as alterações de dois branches. O processo de mesclagem pode resultar em três tipos de cenário:

1. O Git não consegue iniciar o merge: Caso haja mudanças no diretório de trabalho ou na área de staging do projeto atual, o merge não é iniciado.

2. O merge ocorre sem conflitos: O Git consegue combinar todas as mudanças automaticamente.

3. O merge é interrompido por presença de conflito(s): O Git não consegue resolver automaticamente uma ou mais diferenças entre os branches e precisa da sua intervenção para resolver o conflito.

A seguir, vamos detalhar cada um desses casos.

O Git não Consegue Iniciar o Merge

A inicialização do merge pode falhar se existirem mudanças no diretório de trabalho ou na área de staging do projeto atual.

O Git não pode iniciar o merge, pois essas mudanças pendentes podem ser gravadas pelos commits que estão passando pelo processo de merge. Quando esse tipo de erro acontece, é por causa de conflitos com mudanças locais pendentes, não conflitos com outros desenvolvedores. A falha da inicialização do merge vai fazer com que a mensagem de erro a seguir seja exibida:

error: Entry '<...>' not uptodate. Cannot merge. (Changes in working directory)

Você precisará comitar ou descartar as suas mudanças locais para ter sucesso ao executar o merge novamente.

Merge sem Conflito

Este é o caso descrito na seção anterior. Quando não há conflito, o Git consegue realizar o merge automaticamente e já cria um commit para você. Esse commit de merge é criado automaticamente, sem a necessidade de intervenção manual. A mensagem exibida será algo assim:

git merge nova-feature
▶ Updating a1b2c3d..d4e5f6g
Fast-forward
 file1.txt |  2 +-
 file2.txt |  8 +++++---
 2 files changed, 5 insertions(+), 5 deletions(-)

Isso indica que o Git realizou um merge, onde as mudanças foram integradas sem conflitos. Ao inspecionar o log de commits, você conseguirá ver o novo commit realizado:

Ao verificar o histórico de commits, você verá o merge registrado.

git log --oneline
▶ d4e5f6g Merge branch 'nova-feature'
b2c3d4e Adiciona funcionalidade X
a1b2c3d Corrige bug na tela de login
z1x2c3v Versão anterior do projeto

Merge com Conflito

Quando um ou mais conflitos ocorrem durante o merge, o Git não pode decidir automaticamente qual versão do código deve ser mantida e marca o(s) conflito(s) para que você resolva manualmente.

O Git interrompe o processo de merge e solicita que você edite os arquivos conflitantes. Você verá uma mensagem como essa:

git merge nova-feature
▶ Auto-merging arquivo1.txt
CONFLICT (content): Merge conflict in arquivo1.txt
Auto-merging arquivo2.txt
CONFLICT (content): Merge conflict in arquivo2.txt
Automatic merge failed; fix conflicts and then commit the result.

Essa mensagem indica que o merge automático falhou pois ocorreram conflitos nos arquivos arquivo1.txt e arquivo2.txt.

Diante deste cenário, você possui duas opção de como prosseguir:

1. Cancelamento do merge: Se você decidir que não deseja continuar o merge, é possível abortá-lo.

2. Resolução dos conflitos: explicar

Cancelamento do Merge

Se você deseja cancelar o merge completamente e voltar ao estado anterior, use o comando:

git merge --abort

Esse comando desfaz todas as mudanças feitas durante o merge e retorna o repositório ao estado anterior à tentativa de mesclagem.

Resolução dos Conflitos

O outro cenário possível é quando você deseja seguir em frente com o merge e irá resolver os conflitos manualmente.

Ao executar git status você poderá consultar novamente quais os arquivos que possuem conflitos.

On branch main
You have unmerged paths.
  (fix conflicts and run "git commit")

Unmerged paths:
  (use "git add <file>..." to mark resolution)
	both modified:   arquivo1.txt
	both modified:   arquivo2.txt

Após identificar os arquivos com conflitos, você deve abri-los no seu editor de texto. O Git terá adicionado marcadores especiais para apontar as partes conflitantes do código, desta forma:

<<<<<<< HEAD
Código do branch atual.
=======
Código do branch que você está mesclando.
>>>>>>> nome-do-branch

• O trecho entre <<<<<<< HEAD e ======= representa o código do seu branch atual.

• O trecho entre ======= e >>>>>>> nome-do-branch mostra o código do branch que você está tentando mesclar.

Você precisa editar cada arquivo manualmente para escolher qual parte do código manter ou, se necessário, combinar as duas versões.

Após editar o arquivo, remova os marcadores (<<<<<<<, =======, >>>>>>>) e salve as mudanças.

Ao resolver o conflito, use o comando git add para informar ao Git que o conflito foi resolvido em cada um dos arquivos:

git add arquivo1.txt arquivo2.txt

Ao resolver todos os conflitos, você pode finalizar a mesclagem realizando o commit de merge:

git commit -m "Merge branch 'nova-feature'"

Este commit irá incluir todas as mudanças do merge—tanto as resolvidas manualmente quanto as mescladas automaticamente.

Como Funciona

O comando git diff é usado para mostrar as diferenças entre o estado atual do seu repositório e o último commit. Ele é útil para visualizar as alterações feitas nos arquivos antes de criar um novo commit.

No terminal, o output do git diff apresentará as diferenças de forma clara. Cada alteração será mostrada com um prefixo indicando se é uma adição +, uma remoção -, ou uma modificação *.

Estrutura

Esta é a estrutura base do comando git diff que iremos utilizar neste momento

git diff [arquivo]

Em que:

• git diff: Este é o comando principal que invoca a ferramenta de diferenciação do Git.

• [arquivo] (opcional): Este é um argumento opcional que especifica o arquivo específico para o qual você deseja ver as diferenças. Se nenhum arquivo for especificado, o git diff mostrará as diferenças de todos os arquivos modificados em relação ao último commit.

Exemplo de Uso

Exemplo 1: git diff arquivo

Suponha que o arquivo index.html originalmente tinha o seguinte conteúdo:

<!DOCTYPE html>
<html>
<head>
    <title>Meu Site</title>
</head>
<body>
    <!-- Conteúdo do site -->
</body>
</html>

Agora, você fez algumas alterações nesse arquivo. Por exemplo, você modificou o título do site. O arquivo index.html modificado ficou assim:

<!DOCTYPE html>
<html>
<head>
    <title>Meu Novo Site</title>
</head>
<body>
    <!-- Conteúdo do site -->
</body>
</html>

Ao executar o comando git diff index.html, o output no terminal mostrará as diferenças entre o estado atual do arquivo index.html e o último commit. Ele indicará que o título do site foi alterado de "Meu Site" para "Meu Novo Site", destacando essa mudança no código:

diff --git a/index.html b/index.html
index abcdef1..1234567 100644
--- a/index.html
+++ b/index.html
@@ -1,5 +1,5 @@
 <!DOCTYPE html>
 <html>
 <head>
-    <title>Meu Site</title>
+    <title>Meu Novo Site</title>
 </head>
 <body>

Em que:

1. Diff do arquivo index.html:

   Copiar

   diff --git a/index.html b/index.html

   Esta linha indica que está sendo mostrada a diferença entre dois arquivos: a/index.html (o arquivo original) e b/index.html (o arquivo modificado).

2. Cabeçalho de Mudança::

   Copiar

   index abcdef1..1234567 100644
   --- a/index.html
   +++ b/index.html

   Este cabeçalho técnico fornece informações detalhadas sobre as mudanças nos arquivos e pode ser ignorado por enquanto, focando apenas nas alterações visíveis no conteúdo.

3. Linha de Mudança:

   Copiar

   @@ -1,5 +1,5 @@

   Esta linha mostra a linha inicial e o número de linhas afetadas pela mudança em cada arquivo. No exemplo, -1,5 indica que a mudança começa na linha 1 do arquivo original (a/index.html) e afeta 5 linhas. +1,5 indica que a mudança começa na linha 1 do arquivo modificado (b/index.html) e também afeta 5 linhas.

4. Alterações Específicas:

   Copiar

   -    <title>Meu Site</title>
   +    <title>Meu Novo Site</title>

   Essas linhas mostram as alterações específicas que ocorreram em cada versão do arquivo. A linha original <title>Meu Site</title> foi removida (indicada pelo sinal -). Em seu lugar, foi adicionada a linha <title>Meu Novo Site</title> (indicada pelo sinal +).

Exemplo 2: git diff

Para visualizar as diferenças em todos os arquivos modificados, basta utilizar o comando git diff sem nenhum argumento. Dessa forma, o Git apresentará todas as alterações realizadas em todos os arquivos do repositório, oferecendo uma visão abrangente das mudanças efetuadas, sem focar em um arquivo específico, ao contrário do comando git diff arquivo.

Conteúdo Original dos Arquivos:

index.html:

<!DOCTYPE html>
<html>
<head>
    <title>Meu Site</title>
</head>
<body>
    <!-- Conteúdo do site -->
</body>
</html>