Se você está iniciando agora nos estudos e/ou carreira de desenvolvimento de software, provavelmente já deve ter criado seu GitHub e iniciando o versionamento dos seus projetos usando o Git, certo?

Se a resposta é "Ainda não 😔", fique tranquila! Aqui tem um tutorialzinho básico pra criar seu primeiro repositório no GitHub, versionar seu projeto e subir ele pro novo repositório, criando sua vitrine para expor seus projetos e estudos sobre programação.

Agora, se a resposta é "Claro! Já estou apanhando do Git!", você está no lugar certo!

Hoje, esse tutorial tem por objetivo falar um pouco sobre um dos comandos mais básicos do Git, o git add, porém abordando uma variante que vai te surpreender: o parâmetro "-p".

O comando "git add" é muito famoso por "adicionar conteúdo" (propor uma mudança qualquer, seja ela alterar, adicionar ou remover um conteúdo) de um arquivo local ao índice ou staging area, que terá a mudança confirmada, posteriormente, com o comando "git commit", e finalmente enviada ao repositório remoto pelo "git push".

Então, resumindo bem rasamente, esse conjunto de comandos, iniciado pelo git add, são os responsáveis por "salvar" nossas alterações no projeto:

1. Fiz uma alteração local em um ou mais arquivos
2. Vou propor essa mudança, com o comando git add, adicionando ela no índice(staging area).
3. Confirmo que quero realizar essa mudança com git commit, fazendo uma "captura/instantâneo" daquele estado do projeto, incluindo as mudanças propostas pelo git add.
4. Envio com git push esse "instantâneo" do meu repositório local para o repositório remoto.

Bom, mas o foco desse artigo é te dizer para que serve o tal do -p junto com o git add, então vamos ao que interessa!

Para introduzir o assunto, quero confessar que passei seis meses trabalhando como desenvolvedora e vários outros meses apenas estudando e sempre utilizava o git add da seguinte forma:

git add . que adicionava todos os arquivos/diretórios alterados (criados, modificados, deletados) à proposição de mudança do index.
git add meu_arquivo.java que adicionava apenas arquivos ou diretórios especificados por mim

E um belo dia, pareando com um colega de time, vi que ele utilizava o git add -p e que dessa forma conseguia, posteriormente, "organizar" melhor seus commits em etapas, agrupando alterações que tinham relação uma com as outras, o que no fim das contas produzia uma Pull Request muito mais fácil de analisar, mesmo que contivesse muitas alterações.

O parâmetro -p passado após o comando git add, é de "patch" ou "fragmento" em português, e permite que você selecione interativamente os "pedaços" que deseja adicionar ao índice e revise as diferenças antes de adicionar essas alterações.

Dessa forma, é possível adicionar aos poucos, agrupando para o commit, as alterações relacionadas e que façam sentido estar no mesmo commit.

A cada fragmento de alteração exibido (com as diferenças), é possível realizar algumas ações, dentre as quais, estão as que considero mais úteis, listadas abaixo:

• y - adicione este pedaço de alteração
• n - não adicione
• d - não adicione este, nem os remanescentes do arquivo
• a - adicione este e os outros pedaços restantes do arquivo
• q - interrompe a adição, mantendo o que já foi adicionado

Na imagem seguinte temos os arquivos modificados em minha branch. Quero apenas adicionar os pedaços do arquivo TotalizerController.java, observando as diferenças que realizei.

Ao rodar o comando git add -p temos o seguinte:

1. Na primeira linha vemos o comando git diff e o nome do arquivo que está sendo "comparado" naquele momento.
2. Em verde, vemos a linha que foi adicionada neste arquivo. Se fosse uma linha removida, veríamos ela em vermelho.
3. E por último, vemos as opções disponíveis que foram citadas acima.

No vídeo abaixo, demonstro como ignorar algumas alterações (utilizando a opção - n) para que não entrem no commit específico que quero fazer de alterações no controller. Dessa forma, vou adicionar (com a opção y) apenas os pedaços que tenham ligação com essa alteração, e em seguida, interromper a adição (com a opção q) quando já tiver colocado no index os pedaços que quero commitar.

Viu como pode ser fácil organizar em commits distintos, agrupando as alterações de forma lógica, mesmo que tenhamos feito muitas mudanças?