5 comandos git que parecem mágica

O programa git suporta tantos subcomandos que é quase impossível manter o controle de todos eles. A maioria deles é de nível bastante baixo e executa tarefas simples, como confirmar alterações de código ou mudar de branch. Mas alguns dos mais obscuros oferecem funcionalidades surpreendentes que vão muito além do normal.

git culpa: descubra quem mudou o quê

Pessoalmente, acho que git culpa poderia ter um nome mais positivo: git credit, talvez? De qualquer forma, independentemente de como você escolher usá-lo, este comando lhe dirá exatamente quem é responsável por cada linha de código em um arquivo:

O que você verá por padrão são todas as linhas do seu arquivo, prefixadas com detalhes do último commit que o alterou. Esses detalhes incluem o ID do commit, a data e hora desse commit e o autor que fez a alteração.

Se você estiver trabalhando em um projeto maior com muitos colaboradores, esta pode ser uma forma valiosa de acompanhar alterações específicas no código. Você pode usá-lo para descobrir por que alguém os criou ou consultar sobre uma possível atualização.

A culpa também é um recurso compatível com o GitHub: navegue até qualquer arquivo individual e você verá uma guia “Culpa” ao lado do padrão, “Código:”

Observe que o GitHub codifica com cores os commits por idade para que você possa digitalizar rapidamente a lista e encontrar alterações recentes.

arquivo git: pacote de qualquer ponto da história

Trabalhar com um projeto Git normalmente envolve clonar repositórios, verificar ramificações e confirmar alterações. Mas, às vezes, você quer trabalhar apenas com os arquivos do projeto: quando você está executando uma demonstração ou realizando testes casuais, por exemplo.

O comando git archive fornece uma coleção limpa de arquivos de projeto, sem nada relacionado ao Git, em qualquer ponto de commit em seu repositório:

git archive HEAD

Este comando exibe o conteúdo de todos os arquivos na ramificação atual, no formato tar. Você provavelmente desejará salvar essa saída e há duas maneiras de fazer isso. Você pode usar o redirecionamento de arquivo shell para enviar a saída para um arquivo:

git archive HEAD > project.tar

Alternativamente, você pode usar a opção –output para enviar a saída para um arquivo nomeado:

git archive --output=project.tar HEAD

A principal vantagem dessa abordagem é que o Git selecionará de forma inteligente o formato com base no nome do seu arquivo. Por padrão, a saída será no formato tar, mas suporta outros, como .tar.gz e zip:

git archive --output=project.zip 428d235

Lembre-se de especificar o commit desejado usando um ponteiro como HEAD, um ID de tag ou um ID de commit. Você pode até passar um subdiretório para arquivar apenas parte do seu projeto:

git archive --output=project.tar.gz v1.1 docs

Em certo sentido, o comando git archive é antimágico: ele remove todos os dados mágicos do Git do seu repositório, convertendo-os em um conjunto simples de arquivos. Mas criar um arquivo instantâneo do seu projeto a partir de qualquer ponto de toda a sua história é um truque muito especial para mim.

git stash: salve as alterações sem confirmá-las

Várias vezes me deparei com esta situação: você está ocupado trabalhando em uma filial, então algo mais precisa de atenção. Talvez seja um recurso que precise de ajustes ou uma ramificação que exija uma correção rápida de bug. Você salvou seus arquivos, mas mudar de ramificação agora removerá essas alterações.

Quando eu não sabia nada melhor, normalmente verificava minhas alterações, na esperança de limpar o histórico de commits mais tarde (e provavelmente falhando). Mas isso exige muito trabalho administrativo e deixa o repositório confuso, mesmo que apenas por um breve período. Mas agora eu sei sobre o git stash:

Depois de executar o git stash, você terá uma árvore de trabalho limpa, para poder trocar de ramificação com segurança e trabalhar em outra coisa. Quando estiver pronto para retornar, você poderá restaurar seus arquivos:

git stash pop

Como num passe de mágica, seus arquivos estão de volta, com todas as alterações feitas prontas para serem registradas. O nome deste comando reflete a natureza baseada em pilha do stash. Se você precisar fazer o stash várias vezes, suas alterações serão salvas em uma pilha, então o stash mais recente será retornado quando você solicitar um.

git grep: pesquise sua base de código entre filiais

O subcomando git grep pesquisa arquivos e imprime linhas que correspondem a um padrão. Isso pode não parecer muito impressionante à primeira vista; afinal, não é exatamente isso que o grep faz? A parte mágica é quão bem o Git integra esse grep alternativo.

Por padrão, git grep pesquisa em todos os arquivos rastreados em sua árvore de trabalho. Esta é a principal diferença entre o comando grep padrão e a versão Git: grep pesquisa arquivos, enquanto git grep pesquisa o conteúdo dos arquivos que foram confirmados em seu repositório.

Por padrão, git grep pesquisa a versão atual do repositório em sua árvore de trabalho. Mas você também pode pesquisar o conteúdo de outras ramificações ou do repositório em um commit específico:

git grep TODO 4415c19

Sem o git grep, você teria que verificar a revisão específica antes do grep e levar em conta arquivos ignorados, arquivos não rastreados e recursão. Você pode até pesquisar várias revisões, incluindo todo o histórico do seu repositório, se estiver com coragem:

git grep strcat $(git rev-list --all)

git worktree: trabalhe no mesmo repositório mais de uma vez

Se você achou que git stash era bom, aqui está algo ainda melhor: git worktree. Embora o stashing seja bom para trabalhos de curto prazo, pode ser complicado se você estiver trabalhando em arquivos por um período mais longo ou em vários ramos diferentes ao mesmo tempo.

O recurso worktree fornece uma maneira mais permanente de trabalhar em diversas ramificações simultaneamente. Isso é feito fornecendo a você uma pasta de trabalho extra: ou seja, outra coleção de arquivos do repositório.

Assim como acontece com a maioria dos recursos do Git, você pode adaptar as árvores de trabalho para se adequarem ao seu processo, mas aqui está um exemplo simples de como começar:

git worktree add 

Em um repositório existente, use o subcomando worktree para criar um novo diretório anexado a uma ramificação específica. A última parte do seu caminho será usada para o nome do branch, que pode ser um branch existente:

Quaisquer ramificações retiradas em árvores de trabalho vinculadas serão destacadas em ciano e marcadas com um sinal de mais:

Você pode então trabalhar em cada diretório, em ramificações específicas, sem precisar alternar entre elas, o que torna as árvores de trabalho perfeitas para multitarefas.