Git e Github: Perguntas e Exemplos

Com uma pesquisa simples no Google você consegue encontrar vários artigos explicando o que são Git e Github, logo o conhecimento técnico está disponível, mas em algumas vezes não tão acessível assim, necessitando de mais exemplos para entendermos porque eles existem, entre outras funcionalidades. Esse artigo vai buscar explicar com alguns exemplos estes conceitos importantes sobre Git e Github.

Git é um sistema de versionamento de código, criado pelo Engenheiro de software Linus Torvalds (Sim, aquele Linus), que busca resolver o problema muito frequente do controle de versões de um projeto que está sendo desenvolvido por uma equipe de pessoas (Obviamente que você também pode usar o Git desenvolvendo um projeto sozinho). O Git criou um sistema de identificação excelente para cada versão de código, feito por cada membro da equipe, que podem atualizar o projeto principal, conforme este vai sendo desenvolvido. Ainda não ficou claro? Vamos para um exemplo.

Todo mundo já se deparou com o problema do meme acima né? Num trabalho em grupo, é muito mais confortável definir o que cada membro fará, para ter sua liberdade de desenvolver sua parte do jeito que você quiser, mas o mundo ideal não existe. Quando o momento de juntar as partes chega, você percebe que a divisão de vocês não foi tão bem feita, mesmo que boa parte do trabalho seja aproveitável, vocês precisariam de um pouco mais tempo para arrumar as falhas, porém o tempo está quase sempre escasso, impedindo que o objetivo seja atingido com qualidade.

Então, o Git existe para consertar esse problema. Ele não centraliza todo o desenvolvimento em um arquivo, ele continua dividindo as versões, mas dessas vez em branches, que são ramificações identificadas com um código chamado de “Sha1” para cada versão. Após cada membro trabalhar nas suas versões, eles podem dar “Commit” que é algo semelhante a “publicar” na versão principal. É nesse momento que acontece uma das grandes soluções do Git, pois ele identifica as diferenças entre a versão principal compartilhada por todos e as atualizações feitas pelos membros, só permitindo que a versão principal seja atualizada se o código da branch for corrigido e adaptado, permitindo que a “correção de falhas” aconteça em tempo real, melhorando a qualidade do projeto e permitindo aos desenvolvedores que construam códigos condizentes com o que o grupo está produzindo.

Esses são os estágios que um arquivo passa dentro do Git. O Untracked é o estágio em que o arquivo ainda não “existe” para o Git, em que provavelmente ele está na sua máquina ou não compartilhado com ninguém. Esse arquivo passa a existir pro Git quando é adicionado, entrando no estágio de Staged, este estágio é quando o Git sabe que o arquivo existe, mas ainda não está publicado e com um sha1 disponível. Após este estágio, o arquivo vai para o estágio de Unmodified, que é estado que o Arquivo principal fica, logo o objetivo de cada modificação e transformá-la para este estágio. Com o spoiler dado, o estágio de Modified é o estágio do arquivo que está sendo alterado por algum membro do grupo. Após, o ciclo volta para Staged e continua nos outros estágios. Agora um exemplo mais prático.

Imagine que você está no McDonalds prestes a fazer seu pedido de 1 BigMac, 1 Refigerante, 1 Torta de Maçã , 1 Porção de batatas e 1 Porção de Nuggets, enquanto isso na cozinha está acontecendo todo um processo para que seu lanche chegue até você.

A matéria-prima para que seu lanche chegue até você está num estágio de Unmodified, ela existe, mas ainda não entrou na cadeia de processamento do lanche, quando esses mantimentos forem adicionados à cadeia, eles ficam disponíveis para uso, logo ficam Staged, ao esses mantimentos ficarem disponíveis, eles serão tratados por cada um dos membros da cozinha, alguns membros ficam responsáveis pelas batatas, uns pelo BigMac, outros pela torta de maçã, todos sendo preparados para compor seu pedido, quando essas diferentes composições ficarem prontas, elas receberão Commit e irão para o balcão. Mas ao receber o pedido, você notou que os seus Nuggets não vieram, então você não aceita e pede para que seja corrigido, após a correção, você aceita o pedido e vai feliz fazer seu lanche, logo esse seu lanche entra em estágio de Unmodified. No entanto, você estava numa lanchonete diferente do McDonalds, em que você pagaria apenas antes de ir embora para sua casa, eis que você fica com vontade de tomar um doce e pede mais um sorvete, logo o seu pedido final entrou em estágio de Modified, pois quando você for pagar a conta, não vai pagar pelo pedido original, vai pagar pelo pedido original mais a modificação que você fez depois. Então, com seu pedido original e atualizado, você volta feliz da vida para sua casa e outros ciclos de pedido continuam na lanchonete do McDonalds.

O GitHub é toda essa lógica de versionamento do Git expandido numa escala de rede social, em que cada desenvolvedor pode fazer seus projetos, publicá-los no GitHub e deixar disponível para quem bem desejar. Este projeto pode ser receber Fork de outros usuários, que podem desenvolver suas próprias alterações a partir de então.

Então você poderá a partir de então ter seus projetos “Garfados” por outros usuários e melhorados por estes.

Agora é a hora de pegar esses conceitos e aplicá-los em projetos de verdade, pois assim como qualquer ferramenta, você só aprenderá a usar o Git baixando para sua máquina e utilizando para algum projeto. Também assim como qualquer rede social você só aprenderá a usar o Github se fizer uma conta e começar a publicar seus projetos lá. Espero que este artigo seja um incentivo para que você se desenvolva nessa ferramenta e continue a ler meus artigos.

Você pode me acompanhar em outras fontes pelo link: linktr.ee/otaviodefilpo

Padawan em Engenharia, meio ambiente e ciência de dados. Sempre atento às mudanças do mundo 🌅

Padawan em Engenharia, meio ambiente e ciência de dados. Sempre atento às mudanças do mundo 🌅