Isto é o que eu uso frequentemente:
git fetch upstream develop;
git reset --hard upstream/develop;
git clean -d --force;
Note-se que é uma boa prática para não fazer alterações ao seu mestre local / desenvolver ramo, mas em vez de checkout para outro ramo para qualquer mudança, com o nome de filial prefixado pelo tipo de mudança, por exemplo feat/, chore/, fix/, etc. Assim, você só precisa puxe as alterações, não envie nenhuma alteração do mestre. O mesmo vale para outros ramos com os quais outros contribuem. Portanto, o descrito acima só deve ser usado se você confirmar alterações em um ramo em que outros se comprometeram e precisar redefinir. Caso contrário, no futuro, evite enviar para um ramo para o qual outros enviam, em vez disso, faça o checkout e envie para o referido ramo por meio do ramo com check-out.
Se você deseja redefinir sua filial local para a confirmação mais recente na filial upstream, o que funciona para mim até agora é:
Verifique seus controles remotos, verifique se o upstream e a origem são o que você espera, se não como o esperado, use git remote add upstream <insert URL>, por exemplo, o repositório original do GitHub do qual você retirou e / ou git remote add origin <insert URL of the forked GitHub repo>.
git remote --verbose
git checkout develop;
git commit -m "Saving work.";
git branch saved-work;
git fetch upstream develop;
git reset --hard upstream/develop;
git clean -d --force
No GitHub, você também pode fazer checkout da ramificação com o mesmo nome da local, para salvar o trabalho lá, embora isso não seja necessário se o desenvolvimento da origem tiver as mesmas alterações que a ramificação local de trabalho salvo. Estou usando o ramo de desenvolvimento como exemplo, mas pode ser qualquer nome de ramo existente.
git add .
git commit -m "Reset to upstream/develop"
git push --force origin develop
Então, se você precisar mesclar essas alterações com outra ramificação enquanto houver conflitos, preservando as alterações no desenvolvimento, use:
git merge -s recursive -X theirs develop
Enquanto uso
git merge -s recursive -X ours develop
para preservar as alterações conflitantes de branch_name. Caso contrário, use uma ferramenta de fusão com git mergetool.
Com todas as mudanças juntas:
git commit -m "Saving work.";
git branch saved-work;
git checkout develop;
git fetch upstream develop;
git reset --hard upstream/develop;
git clean -d --force;
git add .;
git commit -m "Reset to upstream/develop";
git push --force origin develop;
git checkout branch_name;
git merge develop;
Observe que, em vez de fazer upstream / desenvolvimento, você pode usar um hash de confirmação, outro nome de filial, etc. Use uma ferramenta CLI como Oh My Zsh para verificar se sua ramificação está verde, indicando que não há nada a confirmar e se o diretório de trabalho está limpo ( que é confirmado ou também verificável por git status). Observe que isso pode realmente adicionar commits comparação para montante desenvolver se houver qualquer coisa adicionado automaticamente por um cometa, por exemplo, diagramas UML, cabeçalhos de licença, etc., então, nesse caso, você poderia, então, puxar as mudanças em origin developque upstream develop, se necessário.
git statusseu segundo comandogit reset --hard HEADfalhou. Você não colou sua saída, no entanto. → Pergunta incompleta.