Como usar o Git e o GitHub na prática: um guia simplificado para leigos

Já ouviu falar do Git? E do GitHub? 

Hoje vamos mostrar um passo a passo simplificado do funcionamento dessas incríveis ferramentas para você, meu amigo leigo interessado em tecnologia. Vamos explicar os conceitos principais, como utilizar o Git para gerenciar o seu código e como criar o seu perfil no GitHub para montar o seu portfólio virtual.

Ainda que você não seja programador, é uma ótima oportunidade para aprender como funciona o Git e o GitHub, absorver alguns conceitos básicos e se familiarizar com essa incrível ferramenta que irá abrigar todos os códigos compartilhados aqui no site para vocês acompanharem.

Deixo aqui abaixo também o vídeo sobre este assunto que gravamos para o nosso canal no YouTube, que é um espaço em que compartilho algumas opiniões, dicas e projetos com outros interessados em tecnologia, seja você programador, advogado ou entusiasta.  Aproveita para se inscrever lá e não perder os próximos vídeos, prometo que farei conteúdos interessantes e algumas lives com "coding sessions" bem legais.

Veja aqui: https://youtu.be/cnIYisCYlzM

Tudo certo? Então vem comigo.

O Git: um programa para controle de versão¶

No mundo do desenvolvimento, é boa prática que todo o seu projeto seja versionado, ou seja, que você possa "arquivar" todas as alterações efetuadas no seu código ao longo do seu desenvolvimento em versões diferentes. 

Dessa forma, qualquer desenvolvedor pode rapidamente localizar alterações efetuadas, receber colaborações em partes do código de terceiros e ter um backup do seu código de forma prática e detalhada sem precisar salvar em seu computador inúmeras pastas e arquivos com nomes como "v1.0.0.1", "versão_de_27_de_julho_de_2021.zip" ou "versão inicial", como eu costumava fazer antigamente. Antes de conhecer o Git, era comum eu pesquisar nos HDs externos aqui a versão que eu utilizei no projeto e o backup que enviei para o meu e-mail. Uma bagunça.

Habemus versões?

Nesse cenário, entra o Git, um programa de computador para controle de versões usado para gerenciar códigos de projetos em todo o mundo.

O Git nasceu com pelas mãos de Linus Torvalds (o "pai" do Linux) em 2005 para ser utilizado no desenvolvimento do Kernel Linux (o núcleo do Linux), sendo posteriormente adotado por outros projetos. [Veja aqui mais informações sobre o Git]

No meu primeiro emprego na área de tecnologia como (nos idos dos anos 2003), era comum dar confusão quando outro colega estava com o mesmo arquivo aberto e mexendo, comprometendo muitas vezes outras partes do programa em que eu estava trabalhando. Com o Git, esse problema é superado.

O Git possibilita centralizar o código de um projeto e rastrear as alterações feitas neste código por uma ou mais pessoas. Assim, times inteiros podem trabalhar ao mesmo tempo no código sem atrapalhar uns aos outros, e projetos que envolvem muitas pessoas diferentes podem evoluir em uma velocidade incrível. Você mesmo pode contribuir com um projeto de código livre criando uma funcionalidade que ainda não existe e sugerindo ao "dono" do código as suas alterações. Veremos isso em mais detalhes.

E o GitHub, o que é?¶

O GitHub, por sua vez, é uma plataforma que disponibiliza o Git aos seus usuários "na nuvem". Em outras palavras, é um site que permite que você crie e guarde os seus códigos, que estarão disponíveis e poderão ser atualizados via Git pela Internet. Existem outras alternativas como o BitBucket (que é o que eu uso há muitos anos e que tem todos os meus projetos privados) e o GitLab, ambas excelentes, mas ficaremos aqui no GitHub que é a mais famosa.

Você pode (e deve) criar o seu perfil no GitHub gratuitamente, acessando o site github.com e clicando em "SignUp". 

O GitHub

Uma vez cadastrado, você pode criar o seu primeiro repositório, clicando na sua foto no menu, em "Seus Repositórios" (Your repositories) e, finalmente, em "Novo" (New). A partir daí é fácil: defina o nome do seu repositório (vamos chamar também de "repo" para facilitar), estabeleça se ele será público ou privado (todos tem acesso ou apenas você), e pronto!

Um repo funciona como uma "pasta" para os seus arquivos. Uma vez que você o cria, pode enviar arquivos e atualizações para ele via Git e ele começará a armazenar as informações. 

No GitHub você verá inúmeros repositórios públicos (como os repositórios do dev.lawyer) em que você pode acessar, copiar, utilizar e contribuir com o código como julgar conveniente. 

Além de uma  plataforma para backup e versionamento, o GitHub permite que você encontre colaboradores para um projeto do seu interesse, ajude outras pessoas em projetos interessantes e utilize o GitHub como o seu próprio "portfólio" de programação, já que todos podem acessar o seu perfil e ter uma ideia do tipo de programador que você é. Eu arrisco dizer que hoje ter um bom GitHub é mais importante para desenvolvedores do que um bom LinkedIn. Muitos recrutadores pedem o link do seu GitHub como meio de avaliar o que você faz no meio da tecnologia.

Criou o seu perfil? Pois então me segue lá, e vamos trocar figurinhas.

Meu perfil no GitHub: https://github.com/OctavioSI

Perfil do Dev.Lawyer no GitHub: https://github.com/Dev-Lawyer

Link para o repositório deste conteúdo: https://github.com/Dev-Lawyer/GitEGitHub

Como funciona e como usar o Git e o GitHub na prática?¶

A melhor maneira de aprender é fazendo.  Primeiro instale a última versão do Git em sua máquina, que pode ser encontrada aqui: https://git-scm.com/downloads

Após instalar, você terá acesso a um terminal com o git (geralmente pré-instalado na maioria das distribuições Linux e, no caso do Windows, por meio do programa chamado "Git Bash"). Utilizaremos o Git pelo terminal -- não assuste, pois uma vez que você acostumar com os comandos básicos, tudo ficará mais fácil.

Agora vamos criar um novo repo no GitHub. Vou criar o meu no perfil do Dev.Lawyer, mas façam as correspondências necessárias. O nosso primeiro repositório será chamado de "GitEGitHub", e teremos apenas um README.md (arquivo com informações do repositório).

Criando um novo repo

Com o repo criado, você pode então "cloná-lo" no seu computador. Continue lendo que explicaremos melhor o funcionamento e fluxo dos repositórios mas, em linhas gerais, significa que faremos uma cópia no seu computador desse repositório que está no GitHub, na nuvem. Na página do repo há um botão "Code", sendo que uma das opções é exatamente a de "clonar".

Clonando um repo localmente

Você pode clonar o repo diretamente pelo Git, usando o seguinte comando (troque o endereço pelo endereço do seu repo que foi criado e que está na barrinha ali na figura acima):

git clone https://github.com/Dev-Lawyer/GitEGitHub.git

Como o repositório criado é público, conseguimos cloná-lo sem problemas localmente. Se fosse um repo privado, seria necessário realizar a autenticação no GitHub.

Clonando o repo localmente

Com o repo clonado, podemos acessar a cópia local criada e modificar os seus arquivos. Você perceberá que existe aqui uma pasta ".git", que possui informações do nosso repositório (indica que estamos em uma pasta que é gerenciada pelo Git), um arquivo "LICENSE" (dispõe a licença de uso que definimos) e finalmente o README.md, todos criados pelo próprio GitHub.

Como o nosso repo está atualmente

Vamos alterar o conteúdo do README.md que veio na nossa pasta local para incluir o link deste artigo e salvá-lo. Podemos fazer isso em qualquer editor de texto.

Após alterarmos o arquivo, seguiremos os seguintes passos:

• No terminal (ou no Git Bash) vamos entrar na pasta do nosso repo (você pode navegar com o comando "cd");

• Uma vez dentro da pasta, vamos adicionar todos os arquivos modificados com o comando "git add -A"

• Vamos agora fazer um "commit" (ou "comitar", como é comum aportuguesarmos isso), que nada mais é do que indicar para o Git que estamos criando um "checkpoint" no código, uma nova versão. Colocamos aqui uma opção -m '<mensagem>' para definir a descrição que este commit terá.

• Não se aplicaria em nosso caso já que o repo é recente e apenas nós estamos usando, mas aqui seria o momento de baixar quaisquer alterações que o nosso código remoto (que está na nuvem) possa ter sofrido, com o comando "git pull" (ou "puxar alterações");

• Se houver conflitos entre a versão remota e a versão local, arrumamos os problemas indicados pelo Git e comitamos uma nova versão, na qual o código remoto alterado fica "incorporado" no nosso código. Estando tudo certo, sem conflitos, enviamos então o nosso código local ao código remoto, que terá agora os mesmos commits, com o comando "git push origin" (vamos empurrar para a "origin", que é como o nosso repo remoto está definido, os commits locais).

Comitando as nossas alterações locais e enviando ao repo remoto no GitHub

Os comandos utilizados acima foram:

cd ~/Projects/devlawyer/GitEGitHub/
git add -A
git commit -m 'Atualizando o link do artigo'
git pull
git push origin

Se acessarmos agora o nosso repo no GitHub, veremos que ele foi atualizado e que o commit que fizemos está lá. O README.md também já reflete o link atualizado do artigo que fornecemos.

Nosso commit funcionou :)

Clicando nos commits anteriores nós conseguimos ver como os arquivos eram naquele ponto exato do tempo. 

Isso é o básico do Git, mas podemos fazer muito mais do que isso (e se houver interesse posso criar mais conteúdos sobre o tema), como:

• criar sub-divisões do nosso repo para tratar de uma funcionalidade, bug ou característica isoladamente (criando uma "ramificação" ou "branch");

• criar ambientes de teste e produção, para que o código possa ser testado antes de chegar ao usuário final;

• definir fluxos de trabalho para que equipes participem simultaneamente do projeto, com fluxos de revisão e aprovação (workflow);

• estruturar rotinas automatizadas para validar o código que está sendo sincronizado, evitando erros em nossos programas antes de chegarem ao ambiente de produção; e

• "empurrar" código para outros repositórios, colaborando em um projeto de terceiros.

Simples ou parece muito complicado?

O Git serve só para código ou posso versionar qualquer documento? ¶

Sim, o Git não é limitado a código! Em realidade, o Git pode ser usado para registrar um histórico de alterações em qualquer tipo de documento.

É interessante notar que existem ferramentas que já utilizam o conceito de versionamento para controle de arquivos como excel e word, como o GitPitch e o Simul. O controle de histórico de versões, no entanto, ainda é um pouco limitado para arquivos "fechados" como .xlsx ou .docx, o que torna essas interessantes soluções menos funcionais quando comparadas ao que o controle de versões faz para códigos de programação.

É possível listar algumas vantagens em se utilizar o Git para o versionamento de documentos: você conta com um backup da sua documentação mais confiável do que criar arquivos separadamente em seu computador, é possível "colaborar" com outras pessoas em um documento desde que usando um arquivo de texto ("não fechado" como o docx ou o markdown que usamos em nosso README.md) e usar o Git torna o seu progresso rastreável.

Há quem questione a vantagem disso, posto que você pode usar ferramentas de versão contidas no Dropbox ou Google Docs, por exemplo, o que faz sentido também a depender do seu modo de trabalho. Mas é inegável que o uso do Git é possível e bem visto para o gerenciamento de documentos.

Certamente exploraremos mais esse assunto no futuro, dado o nosso público "legal".

Mas tudo isso apenas para um controle de versão? Vale a pena? ¶

Quando olhamos uma plataforma como o GitHub fica claro que o grande valor do serviço não é apenas no armazenamento de código e histórico de versões. O que o serviço se tornou, em realidade, é em uma gigantesca comunidade de colaboradores.

Com a disponibilização do código para que mais pessoas possam aprender, usar o código e compartilhar/melhorar/complementar/corrigir, o GitHub tornou-se em um grande espaço de economia colaborativa.

De uma forma ou de outra, vale a leitura se você quer acompanhar as próximas postagens -- estou constantemente pensando em como integrar tecnologia e Direito, e este é o primeiro passo para todos que desejam acompanhar o conteúdo aqui.


/* Fim do post, até a próxima */