Como substituir a filial local por filial remota inteiramente no Git?

Eu tenho dois ramos:

1. filial local (aquela com quem trabalho)
2. filial remota (pública, apenas confirmações bem testadas vão para lá)

Recentemente, eu estraguei seriamente minha filial local.

Como eu substituiria totalmente a filial local pela remota, para poder continuar meu trabalho de onde a filial remota está agora?

Eu já procurei no SO e fazer check-out localmente na filial remota não tem nenhum efeito.

1. Verifique se você verificou o ramo que está substituindo (no comentário de Zoltán ).

2. Supondo que o mestre seja o ramo local que você está substituindo e que "origem / mestre" seja o ramo remoto para o qual você deseja redefinir:

   git reset --hard origin/master
   

Isso atualiza sua ramificação HEAD local para ter a mesma revisão que origem / mestre e --hardsincronizará essa alteração também no índice e na área de trabalho.

Isso é tão fácil quanto três etapas:

1. Exclua sua filial local: git branch -d local_branch
2. Busque a ramificação remota mais recente: git fetch origin remote_branch
3. Reconstrua a filial local com base na remota: git checkout -b local_branch origin/remote_branch

git branch -D <branch-name>
git fetch <remote> <branch-name>
git checkout -b <branch-name> --track <remote>/<branch-name>

Substitua tudo pelo ramo remoto; mas apenas a partir do mesmo commit sua filial local está ativada:

git reset --hard origin/some-branch

OU , obtenha as últimas da filial remota e substitua tudo:

git fetch origin some-branch
git reset --hard FETCH_HEAD

Como um aparte, se necessário, você pode eliminar arquivos e diretórios não rastreados que ainda não foram confirmados:

git clean -fd

A maneira mais segura e completa de substituir a filial local atual pelo controle remoto:

git stash
git merge --abort
git rebase --abort
git branch -M yourBranch replaced_yourBranch
git fetch origin yourBranch:yourBranch
git checkout yourBranch

A stashlinha salva as alterações que você não confirmou. A branchlinha move sua ramificação para um nome diferente, liberando o nome original. A fetchlinha recupera a cópia mais recente do controle remoto. ocheckout linha recria a ramificação original como uma ramificação de rastreamento.

Ou como uma função bash:

replaceWithRemote() {
    yourBranch=${1:-`git rev-parse --abbrev-ref HEAD`}
    git stash
    git merge --abort
    git rebase --abort
    git branch -M ${yourBranch} replaced_${yourBranch}_`git rev-parse --short HEAD`
    git fetch origin ${yourBranch}:${yourBranch}
    git checkout ${yourBranch}
}

que renomeia a ramificação atual para algo como replace_master_98d258f.

Estou meio surpreso que ninguém tenha mencionado isso ainda; Eu uso quase todos os dias:

git reset --hard @{u}

Basicamente, @{u}é apenas uma abreviação para o ramo upstream que seu ramo atual está rastreando. Por exemplo, isso normalmente equivale a origin/[my-current-branch-name]. É legal porque é independente de ramo.

Certifique-se de git fetchprimeiro obter a cópia mais recente da filial remota.

Isso pode ser feito de várias maneiras, continuando a editar essa resposta para espalhar uma melhor perspectiva de conhecimento.

1) Redefinir com força

Se você estiver trabalhando a partir da ramificação de desenvolvimento remoto, poderá redefinir HEAD para a última confirmação na ramificação remota, conforme abaixo:

git reset --hard origin/develop

2) Exclua a ramificação atual e faça o checkout novamente no repositório remoto

Considerando que você está trabalhando no ramo de desenvolvimento no repositório local, que é sincronizado com o ramo remoto / de desenvolvimento, você pode fazer o seguinte:

git branch -D develop
git checkout -b develop origin/develop

3) Interromper mesclagem

Se você estiver no meio de uma mesclagem incorreta (feita erroneamente com ramificação incorreta) e quiser evitar a mesclagem, volte para a ramificação mais recente, como abaixo:

git merge --abort

4) Abortar rebase

Se você estiver entre uma nova recuperação incorreta, poderá anular a solicitação de nova recuperação, conforme abaixo:

git rebase --abort

Você pode fazer o que o @Hugo da @Laurent disse, ou pode usar git rebasepara excluir os commits que deseja se livrar, se souber quais. Eu costumo usar git rebase -i head~N(onde N é um número, permitindo que você manipule os últimos N commit) para esse tipo de operações.

A resposta selecionada está absolutamente correta , no entanto, não me deixou com as últimas commit / pushes ...

Então para mim:

git reset --hard dev/jobmanager-tools
git pull  ( did not work as git was not sure what branch i wanted)

Como sei que quero definir temporariamente minha ramificação upstream por algumas semanas para uma ramificação específica (a mesma que mudei / fiz check-out anteriormente e fiz uma redefinição definitiva)

Então, depois de redefinir

git branch --set-upstream-to=origin/dev/jobmanager-tools
git pull
git status    ( says--> on branch  dev/jobmanager-tools 

Se você deseja atualizar o ramo que não está atualmente com check-out, você pode:

git fetch -f origin rbranch:lbranch

Conforme fornecido na explicação escolhida, o git reset é bom. Hoje em dia, porém, geralmente usamos submódulos: repositórios dentro de repositórios. Por exemplo, se você usa o ZF3 e o jQuery em seu projeto, provavelmente deseja que eles sejam clonados em seus repositórios originais. Nesse caso, o git reset não é suficiente. Precisamos atualizar os submódulos para a versão exata definida em nosso repositório:

git checkout master
git fetch origin master
git reset --hard origin/master
git pull

git submodule foreach git submodule update

git status

é o mesmo que você virá (cd) recursivamente para o diretório de trabalho de cada submódulo e será executado:

git submodule update

E é muito diferente de

git checkout master
git pull

porque os submódulos apontam não para ramificação, mas para a confirmação.

Nesse caso, quando você faz check-out manualmente de uma ramificação para 1 ou mais submódulos, pode executar

git submodule foreach git pull

git reset --hard
git clean -fd

Isso funcionou para mim - o clean também mostrou todos os arquivos excluídos. Se ele indicar que você perderá alterações, precisará ocultar.

A maneira mais feia, porém mais simples: exclua sua pasta local e clone o repositório remoto novamente.