Primeiras aulas do curso Git e Github: estratégias de ramificação, Conflitos e Pull Requests

Git e Github: estratégias de ramificação, Conflitos e Pull Requests

GitHub e OpenSource - Introdução

Olá, pessoal, boas vindas à Alura, meu nome é Vinicius Dias e os guiarei nessa continuação do curso sobre Git e GitHub, em que teremos uma visão geral sobre o que é open source e como contribuir para projetos do tipo, especificamente trabalhando com o GitHub.

Veremos o que é uma issue, como abrir e fechá-la, como lidar com ela, de forma geral, o que pode ser um problema, um relatório de bug. Também entenderemos como gerenciar e lidar com pull request, ou seja, como enviar pedidos e sugestões de melhorias em código para projetos open source.

Aprenderemos boas práticas para contribuir, como não utilizar tantos commits e conseguir unir vários deles em um só. Falaremos sobre um controle um pouco mais refinado e avançado de versionamento, gestão de conflitos, busca avançada de commits, formas de encontrar modificações, entre outros.

Para continuarmos nessa parte de profissionalismo e boas práticas, falaremos sobre estratégias de branching, entendendo como organizar nossas branches de forma bem interessante. Depois, conheceremos ferramentas como o GitKraken, que nos auxiliará a executar estas alterações e boas práticas de Git e gerenciar o versionamento do nosso código de forma facilitada.

Além disso, conheceremos os eventos, os git hooks, ações que são executadas em determinados eventos. Assim, com apenas um push, seremos capazes de executar o deploy de uma aplicação, disponível para acesso. Será um curso bem interessante, relativamente curto, espero que vocês tirem bastante proveito.

Caso surja alguma dúvida no decorrer do curso, não hesite em abrir uma dúvida no fórum, e espero vocês no próximo vídeo para começarmos a colocar a mão na massa!

GitHub e OpenSource - Issues

Está na hora de conversarmos um pouco mais sobre o GitHub, o gerenciador de repositórios remotos, muito utilizado pela comunidade de desenvolvimento open source, ou seja, em projetos de código aberto. Isso quer dizer que o código será disponibilizado em algum lugar público, como o GitHub, para que outras pessoas possam contribuir sugerindo melhorias, implementando-as, solicitar features específicas, e assim por diante, tornando o projeto efetivamente colaborativo.

Você pode estar se perguntando: "vou desenvolver meu projeto e colocá-lo na internet para que todo mundo veja o meu código e copie meu trabalho?" Não é com esta mentalidade que o software livre funciona; quando desenvolvemos projetos de código aberto, pensamos nas vantagens e possibilidades que eles podem alcançar.

Alguns exemplos de projetos com códigos simples e abertos são o VS Code, editor que temos utilizado, o npm, gerenciador de pacotes usado para baixar dependências no JavaScript, e até linguagens como o PHP. Eles trazem muitas vantagens, dentre as quais permitir a melhoria contínua do código de maneira colaborativa. Para mais detalhes, fica a recomendação de se pesquisar um pouco mais a fundo sobre o assunto; existem inclusive cursos sobre Linux que tocam em open source, palestras na internet, como a da Daiane Alves no evento Darkmira Tour PHP em 2019, que fala sobre como empreender utilizando software livre, é bastante interessante pesquisar sobre tudo isso.

Voltando ao GitHub, que é a "casa" de muitos projetos open source, temos algumas boas funcionalidades, como as "Issues", ou "problemas", em tradução livre, em que é possível controlar as sugestões de melhorias, pedidos de novas funcionalidades, e assim por diante. Existem alguns projetos que utilizam as issues de forma até mais interessante, e como exemplo, está o repositório de uma comunidade chamada PHPRio, disponibilizado para cadastro de palestras ou palestrantes, o que é realizado por meio das issues do GitHub.

Assim, podemos filtrar palestrantes através da lista de issues do projeto! Conseguimos gerenciar este tipo de conteúdo, que não é um "problema" propriamente dito. Voltando para o nosso caso, poderemos começar a pensar na colaboração de outras pessoas. Para tal, criaremos uma sugestão, dentro de "Issues", clicando no botão "New issue", algo possível de se fazer em qualquer repositório.

O título poderá ser algo do tipo "Adicionar título na página", e a descrição, "A página contém apenas a lista dos cursos. Senti falta de um título.". Não é algo tão importante de início, mas vale ressaltar que é possível utilizar código markdown. Clicaremos no botão "Submit new issue" para enviar a issue, que passará a figurar em uma lista, a partir da qual, se você gerencia um projeto de software livre, conseguirá organizá-la por ordem de prioridade.

Sugiro que deem uma olhada nos projetos que vocês utilizam para verificar se são de código aberto, e se forem, verifiquem suas listas de issues, talvez haja algo com que vocês possam contribuir. Durante este curso entenderemos um pouco melhor sobre como fazer isto, também. Vamos resolver o problema que acabamos de criar a seguir.

GitHub e OpenSource - Pull Requests

Sobre as issues, ou problemas do GitHub, um ponto interessante é que se tivermos as permissões necessárias, ou seja, se formos os donos do repositório, ou fizermos parte da organização da empresa, poderemos fechar a issue ("Close issue"), indicando que o problema já foi resolvido. Se a issue estiver fechada, nestas condições, poderemos reabri-la para informar que o problema voltou a acontecer, por exemplo, e todo o histórico fica salvo no GitHub.

Vamos supor que outra pessoa da mesma equipe, Ana, já conhece o projeto e sabe como resolver o problema que publicamos anteriormente. Ela não poderá simplesmente editar o código criado pelo Vinicius. Isso evita que uma pessoa mal intencionada tenha acesso total ao código, criando bugs propositais, ou incluindo um código que não faz sentido. Então, mesmo que o projeto seja open source, existe sempre alguém validando estas alterações, garantindo que elas sejam de fato benéficas para o projeto.

Assim, o primeiro passo para que a Ana possa contribuir no projeto do Vinicius é criar uma cópia do mesmo para trabalhar nele e, no final, quando finalizada a solução da issue, ela enviará ao repositório do Vinicius apenas as alterações feitas. Vamos criar este repositório cópia!

Quando trabalhamos com controle de versões, principalmente com o Git e o GitHub, o nome deste repositório cópia é fork, que remete aos dentes de um "garfo", em inglês. Então, logados como Ana, clicaremos no botão "Fork" no topo direito da página. Ao atualizarmos a página, verificaremos a existência da cópia do projeto para analura, que é da Ana, e ela poderá editar este projeto da forma como preferir.

Temos todo este código na máquina local, no diretório "projeto", e garantiremos isto acessando o repositório pelo Terminal digitando cd ana/ seguido de cd projeto/. Executaremos git pull origin master, e teremos a mensagem de que este repositório não existe. Aqui, entra outro assunto: adicionaremos, com o origin, o repositório da Ana, o outro repositório, aquele que copiamos. Para isto, voltaremos ao GitHub e clicaremos em "Clone or download", um botão dropdown que exibe um link, que copiaremos.

No Terminal, digitaremos git remote add origin colar o link no comando e dar "Enter". E então traremos as alterações com git pull origin master. No VS Code, confirmaremos que o código está atualizado como esperávamos. Já temos o repositório local, como Ana, sincronizado com o nosso fork, no GitHub da Ana.

Feito isso, no código no VS Code, adicionaremos um título, acrescentando uma linha antes da abertura da tag <ul>: <h1>Cursos de DevOps</h1>. Criaremos um commit no Terminal começando por git status e git diff para verificarmos as modificações realizadas, e então git add index.html e git commit -m "Título adicionado". Repetiremos o mesmo processo após pularmos uma linha entre a linha recém implementada e <ul>, sendo portanto o último comando digitado git commit -m "Quebra de linha".

Feitas todas estas alterações, enviaremos os dados ao repositório com git push origin master. Porém, o envio será rejeitado, pois não temos permissão para isso. Para resolvermos isto, o primeiro passo será configurar o e-mail da Ana, com git config --local user.email "anaalura123321@gmail.com". Depois, usaremos git push origin master para verificarmos se, com isto, temos sucesso.

Não conseguiremos acesso, e o que acontece é que se fosse em um ambiente MacOX ou Linux, provavelmente você já teria recebido uma mensagem pedindo o login e senha do GitHub. No Windows, como já adicionamos um repositório do GitHub anteriormente, ele trabalha de forma diferente. A partir do momento em que adicionamos um repositório do GitHub, sempre que tentarmos enviar algo para lá, ele tentará utilizar estas credenciais.

Esta é a forma mais simples: apagaremos as credenciais do GitHub acessando "Painel de Controle > Contas de Usuário > Gerenciador de Credenciais > Credenciais do Windows". Dentre as Credenciais Genéricas, clicaremos na seta ao lado de git:https://github.com para que a informação seja expandida, e em "Remover". Assim, se tentarmos refazer o push, o GitHub nos solicitará os dados para login.

Faremos login como "analura", e agora, sim, conseguiremos enviar as alterações. Vamos atualizar a página com o projeto no GitHub, em que teremos mais commits adicionados — referentes ao título, e quebra de linha. De que forma enviaremos as modificações para o dono do repositório, ou seja, para o repositório do Vinicius?

Estas modificações são realizadas por meio de pull requests, um pedido de envio de modificação. Então, clicaremos no botão "New pull request", e o GitHub fará o trabalho de verificar se com o Git conseguimos fazer merges sem nenhum conflito, exibindo uma mensagem que diz que ambos os repositórios podem ser unificados sem nenhum problema, e mais abaixo, os commits enviados.

No fim, todas as alterações serão realizadas, neste caso, somente adicionamos duas linhas. Poderemos clicar em "Create pull request" para confirmar que queremos fazer esta ação, cujo título será "Adicionando título na página", sendo possível acrescentarmos um comentário, algo como "Adicionando um título para a página que antes não tinha.". Pressionaremos "Create pull resquest", e isto estará presente no repositório do Vinicius.

Poderemos confirmar isso logando como ele e acessando a aba "Pull requests" no GitHub. Analisaremos os commits e clicaremos em "Merge pull request" e "Confirm merge", já que não há nada a ser alterado. Com isto, teremos um pull request no status merged. É possível verificarmos o código, que estará com as alterações devidamente implementadas, e então fecharmos a issue, junto a um texto "Fechado pelo PR #2", clicando em "Close and comment".

A nossa issue estará fechada, e contendo um link para o último pull request junto a todas as alterações realizadas. Resumindo o que vimos, o Vinicius cria um repositório, a Ana enviou uma atualização, posteriormente revisado e autorizado pelo Vinicius, que enviou uma notificação informando que o pull request foi aceito.

Algo que não ficou tão legal, porém, é a lista de commits, pois o commit de quebra de linha não é relevante. Será que não seria interessante termos um único commit? Mas a Ana fez dois commits, e ela tem o direito de trabalhar com quantos quiser! Será que depois de realizar os commits, ela não conseguiria juntar vários em um só? Como será que conseguimos unir commits para ajudar quem for revisar o código?

Sobre o curso Git e Github: estratégias de ramificação, Conflitos e Pull Requests

O curso Git e Github: estratégias de ramificação, Conflitos e Pull Requests possui 116 minutos de vídeos, em um total de 41 atividades. Gostou? Conheça nossos outros cursos de Builds em DevOps, ou leia nossos artigos de DevOps.

Matricule-se e comece a estudar com a gente hoje! Conheça outros tópicos abordados durante o curso:

Aprenda Builds acessando integralmente esse e outros cursos, comece hoje!

Plus

  • Acesso a TODOS os cursos da plataforma

    Mais de 1200 cursos completamente atualizados, com novos lançamentos todas as semanas, em Programação, Front-end, UX & Design, Data Science, Mobile, DevOps e Inovação & Gestão.

  • Alura Challenges

    Desafios temáticos para você turbinar seu portfólio. Você aprende na prática, com exercícios e projetos que simulam o dia a dia profissional.

  • Alura Cases

    Webséries exclusivas com discussões avançadas sobre arquitetura de sistemas com profissionais de grandes corporações e startups.

  • Certificado

    Emitimos certificados para atestar que você finalizou nossos cursos e formações.

  • Alura Língua (incluindo curso Inglês para Devs)

    Estude a língua inglesa com um curso 100% focado em tecnologia e expanda seus horizontes profissionais.

12X
R$85
à vista R$1.020
Matricule-se

Pro

  • Acesso a TODOS os cursos da plataforma

    Mais de 1200 cursos completamente atualizados, com novos lançamentos todas as semanas, em Programação, Front-end, UX & Design, Data Science, Mobile, DevOps e Inovação & Gestão.

  • Alura Challenges

    Desafios temáticos para você turbinar seu portfólio. Você aprende na prática, com exercícios e projetos que simulam o dia a dia profissional.

  • Alura Cases

    Webséries exclusivas com discussões avançadas sobre arquitetura de sistemas com profissionais de grandes corporações e startups.

  • Certificado

    Emitimos certificados para atestar que você finalizou nossos cursos e formações.

  • Alura Língua (incluindo curso Inglês para Devs)

    Estude a língua inglesa com um curso 100% focado em tecnologia e expanda seus horizontes profissionais.

12X
R$120
à vista R$1.440
Matricule-se
Conheça os Planos para Empresas

Acesso completo
durante 1 ano

Estude 24h/dia
onde e quando quiser

Novos cursos
todas as semanas