Como lidar com isso quando um commit em andamento de repente parece depender de outro que ainda não existe?

Sou inexperiente com o Git, mas tento o meu melhor para me acostumar com isso, e até agora estou usando apenas para projetos em que trabalho sozinho.

Quando eu codifico, existe alguma abordagem de cima para baixo naturalmente (como não sei o futuro), e há um tema recorrente:

Eu trabalho um pouco.
Descobri que, para colocar meu trabalho em algo "comprometível", preciso fazer outro trabalho.
O outro trabalho merece seu próprio commit.

Por algo comprometível, quero dizer algo que compila ou algo que não é uma bagunça total.
E por algo que merece seu próprio commit, estou me referindo ao que aprendi que os commits devem fazer apenas uma coisa.

O jeito que eu resolvo isso é complicado. Se o outro trabalho estiver em outro arquivo, eu faço uma nova ramificação, confirmo lá e mesclo. Se o trabalho estiver no mesmo arquivo .. ugh .. Eu faço uma cópia local e redefino o arquivo para o estado em HEAD, faça a confirmação necessária e, em seguida, começo a restaurar meu trabalho a partir da cópia. Como devo lidar com isso? Não imagino que seja esse o caminho, é? Suponho que não, porque deve aparecer com certa frequência para todos (que também não conhecem o futuro). Ou talvez pareça que meu fluxo de trabalho provavelmente tenha falhas?

Existem várias maneiras de resolver isso.

Se você quiser fazer as alterações para a primeira confirmação sem interferir nas alterações atuais, convém usar git stash. Isso descartará todas as alterações abertas, permitindo que você as restaure mais tarde. Use git statuspara ver que eles não estão mais presentes. Agora crie a primeira confirmação como você está acostumado. Em seguida, você pode usar git stash poppara restaurar suas alterações originais e criar a segunda confirmação, executando seu trabalho principal.

Outra maneira seria fazer todas as alterações necessárias e criar dois commits, ambos contendo uma parte do seu trabalho. Para fazer isso, você pode usar o índice (também conhecido como área de preparação) fornecido pelo git. Essa é uma área especial que você pode usar para preparar confirmações. Supondo que você alterou vários arquivos, você pode adicionar cada um deles ao índice usando git add. Ao fazer, git commitapenas os arquivos adicionados ao índice serão confirmados. git statusmostrará quais partes de suas alterações serão confirmadas e quais não serão. Por exemplo, ele ficará assim depois de alterar os arquivos a.txt, b.txt e c.txt e depois fazer git add a.txt:

On branch master
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

        modified:   a.txt

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

        modified:   b.txt
        modified:   c.txt

Quando você estiver git commitnesse estado, apenas as alterações em a.txt serão adicionadas ao seu commit.

Além disso, você pode revisar as mudanças exatas a serem confirmadas usando git diff --cached, que mostrarão uma comparação de todas as alterações que serão confirmadas.

Se um arquivo contiver alterações para as duas confirmações, você também poderá adicionar apenas partes dele ao índice usando "git add --patch b.txt". O git fornecerá a você um modo interativo que solicita cada alteração no arquivo fornecido, se ele deve ser adicionado ao índice. Isso pode ficar mais difícil se houver alterações nas linhas próximas umas das outras, que precisam ser divididas nas duas confirmações, no entanto, existem maneiras de resolver isso também.

Se você quiser saber mais sobre a área de preparação, leia isto: http://gitready.com/beginner/2009/01/18/the-staging-area.html

Você também pode querer ler mais sobre a adição interativa aqui: http://nuclearsquid.com/writings/git-add/

Se você usa uma GUI para o Git, como o SourceTree da Atlassian, ou git guipode comprometer partes dos arquivos e deixar outras partes descomprometidas. De fato, você pode confirmar linhas de código individuais.

Faço isso com frequência quando caio em tocas de coelho como você descreve. Essa é uma ótima maneira de tornar esse commit sensato ou comprometido como precursor do commit principal.

Você pode fazer isso na linha de comando, mas é meio desajeitado.

Quando você pode confirmar no nível do patch do Git e em linhas individuais, não é necessário criar novas ramificações, stash, commit, stash e mesclagem. Continue trabalhando e não interrompa o fluxo. Você tem uma coisa boa acontecendo.