Uma forma revolucionária de gerenciar seu time e seu projeto

Revolucionário? O Git? Que exagero! Você pode dizer.

Sim. Eu também diria a mesma coisa. Já trabalho com o Git a mais de 2 anos e para mim ele se tornou uma simples ferramenta de trabalho. Indispensável, mas simples. Acontece que na sua simplicidade se esconde a força de sua complexidade.

Você provavelmente deve imaginar que muito pesquisei sobre Git antes de escrever esse post, a fim de entender melhor a dinâmica de seu funcionamento. De fato, li muitos textos antes de começar mais um, procurei imagens didáticas e rodei o mundo a procura de especialistas sem a parte de rodar o mundo hehe.

Porém, depois de achar um mundo de bons artigos, pensei o que faria o meu post único, de forma a manter a identidade do blog e, mais importante, que acrescentasse algo para o leitor.

E finalmente, depois de muito pensar mentira, nem pensei tanto assim, decidi seguir um rumo um pouco diferente. Este não será um post técnico, mas mais subjetivo e escrito com minhas próprias palavras e as abstrações que consegui fazer do funcionamento do Git.

Versionador

créditos da imagem à Bruna ♥

Imagine antigamente, antes dos cloud services dropbox, box, drive, etc existirem, como um time de desenvolvedores fazia para compartilhar as alterações feita por cada um no projeto?

Bom, se não compartilhavam por disquete ou CD, era no mínimo por pendrive, espetando o dito cujo em cada computador, juntando as alterações manualmente nos arquivos já existentes e depois anotando, talvez no notepad ou em um papel, o que mudou nessa nova versão.

Bom, com os serviços de compartilhamento atuais tudo ficou mais fácil e natural. Basta colocar um projeto na nuvem, dar acesso a todos da equipe, e voilà, teremos mais ou menos um controle sobre todas as alterações e de forma um pouco mais fácil do que ficar espetando o bom e velho pendrive.

Tudo quase lindo.

Queremos uma ferramenta que nos dê controle total sobre todas as alterações, com informações contextuais que digam o que foi alterado, onde, quando, por quem, e porquê ufa!. Também queremos fazer isso da forma mais simples o possível, de forma que, por exemplo, eu consiga migrar entre diferentes dispositivos e sempre ter a versão mais atual do projeto.

Queremos atualizar, alterar, e gerenciar nossos projetos e nossa equipe de qualquer lugar do mundo, como citei nesse meu último post.

É para isso que o Git serve.

E sim, é isso tudo mesmo. Tão fácil quanto digitar 3 linhas de comando, ou dar 3 cliques, ou tomar um chocolate quente em um dia chuvoso.

Desde o início do projeto, temos esse controle todo. No começo pode parecer complexo, mas rapidamente tudo se torna tão natural quanto a luz do dia mas que preguiça boa, me deixa aqui atoa . E a cada alteração, ou conjunto de alterações feitas ao projeto, podemos lançar o que chamamos de nova versão do projeto.

Esse é um dos trabalhos do Git, ser um controlador de versão. Isso facilita, por exemplo, retornar facilmente no tempo para recuperar um código perdido, ou testar se antigamente determinado erro já ocorria.

Árvore do projeto

Imagine como é plantar uma árvore.

Você escolhe um bom local, prepara o terreno, coloca adubo, e enfim coloca a semente.

Você tapa o buraco e dá uma simples regada. Você para e olha para a terra molhada no chão, vislumbrando no futuro como aquela árvore crescerá e se encherá de ramos, galhos e frutos.

Passa um tempo e, depois de muito trabalho, o tronco começa a crescer. Você fica maravilhado em como ela é jovem porém já tão robusta. Robusta e flexível.

E de repente, de forma muito rápida, os galhos começam a nascer e crescer. Se ramificam cada vez mais, e você precisa de mais pessoas para te ajudar a cuidar da árvore. Cada um cuida de uma parte, mas todos contribuem para o crescimento daquele corpo que está se formando.

As tempestades começam a aparecer e chacoalham os galhos, deixando-os confusos e desordenados. Parece que tudo vai ruir, mas ela aguenta firme, e o sol aparece de novo.

Então você para, e olha de novo para ela. Observa a tonalidade marcante que ela adquiriu. Orgulhoso de sua e de tua grandiosidade, respira fundo e pensa em todo o trabalho duro que ogirinou todos aqueles galhos.

Claro que os galhos dessa árvore que você plantou são meio doidos. Porque eles sempre acabam se juntando ao tronco de novo depois de um tempo, uns juntam com outros, ou até mesmo o tronco acaba se juntando com um determinado galho.

Claro, essa é a árvore do seu projeto. Me perdoem pela historinha, mas eu quis poetizar um pouco para mostrar como o Git trata cada elemento de um projeto, pensando nos detalhes e tornando tudo muito natural para você.

Se você sabe como é uma árvore, tudo será simples para você.

Árvore do projeto de verdade

Bom, o Git mantém um repositório do projeto que guarda toda essa árvore de alterações. E primeiramente, tudo isso funciona de maneira local, na sua máquina.

commit

Cada alteração ou um conjunto de é salvo no repositório através do conhecido comando git commit. Commit é algo como enviar, entregar, executar.

E cada commit deve possuir uma mensagem auto-explicativa dizendo o que foi alterado, como

• “novo layout para os posts”
• “melhorando organização do css”
• “consertando bug de imagem em mobile”

Aos poucos, vai se formando o tronco do seu projeto.

Mas na prática, como é feito?

Suponha que você tenha alterado vários arquivos em duas pastas totalmente diferentes do seu projeto, e você quer criar um commit apenas com as alterações de uma pasta, e depois da outra, para manter as coisas organizadas.

add

Então, o Git tem um estágio antes do commit, que é o add. O, também famoso, comando git add, adiciona os arquivos desejados em uma espécie de repositório temporário, que o Git chama de index, ou índice.

O fluxo seria mais ou menos assim:

• git add caminho/para/arquivo.txt
• git commit -m "comentario explicativo"

O commit então manda todos os arquivos adicionados no index para o repositório.

status

Um comando muito também útil e usado é o deixa eu adivinhar, famoso? famoso comando git status. Na imagem você pode ver que verde é o que está adicionado e pronto para o commit. O que está em vermelho é um arquivo que foi alterado, alteração que pode facilmente ser desfeita com o um pouco menos famoso comando git checkout caminho/para/arquivo.txt.

branch

Imagine agora que você está em um time de desenvolvedores e decide implementar uma nova funcionalidade no projeto. Naturalmente você alterará vários arquivos e fará vários commits. Durante esse tempo, outras pessoas da equipe também estão commitando e fazendo alterações. Virará tudo uma bagunça, certo?

E se seu chefe fazer algo que chefes nunca fazem, que é voltar a trás e pedir pra desfazer o que você já fez? Terá que ir olhando commit por commit, para identificar qual é relacionado, e depois fazer alguma mágica para sumir com eles do tronco.

Para isso existe o branch, ou, em mineirês, o gái.

Basta criar um branch novo git branch branch_novo, mudar para esse branch git checkout branch_novo e meter o pau. Você também pode unir os dois comandos fazendo git checkout -b branch_novo.

push

Por fim entra a nuvem, ou remote, um repositório online no qual nosso repositório local está associado.

De que adianta ter todo esse controle sozinho e não poder compartilhar com outras pessoas? Afinal, essa é uma das grandes felicidades da vida, não? Compartilhar momentos.

E posts também, aproveita pra compartilhar com os amigos se está gostando do texto:

Há várias formas de ter uma repositório Git online e uma delas é no GitHub. Aliás esse é um ponto que confunde muitas pessoas, a diferença entre Git e GitHub não, não são a mesma coisa, fique tranquilo que vou explicar mais no final.

Ao clonar um repositório, com o comando git clone http://url-qualquer.com/caminho/qualquer.git/, é criado uma pasta no seu computador com o projeto Git automaticamente já linkado com esse repositório online.

Porém, você pode iniciar um projeto no seu computador e depois adicionar o repo online, com o comando git remote add branch http://outra-url.com/outro/caminho.git/.

Em posse de um repositório online que emoção, surgem dois super conhecidos cansei de falar famoso comandos: git pull e git push.

Enquanto o primeiro é para atualizar seu repositório local com o remoto, o segundo faz o contrário. Pega todos os seus commits e manda para o remoto. Obviamente que esses novos commits irão para a ~ponta do tronco, por isso seu repositório deve estar sempre atualizado em relação ao remoto, antes de performar um push.

Para relembrar

O fluxo normal e mais comum fica assim:

• git add --all o sufixo –all adiciona todos os arquivos que sofreram alteração
• git commit -m "no comments" você também pode usar git commit -am "add and commit together!" que não precisará da etapa anterior
• git pull só para garantir que estamos atualizados antes de ~pushar.
• git push voilà.

Simples, bonito, rápido e fácil, não achou? Se concorda e gostou, garanto que os próximos post vão ter conteúdos melhores ainda. Pra garantir que você não vai ficar sem receber, sinta-se à vontade de se inscrever na lista de email. Juro que não mando spam nenhunzinho mesmo.

Agora que estamos todos alinhados, que tal ver um pouco de magia comandos legais?

comandos ~mágicos

Imagine como é plantar uma árvore de cereja.

Bricadeira hehe, não vou começar outra história romântica sobre como plantas crescem. Mas é interessante observar o nome do comando.

Imagine que cada commit seja uma saborosa bolinhas vermelha, como uma cereja.

Como cherry pick significa, literalmente, escolher cerejas, na nossa metáfora isso se torna escolher commits. A expressão, portanto, mostra que o que o comando faz: escolher um commit e colocar em outro lugar.

Olhe essa bonitinha árvore de cerejas para entender:

Imagine que cada commit seja identificado por uma letra na verdade é por um SHA, e que seu último commit foi o H. Isto é, você está no branch de cima.

Se você deseja pegar as alterações feitas no commit E a aplicar no seu branch atual, basta executer git cherry-pick E, que a árvore ficará assim:

It´s a kind of magic …

merge e rebase

Merge é tão simples que nem imagem vai ter, vai na lata mesmo: enquanto git branch abre um novo ramo a partir de onde você está, o git merge pega todas essas alterações e aplica de novo em outro branch, criando uma espécie de um novo commit, porém mantendo o histórico do outro branch intacto.

Deu pra entender?

Ta bom, vai uma imagem aí:

Essa imagem eu peguei desse link aqui. Ele explica tão bem, mas tão bem como é o rebase e sua relação com o merge, que vou deixar a explicação a cargo dele. Mas você promete que volta pra terminar de ler meu post? Tá no finalzinho e ainda tem coisa legal!

squash

Esse também é fácil. squash é esmagar, achatar, e serve para juntar vários commits em apenas um.

Mas porque eu iria querer fazer isso? Você me pergunta.

Sei lá cara, o projeto é seu, você que decide o que quer fazer com ele. Eu te respondo ♥

stash

Esse também é legal, ele pega as alterações que você fez nos arquivos aqueles que estão vermelho no git status, e coloca em um mundo paralelo totalmente desconectado da árvore do seu projeto.

Mas porque eu iria querer fazer isso? Você me pergunta.

Agora eu sei te responder!

Imagine que você acabou de terminar uma nova feature do projeto em um branch, e acabou de criar outro para começar outra feature. Ai você começa a fazer as alterações, mas percebe que precisa de consertar algo errado na feature anterior. Se você simplesmente fizer git checkout primeiro_branch, as alterações permanecem nos arquivos o vermelhinho do git status continua igual, algo que você não quer, você quer deixar as alterações no segundo branch.

Você pode commitar as alterações antes de dar o checkout, mas você não quer poluir seu projeto com um commit antes da hora.

Ou você pode fazer isso e fazer um squash depois e reescrever o commit anterior.

Que confusão!

Tá bom, é mais fácil colocar essas alterações no mundo paralelo com git stash, mudar de branch, fazer o que quiser fazer, voltar pro outro branch, e pegar tudo de novo com git stash apply.

Tão simples quanto colher cerejas!

GitHub

Talvez nesse ponto você já tenha ideia é só eu que acho estranho escrever ideia sem acento? de algumas diferenças. O GitHub seria mais ou menos um cloud service para o Git.

Porém, o Git não engloba um GitHub, e nem vice-versa, ambos são mais ou menos independentes.

Além do Git, o GitHub tem:

• o Pages, para hospedar páginas estáticas e gratuitas, com a possibilidade de usar domínios próprios, tudo de graça. Tem um post legal de um blog legal que ensina a fazer isso com Jekyll.

• Tem também o Gist, para compartilhar e discutir trechos simples de código de forma rápida.

• E tem o incrível pacote para estudantes, que, ao comprovar que é estudante, você ganha várias coisas de graça, como planos em ferramentas pagas, editores de texto pago, e até 5 repositórios privados no GitHub.

Eu sei, o post ficou grande. Mas isso não é uma boa coisa?

Se achou ruim, para te compensar eu vou parar de enrolar e acabar o post aqui mesmo, abruptamente.

tchau.