Like A Girl

Pushing the conversation on gender equality.

Code Like A Girl

Comandos do Git que você deveria usar

Você descobre e se embrenha nesse mundo de programação, e tudo é maravilhoso. Lógica, estruturas, laços… Começa a desenvolver seus primeiros projetos sozinha e tudo corre muito bem! Mais na frente, aprende padrões de projeto, qualidade, e quem sabe um pouco sobre requisitos. Até que você se depara com seu primeiro projeto em time. E junto com ele você percebe que precisa de mais um skill, o de conhecer um Sistema de Controle de Versão — (quase) um outro mundo pra saber. Nesse artigo vamos abordar o Git.

No início vai push -f no master sem nem ao menos atualizar a árvore local e o projeto pode até quebrar inteiro por uma, duas, três vezes… “O que eu estou fazendo?”, “Por que preciso aprender isso?”. Você às vezes reluta e parece que o Git só atrapalha o seu trabalho.

Depois de alguns meses fritando o cérebro com ele, você começa a tomar gosto pelo uso da ferramenta. Você sabe clonar e criar seu próprio repositório, faz seus commits, usa seus add, push e pull direitinho. Success! Mas de onde saíram estes, existem muitos mais. Comandos que fazem toda a diferença na sua rotina de trabalho depois que você os aprende, pois economizam tempo e deixam sua árvore super limpa e bonita. Vou contar algumas situações corriqueiras ou mais estranhas que já passei e que podem acontecer com você também, descrevendo como funciona o comando que me ajudou.

Sherlock Holmes de Bug

Para começar a caçada por uma inconsistência que está quebrando seu projeto
Agora eu marquei um commit no qual eu sei que a inconsistência não ocorria como bom
Depois é só ir marcando os commits como bad ou good conforme a busca do bisect for ocorrendo, até encontrar o commit que gerou um bug.

Um belo dia tinhamos em mão um bug que ninguém fazia ideia de como tinha sido inserido, e qual parte do código o gerava. Para encontrar o código que o causava, e assim agilizar o processo de correção do bug, nós usamos o git bisect, que faz uma busca binária até encontrar um commit específico — no caso, o que está gerando o problema. Para começar, você executa o git bisect start. A ideia é ir testando a aplicação a cada interação com o git e prosseguir com o git bisect bad (se o problema estiver ocorrendo após o teste) ou git bisect good (se o problema não estiver mais ocorrendo após o teste) enquanto o git se encarrega de “navegar” entre os commits a serem pesquisados até encontrar o commit que quebrou o projeto.

Stalker de arquivo

Resultado do git blame do arquivo web.py

Imagine que você está trabalhando numa Classe e se depara com um trecho de código que você definitivamente não consegue entender. Ou então você quer saber em que contexto uma linha foi inserida e quais outras partes foram modificadas junto com ela no mesmo commit. Pra isso, você usa git blame <caminho_do_arquivo> e o Git te mostra o hash, o nome do autor e a data de cada linha do arquivo. Assim você pode procurar o coleguinha certo pra consultar sobre o trecho, ou usar o hash pra dar um git show <hash_do_commit> e ver todas as modificações do commit que alterou tal linha.

Cherry-pick

O git branch -v mostra o último commit de cada branch que você possui localmente
Dessa forma eu adicionei o último commit do branch bug-fix no branch example

Agora pense sobre o seguinte cenário: você está trabalhando em uma parte específica do sistema, mas uma outra parte do sistema está com um bug crítico que te impede de testar seu trabalho. Enquanto você continuava trabalhando na sua tarefa, outro componente do seu time já corrigiu o bug e você precisa dessa correção para continuar com os seus testes. Uma forma simples e rápida de pegar essa correção do master (se ela já estiver integrada) ou de qualqur outro branch (se ela não tiver sido integrada) e adicioná-la ao seu branch de trabalho sem se preocupar em resolver possíveis conflitos com o master é dando um git cherry-pick <hash_do_commit_da_correcao_do_bug> no seu branch, que funciona como se você pegasse uma pinça, puxasse o commit de um branch e jogasse em outro branch. Acredito que esse comando é mais utilizado quando a correção ou modificação em questão possui apenas um commit.

Guarda pra mais tarde

Possuo um arquivo alterado no branch bug-fix
Agora eu quero usar o rebase mas o Git me adverte que tenho alterações não commitadas e já dá a dica para o nosso próximo passo
Estado após usar o git stash
Agora podemos usar o rebase
E usar o git stash pop para voltar com as alterações anteriores

Vocês não imaginam o medo que eu senti quando descobri esse comando! Sabe aquela sensação lá no fundo dizendo que não vai dar certo?! Mas nas últimas semanas tenho usado muito ele e não me arrependi. Sabe quando você vai dar o rebase mas tem alterações não comitadas que não quer comitar agora mas também não quer perder? É só usar git stash, fazer o que pretendia fazer, e depois dar um git stash pop, que as alterações voltam do jeito que estavam.

Baú do tesouro

Iniciando com rebase iterativo
O comando fica assim
Depois é fácil seguir as instruções que o próprio comando te mostra. Basta substituir o pick, antes do commit, pela ação que você desejar: d para deletar o commit, e para editar e assim por diante. Também é possível trocar os commits de ordem, recortando a linha de um commit e a colando em outra posição entre os demais commits, conforme fizer mais sentido pra você.

Rebase, ah o rebase. Difícil lembrar de um dia de trabalho que eu não o tenha usado nos últimos 6 meses, no mínimo. Ele permite que você faça uma série de alterações em commits. Para utilizá-lo, sua árvore precisa estar limpa (ou seja, você não pode ter arquivos modificados no branch). Você pode usar o rebase em qualquer commit anterior do seu branch. Para começar, encontre o hash do commit anterior ao que você deseja modificar. Aí é só jogar git rebase -i <hash_do_commit_anterior> e ser feliz. Bem vindo ao rebase iterativo. Quase um controle na palma da sua mão *-* Você pode deletar commits, mesclar dois ou mais commits (caso, por exemplo, você tenha feito o mesmo commit duas vezes porque esqueceu que já tinha commitado), pode editar as modificações de qualquer commit (deixando assim cada commit seu mais lindo que o outro, esbanjando qualidade, e sem a necessidade de acrescentar commits de correção da sua própria alteração posteriormente no mesmo branch).

Se tiverem dúvidas sobre os comandos acima, pode escrever nos comentários que eu respondo. Outra dica também é sempre utilizar o git status, pois ele muitas vezes te direciona sobre como prosseguir — como vocês podem ver nas imagens. Caso se interesse em aprender mais sobre esses e outros comandos, você pode encontrar aqui. Se você tiver um comando escondido do Git, que você pensa que só você sabe, mas que facilita muito o trabalho em situações corriqueiras, comenta aqui no post 😉

Agradecimentos ao meu líder técnico André Pedralho por ter — incansavelmente — me passado todos esses ensinamentos.

Siga a tag codelikeagirlBR para ver nossos posts! 😀

Quer escrever ou traduzir artigos em português para a Code Like A Girl? Se você já faz parte do time de escritoras(es) da Code Like A Girl basta enviar seu artigo diretamente para nossa publicação. Se você ainda não faz parte do nosso time, envie uma mensagem direta para a conta de twitter CodeLikeAGirlBr. Nós avaliaremos seu artigo e ajudaremos a refiná-lo para publicação.