Como Verificar se um Arquivo Está Staged no Git

Introdução

Neste laboratório, você aprenderá como verificar se um arquivo foi staged no Git. Exploraremos o comando git status para ver o estado do seu repositório e identificar arquivos staged. Em seguida, você usará git diff --cached para verificar as alterações específicas que estão atualmente na área de staging, fornecendo uma visão clara do que será incluído no seu próximo commit. Finalmente, você testará com arquivos não staged para solidificar ainda mais sua compreensão do processo de staging.

Verificar o status do Git para arquivos Staged

Nesta etapa, verificaremos o status do nosso repositório Git após adicionar um arquivo à área de staging. Isso nos ajudará a entender como o Git rastreia as alterações antes que elas sejam commitadas.

Primeiro, certifique-se de estar no seu diretório my-time-machine. Você pode usar o comando cd para navegar até lá:

cd ~/project/my-time-machine

Agora, vamos criar um novo arquivo chamado future_plans.txt e adicionar algum conteúdo a ele:

echo "Plan 1: Build a bigger time machine" > future_plans.txt

Este comando cria o arquivo e escreve o texto "Plan 1: Build a bigger time machine" nele.

Em seguida, adicionaremos este novo arquivo à área de staging usando o comando git add:

git add future_plans.txt

Lembre-se, git add stageia as alterações, preparando-as para o próximo commit. Ele ainda não cria o commit em si.

Agora, vamos verificar o status do nosso repositório usando git status:

git status

Você deve ver uma saída semelhante a esta:

On branch master
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
        new file:   future_plans.txt

Untracked files:
  (use "git add <file>..." to include in what will be committed)
        message.txt ## This file is already committed, but Git status shows it differently after a commit. Don't worry about this for now.

Observe a seção "Changes to be committed:". Isso indica que future_plans.txt agora está na área de staging, pronto para ser incluído no próximo commit. O Git o reconhece como um "new file" (novo arquivo).

Entender a área de staging é crucial no Git. Ela permite que você agrupe alterações relacionadas antes de fazer um commit. Isso significa que você pode trabalhar em várias coisas, mas apenas commitar alterações específicas quando elas estiverem prontas.

Use git diff --cached para Verificar

Nesta etapa, aprenderemos como ver as alterações que estão atualmente na área de staging. É aqui que o comando git diff se torna útil, especificamente com a opção --cached.

Certifique-se de ainda estar no diretório ~/project/my-time-machine.

Anteriormente, adicionamos future_plans.txt à área de staging. Agora, vamos usar git diff --cached para ver exatamente quais alterações estão staged:

git diff --cached

Você deve ver uma saída semelhante a esta:

diff --git a/future_plans.txt b/future_plans.txt
new file mode 100644
index 0000000..a1b2c3d
--- /dev/null
+++ b/future_plans.txt
@@ -0,0 +1 @@
+Plan 1: Build a bigger time machine

Vamos analisar esta saída:

• diff --git a/future_plans.txt b/future_plans.txt: Esta linha indica que o Git está mostrando a diferença entre duas versões do arquivo future_plans.txt.
• new file mode 100644: Isso mostra que future_plans.txt é um novo arquivo.
• index 0000000..a1b2c3d: Estes são identificadores internos do Git para o conteúdo do arquivo.
• --- /dev/null e +++ b/future_plans.txt: Estas linhas indicam que o arquivo está sendo comparado de nada (/dev/null) para a nova versão de future_plans.txt.
• @@ -0,0 +1 @@: Este é um "hunk header" (cabeçalho de bloco) indicando as linhas que foram alteradas. -0,0 significa zero linhas do arquivo original (inexistente), e +1 significa uma linha no novo arquivo.
• +Plan 1: Build a bigger time machine: O sinal + no início da linha indica que esta linha foi adicionada.

O comando git diff --cached mostra a diferença entre a área de staging e o último commit. Como ainda não fizemos nenhum commit neste repositório (exceto o inicial no laboratório anterior), ele mostra a diferença entre a área de staging e um estado vazio.

Este comando é incrivelmente útil para revisar suas alterações staged antes de commitá-las. Ele ajuda você a garantir que está commitando apenas as alterações que pretende.

Pressione q para sair da visualização de diff e retornar à linha de comando.

Testar Arquivos Unstaged

Nesta etapa, exploraremos como o Git lida com as alterações que foram feitas em um arquivo rastreado, mas que ainda não foram adicionadas à área de staging. Essas são chamadas de alterações "unstaged" (não staged).

Certifique-se de estar no diretório ~/project/my-time-machine.

Anteriormente, criamos e stageamos future_plans.txt. Agora, vamos adicionar outra linha a este arquivo sem stagear a alteração:

echo "Plan 2: Invent a self-folding laundry machine" >> future_plans.txt

O operador >> anexa o texto ao arquivo existente, em vez de sobrescrevê-lo.

Agora, vamos verificar o status do nosso repositório novamente:

git status

Você deve ver uma saída semelhante a esta:

On branch master
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
        new file:   future_plans.txt

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
        modified:   future_plans.txt

Untracked files:
  (use "git add <file>..." to include in what will be committed)
        message.txt

Observe a nova seção: "Changes not staged for commit:". Isso nos diz que o Git vê alterações em future_plans.txt que são diferentes da versão na área de staging. O arquivo é listado como "modified" (modificado).

Este é um conceito chave no Git: o diretório de trabalho (onde você faz as alterações) é separado da área de staging. Você pode ter alterações em seu diretório de trabalho que ainda não foram stageadas.

Para ver a diferença entre o diretório de trabalho e a área de staging, você pode usar git diff sem nenhuma opção:

git diff

Você deve ver uma saída semelhante a esta:

diff --git a/future_plans.txt b/future_plans.txt
index a1b2c3d..e4f5g6h 100644
--- a/future_plans.txt
+++ b/future_plans.txt
@@ -1 +1,2 @@
 Plan 1: Build a bigger time machine
+Plan 2: Invent a self-folding laundry machine

Esta saída mostra a diferença entre a versão de future_plans.txt na área de staging (que só tem "Plan 1") e a versão em seu diretório de trabalho (que agora tem "Plan 1" e "Plan 2"). O sinal + novamente indica a linha adicionada.

Entender a diferença entre alterações staged e unstaged, e como visualizá-las com git status e git diff, é fundamental para usar o Git de forma eficaz.

Pressione q para sair da visualização de diff.

Resumo

Neste laboratório, aprendemos como verificar se um arquivo está staged no Git. Começamos criando um novo arquivo e adicionando-o à área de staging usando git add. Em seguida, usamos git status para observar que o arquivo foi listado em "Changes to be committed" (Alterações a serem commitadas), confirmando que ele estava staged.

Também exploramos o uso de git diff --cached para visualizar as alterações específicas que estão atualmente na área de staging, fornecendo uma visão detalhada do que será incluído no próximo commit. Finalmente, testamos o comportamento de git status com arquivos unstaged para diferenciar entre alterações staged e unstaged.