Isso geralmente acontece comigo: escrevo um código, vou verificar minhas alterações e depois percebo que não estou no ramo apropriado para verificar essas alterações. No entanto, não posso mudar para outro ramo sem que minhas alterações sejam revertidas. Existe uma maneira de mover as alterações para outro ramo a ser verificado lá?
Respostas:
git stash é seu amigo.
Se você ainda não fez o commit, basta executar git stash. Isso salvará todas as suas alterações.
Alterne para o ramo em que deseja que as alterações sejam executadas git stash pop.
Existem muitos usos para o git stash. Esta é certamente uma das razões mais úteis.
Um exemplo:
# work on some code
git stash
git checkout correct-branch
git stash pop
C:\kf [develop +0 ~4 -0]> git checkout feature/customers<br/> error: Your local changes to the following files would be overwritten by checkout:<br/> AspWebApp.vNext/global.asa<br/> RestApi/Web.config<br/> Please, commit your changes or stash them before you can switch branches.<br/> Aborting
Se você ainda não confirmou suas alterações , use-o git checkoutpara ir para o novo ramo e depois enviá-las normalmente - as alterações nos arquivos não estão vinculadas a um ramo específico até que você as confirme.
Se você tiver já se comprometeu suas alterações:
git loge lembre-se do SHA do commit que você deseja mover.git cherry-pick SHAsubstituindo o SHA de cima.git reset HEAD~1para redefinir novamente antes de confirmar o ramo errado.cherry-pick pega uma confirmação e aplica-a ao cabeçalho com saída atualmente permitida, permitindo copiar a confirmação para uma nova ramificação.
git reset HEAD~N --softe depois git checkout -bmover todo o código não confirmado agora para um novo ramo.
Infelizmente isso acontece comigo com bastante regularidade e eu uso git stashse percebi meu erro antes git commite usogit cherry-pick , caso contrário, os dois comandos são explicados muito bem em outras respostas
Desejo adicionar um esclarecimento para git checkout targetBranch: este comando preservará apenas o diretório de trabalho e o instantâneo em etapas se targetBranch tiver o mesmo histórico que sua ramificação atual
Se você ainda não confirmou suas alterações, use o git checkout para ir para a nova ramificação e depois confirme-as normalmente
@ A declaração de Amber não é falsa quando você passa para um newBranch , git checkout -b newBranchum novo ponteiro é criado e está apontando exatamente para o mesmo commit que o seu ramo atual.
De fato, se você tiver uma outra ramificação que compartilhe o histórico com sua ramificação atual (ambas apontam para o mesmo commit), você pode "mover suas alterações"git checkout targetBranch
No entanto, geralmente ramificações diferentes significam histórico diferente, e o Git não permitirá que você alterne entre essas ramificações com um diretório de trabalho ou área de preparação suja. nesse caso, você pode fazer git checkout -f targetBranch(alterações limpas e descartáveis) ou git stage+ git checkout targetBranch(limpar e salvar alterações); simplesmente executar git checkout targetBranchgera um erro:
erro: suas alterações locais nos seguintes arquivos seriam substituídas pelo checkout: ... Confirme suas alterações ou as esconda antes de mudar de ramificação. Interrompendo
Uma redefinição suave do git colocará as alterações confirmadas novamente no seu índice. Em seguida, faça o checkout do ramo em que você pretendia se comprometer. Em seguida, git commit com uma nova mensagem de commit.
git reset --soft <commit>
git checkout <branch>
git commit -m "Commit message goes here"
Dos documentos do git :
git reset [<mode>] [<commit>]Esse formulário redefine o cabeçalho de ramificação atual e possivelmente atualiza o índice (redefinindo-o para a árvore de) e a árvore de trabalho, dependendo. Se omitido, o padrão é --mixed. Deve ser um dos seguintes:
--softNão toca no arquivo de índice nem na árvore de trabalho (mas redefine o cabeçalho para, como todos os modos). Isso deixa todos os seus arquivos alterados "Alterações a serem confirmadas", como o status do git colocaria.