Você está trabalhando alegre e feliz em algo e encontra as alterações nesses arquivos em boas condições. Você não deseja vê-los quando executar o comando git diff, porque planeja trabalhar em outros arquivos e as alterações nesses arquivos são uma distração.

Alguém pede para você fazer um pull, e as mudanças parecem dignas de serem mescladas.

No entanto, você já sujou o índice (ou seja, o seu índice não corresponde ao commit HEAD). Mas você sabe que o pull que você fará não afeta o arquivo frotz.c ou o arquivo filfre.c, portanto, você reverte as alterações no índice destes dois arquivos. As suas alterações na árvore de trabalho permanecem lá.

Então você pode fazer o pull e mesclar deixando as alterações nos arquivo frotz.c e` filfre.c` ainda na árvore de trabalho.

Isso geralmente é feito quando você se lembra que o commit que acabou de fazer está incorreto ou errou algo na sua mensagem do commit, ou ambos. Deixa a árvore de trabalho como estava antes de "redefinir".

Faça as correções nos arquivos da árvore de trabalho.

"reset" copia o cabeçalho antigo para .git/ORIG_HEAD; refaça o commit iniciando com sua a mensagem de registro log. Caso você não precise editar mais a mensagem, em vez disso poderá usar a opção -C.

Você fez alguns commits, mas percebe que eles eram prematuros para estar no ramo master. Você deseja continuar dando polimento neles em uma ramificação de tópico, portanto, crie a ramificação topic/wip fora do HEAD atual.

Rebobine o ramo principal para se livrar destes três commits.

Mude para o ramo topic/wip e continue trabalhando.

Os últimos três commits (HEAD, HEAD^ e`HEAD~2`) foram ruins e você não deseja mais vê-los novamente. Não faça isso caso já tenha repassado estes commits para outra pessoa. (Para saber mais sobre as implicações desta ação, consulte a seção "RECUPERANDO DO UPSTREAM REBASE" no git-rebase[1].)

Tente atualizar a partir do upstream responsável pelos diversos conflitos; você não estava pronto para perder muito tempo mesclando agora, então decide fazer isso mais tarde.

O "pull" não fez a consolidação de mesclagem, portanto, git reset --hard, que é um sinônimo de git reset --hard HEAD, limpa a bagunça do arquivo do índice e da árvore de trabalho.

Mescle uma ramificação de tópico na ramificação atual, o que resultou em um avanço rápido.

Mas você decidiu que o ramo de tópicos ainda não está pronto para consumo público. O "pull" ou "merge" sempre deixa o cume original do ramo atual em ORIG_HEAD, portanto, a redefinição forçada traz o seu arquivo do índice e a árvore de trabalho de volta para esta condição e redefine o cume do ramo para este commit.

Mesmo que você tenha modificações locais em sua árvore de trabalho, você pode usar com segurança git pull quando souber que a alteração no outro ramo não se sobrepõe a elas.

Após inspecionar o resultado da mesclagem, você pode achar que a alteração na outra ramificação não é satisfatória. Se executar o git reset --hard ORIG_HEAD permitirá que você volte para onde estava, mas descartará as alterações locais que você não quer. O git reset --merge mantém suas alterações locais.

Este commit será desfeito de modo que o descarte de uma mensagem de registro log seja OK.

Isso remove o commit WIP do histórico e define a sua árvore de trabalho para a condição anterior antes de você fazer este instantâneo.

Neste ponto o arquivo do índice ainda possui todas as alterações do WIP que você fez o commit como instantâneo WIP. Isso faz a atualização do índice para demonstrar que os seus arquivos WIP estão inalterados.

Isso remove o arquivo do índice enquanto o mantém no diretório de trabalho.

Isso faz o commit de todas as outras modificações no índice.

Adiciona o arquivo ao índice novamente.

Isso faz o commit das suas primeiras edições em branch1.

Em um mundo ideal você poderia ter percebido que o commit anterior não pertencia ao novo tópico quando você criou e alternou para o "branch2" (i.e. "switch -c branch2 start"), mas ninguém é perfeito.

Porém é possível´ usar a opção reset --keep para remover o commit indesejado depois de alternar para branch2.

Primeiro, faz o reset do histórico um commit para trás para que possamos remover o commit original, porém, deixe a árvore de trabalho com todas as alterações. O -N garante que quaisquer novos arquivos adicionados com HEAD, ainda sejam marcados para que o git add -p os encontre.

Em seguida, selecionamos interativamente os blocos das diferenças para serem adicionas utilizando o recurso git add -p. Isso lhe perguntará sobre cada pedaço diff em sequência, assim você poderá usar de comandos simples como "yes, include this" (sim, inclua isso), "no don’t include this" (não, não inclua isso) ou mesmo o poderoso recurso "edit" (editar).

Uma vez satisfeito com os blocos que deseja incluir, você deve verificar o que foi preparado para o primeiro commit utilizando a opção git diff --cached. Isso exibe todas as alterações que foram movidas para o índice e que estão prontas para o commit.

Em seguida, faça o commit das alterações armazenadas no índice. A opção -c especifica para ser feito o preenchimento prévio da mensagem original do commit iniciado com o primeiro commit. É útil para evitar ter que digitá-la novamente. O HEAD@{1} é uma notação especial para o commit onde o HEAD estava antes da redefinição (reset) do commit original (1 alteração atrás). Para mais detalhes consulte git-reflog[1]. Você também pode utilizar qualquer outro commit válido como referência.

Você pode repetir os passos 2-4 diversas vezes para quebrar o código original em diversos commits.

Agora que você dividiu diversas alterações em seus próprios commits e pode não mais usar o modo patch do git add, para que possa selecionar todas os commits restantes que não foram alterados.

Novamente, verifique se você incluiu o que deseja. Você também deve verificar se o git diff não exibe nenhuma outra alteração restante nos commits que serão realizados depois.

E finalmente, crie o commit final.