É absolutamente necessário trabalhar com vários bugs de uma só vez? E por "de uma só vez", quero dizer "ter arquivos editados para vários bugs ao mesmo tempo". Porque, a menos que você precise absolutamente disso, eu trabalharia apenas com um bug de cada vez em seu ambiente. Dessa forma, você pode usar ramificações e rebase locais, o que acho muito mais fácil do que gerenciar um stash / estágio complexo.
Digamos que o mestre esteja no commit B. Agora trabalhe no bug # 1.
git checkout -b bug1
Agora você está no ramo bug1. Faça algumas alterações, confirme, aguarde a revisão do código. Como é local, você não está afetando ninguém, e deve ser fácil fazer um patch a partir do git diffs.
A-B < master
\
C < bug1
Agora você está trabalhando no bug2. Ir para trás a principal com git checkout master
. Faça um novo ramo git checkout -b bug2
. Faça alterações, confirme, aguarde a revisão do código.
D < bug2
/
A-B < master
\
C < bug1
Vamos fingir que alguém comete E & F no mestre enquanto você está aguardando a revisão.
D < bug2
/
A-B-E-F < master
\
C < bug1
Quando seu código for aprovado, você poderá refazê-lo novamente para dominar com as seguintes etapas:
git checkout bug1
git rebase master
git checkout master
git merge bug1
Isso resultará no seguinte:
D < bug2
/
A-B-E-F-C' < master, bug1
Em seguida, você pode pressionar, excluir seu ramo bug1 local e pronto. Um bug de cada vez no seu espaço de trabalho, mas com o uso de ramificações locais, seu repositório pode lidar com vários bugs. E isso evita uma dança de palco / stash complicada.
Responda à pergunta de ctote nos comentários:
Bem, você pode voltar ao esconderijo para cada bug e trabalhar apenas com um bug por vez. Pelo menos, você economiza o problema de preparação. Mas, tendo tentado isso, acho pessoalmente problemático. Os stashes são um pouco confusos em um gráfico de log do git. E o mais importante, se você estragar alguma coisa, não pode reverter. Se você tem um diretório de trabalho sujo e abre um stash, não pode "desfazer" esse pop. É muito mais difícil estragar confirmações já existentes.
Então git rebase -i
.
Ao refazer uma ramificação para outra, você pode fazer isso de maneira interativa (o sinalizador -i). Ao fazer isso, você tem a opção de escolher o que deseja fazer com cada confirmação. O Pro Git é um livro incrível, que também está online no formato HTML e tem uma boa seção sobre rebasing e squash:
http://git-scm.com/book/ch6-4.html
Vou roubar seu exemplo literalmente por conveniência. Finja que você tem o seguinte histórico de consolidação e deseja rebase e squash bug1 no master:
F < bug2
/
A-B-G-H < master
\
C-D-E < bug1
Aqui está o que você verá quando digitar git rebase -i master bug1
pick f7f3f6d changed my name a bit
pick 310154e updated README formatting and added blame
pick a5f4a0d added cat-file
#
# Commands:
# p, pick = use commit
# e, edit = use commit, but stop for amending
# s, squash = use commit, but meld into previous commit
#
# If you remove a line here THAT COMMIT WILL BE LOST.
# However, if you remove everything, the rebase will be aborted.
#
Para compactar todas as confirmações de uma ramificação em uma única confirmação, mantenha a primeira confirmação como "pick" e substitua todas as entradas "pick" subsequentes por "squash" ou simplesmente "s". Você também terá a oportunidade de alterar a mensagem de confirmação.
pick f7f3f6d changed my name a bit
s 310154e updated README formatting and added blame
s a5f4a0d added cat-file
#
# Commands:
# p, pick = use commit
# e, edit = use commit, but stop for amending
# s, squash = use commit, but meld into previous commit
Então, sim, esmagar é um pouco doloroso, mas eu ainda o recomendaria sobre o uso pesado de esconderijos.