Как сбросить локальную ветвь на удаленный? [Дубликат]

Если у вас была проблема, как у меня, что вы уже внесли некоторые изменения, но теперь по какой-либо причине вы хотите избавиться от нее, самый быстрый способ - использовать git reset следующим образом:

git reset --hard HEAD~2

У меня было 2 не необходимых фиксации, следовательно, число 2. Вы можете изменить его на свой собственный номер фиксации для сброса.

Так что отвечая на ваш вопрос - если вы на 5 коммитов впереди удаленный репозиторий HEAD, вы должны запустить эту команду:

git reset --hard HEAD~5

Обратите внимание, что вы потеряете сделанные вами изменения, поэтому будьте осторожны!

Мне нужно было сделать (решение в принятом ответе):

git fetch origin
git reset --hard origin/master

Далее следуют:

git clean -f

для удаления локальных файлов

Чтобы посмотреть, какие файлы будут удалены (без их удаления):

git clean -n -f

использовать reset --soft origin /, это вернет исходную головку и даст вам возможность работать с изменениями. они могут быть отброшены или

Все вышеперечисленные предложения правы, но часто, чтобы действительно сбросить ваш проект, вам также нужно удалить даже файлы, которые находятся в вашем .gitignore.

Чтобы получить моральный эквивалент стирания вашего каталога проекта и повторного клонирования с удаленного:

git fetch
git reset --hard
git clean -x -d -f

Предупреждение: git clean -x -d -f является необратимым , и вы можете потерять файлы и данные (например, которые вы проигнорировали с помощью .gitignore).

Предыдущие ответы предполагают, что ветвь, подлежащая сбросу, является текущей ветвью (выведено). В комментариях OP hap497 пояснил, что ветвь действительно проверена, но это явно не требуется исходным вопросом. Поскольку существует хотя бы один «повторяющийся» вопрос, Полностью отбросить ветвь до состояния репозитория , который не предполагает, что ветвь проверена, вот альтернатива:

Если ветка " mybranch "в настоящий момент не проверяется, чтобы сбросить его на удаленную ветвь« myremote / mybranch », вы можете использовать эту команду low-level :

git update-ref refs/heads/mybranch myremote/mybranch

метод оставляет извлеченную ветвь такой, какой она есть, а рабочее дерево - нетронутым. Он просто перемещает голову mybranch в другую фиксацию, независимо от того, что указано в качестве второго аргумента. Это особенно полезно, если несколько ветвей необходимо обновить до новых удаленных головок.

Будьте осторожны при выполнении этого, и используйте gitk или аналогичный инструмент, чтобы дважды проверить источник и место назначения. Если вы случайно сделаете это в текущей ветке (и git не сможет удержать вас от этого), вы можете запутаться, потому что новое содержимое ветви не соответствует рабочему дереву, которое не изменилось (чтобы исправить, обновить ветвь снова, где он был раньше).

Если удаленный репозиторий origin и вас интересует branch_name:

git fetch origin
git reset --hard origin/<branch_name>

Кроме того, вы переходите для сброса текущей ветви origin на HEAD.

git fetch origin
git reset --hard origin/HEAD

Как это работает:

git fetch origin загружает последние данные с удаленного устройства, не пытаясь слить или переустановить что-либо.

Затем git reset сбрасывает ветвь <branch_name> на то, что вы только что выбрали. Параметр --hard изменяет все файлы в рабочем дереве, чтобы они соответствовали файлам в origin/branch_name.

Если вы хотите вернуться в состояние HEAD как для рабочего каталога, так и для индекса, вы должны git reset --hard HEAD, а не HEAD^. (Возможно, это была опечатка, так же как одиночная и двойная тире для --hard.)

Что касается вашего конкретного вопроса о том, почему эти файлы отображаются в статусе как измененный, это выглядит, сделал мягкий сброс вместо жесткого сброса. Это приведет к тому, что файлы, которые были изменены в HEAD commit, появятся так, как если бы они были поставлены, что, вероятно, означает, что вы видите здесь.

Если вы хотите сбросить свою локальную ветвь до последней фиксации в ветке вверх, то для меня работает до сих пор:

Проверьте свои пульты, убедитесь, что ваш восходящий поток и источник - это то, что вы ожидаете, если не так, как ожидалось, используйте git remote add upstream <insert URL>, например из оригинального репо GitHub, из которого вы были откопаны, и / или 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;

Или:

git fetch upstream master;
git reset --hard upstream/master;
git clean -d --force;

В GitHub вы также можете проверить ветку с помощью то же имя, что и местное, чтобы сохранить там работу, хотя это необязательно, если происхождение разработки имеет те же изменения, что и локальная ветвь с сохраненной работой. Я использую ветвь разработки в качестве примера, но это может быть любое существующее имя ветки.

git add .
git commit -m "Reset to upstream/develop"
git push --force origin develop

Тогда, если вам нужно объединить эти изменения с другой веткой, где есть конфликты, сохраняя изменения в разработке, использовании:

git merge -s recursive -X theirs develop

Во время использования

git merge -s recursive -X ours develop

сохранить конфликтующие изменения ветви_имя. В противном случае используйте mergetool с git mergetool.

Со всеми изменениями вместе:

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;

Обратите внимание, что вместо upstream / develop вы можете использовать хеш-фиксацию, другое имя ветки, и т. д. Используйте инструмент CLI, такой как Oh My Zsh, чтобы проверить, что ваша ветка зеленая, указывает, что ничего не зафиксировано, и рабочий каталог является чистым (что подтверждено или также проверено git status). Обратите внимание, что это может фактически добавить фиксации по сравнению с восходящим потоком, если есть что-либо, автоматически добавленное фиксацией, например. UML-диаграммы, заголовки лицензий и т. Д., Поэтому в этом случае вы могли бы потянуть изменения на origin develop на upstream develop, если это необходимо.

Если вы не возражаете сохранить свои локальные изменения, но все же хотите обновить свой репозиторий в соответствии с начальником / HEAD, вы можете просто скопировать ваши локальные изменения, а затем потянуть:

git stash
git pull

Никакое количество сброса и очистки, похоже, не повлияло на невоспроизводимые и измененные файлы в моем локальном репозитории git (я пробовал все варианты выше). Моим единственным решением для этого было rm локальное репо и повторное клонирование его с удаленного.

К счастью, у меня не было никаких других ветвей, о которых я заботился.

xkcd: Git

git reset --hard HEAD фактически только сбрасывается до последнего зафиксированного состояния. В этом случае HEAD ссылается на HEAD вашего филиала.

Если у вас несколько коммитов, это не сработает.

То, что вы, вероятно, захотите сделать, сбрасывается в голову источника или что бы вы ни называли удаленным репозиторием. Я бы, вероятно, просто сделал что-то вроде

git reset --hard origin/HEAD

Будьте осторожны. Жесткие списания не могут быть легко отменены. Лучше делать то, что предлагает Дэн, и отбрасывать копию ваших изменений перед сбросом.

В этом вопросе смешиваются два вопроса:

1. , как сбросить локальную ветвь до точки, где удаленный
2. , как очистить зону промежуточной (и, возможно, рабочий каталог), так что git status говорит nothing to commit, working directory clean.

. Один-стоп-ответ:

1. git fetch --prune (необязательно) Обновляет локальный снимок удаленного репо. Дальнейшие команды являются только локальными. git reset --hard @{upstream} Помещает указатель локальной ветви, где находится моментальный снимок удаленного, а также задает индекс и рабочий каталог файлам этого коммита.
2. git clean -d --force Удаляет неподготовленные файлы и каталоги, которые [gg]

Если вы хотите, чтобы текущие изменения были использованы позже, тогда спрячьте изменения другим, вы можете использовать эти две команды,

git fetch origin
git reset --hard origin/master

Единственное решение, которое работает во всех случаях, которые я видел, - это удаление и повторное использование. Может быть, есть и другой способ, но, очевидно, этот путь не оставляет шансов на то, что старое государство останется там, поэтому я предпочитаю это. Bash one-liner вы можете установить как макрос, если вы часто испортите вещи в git:

REPO_PATH=$(pwd) && GIT_URL=$(git config --get remote.origin.url) && cd .. && rm -rf $REPO_PATH && git clone --recursive $GIT_URL $REPO_PATH && cd $REPO_PATH

* предполагает, что ваши .git-файлы не повреждены

Я сделал:

git branch -D master
git checkout master

, чтобы полностью сбросить ветвь

note, вы должны проверить на другую ветку, чтобы удалить нужную ветку

Это то, с чем я сталкиваюсь регулярно, & amp; Я обобщил приведенный выше сценарий Вольфганг для работы с любой ветвью

. Я также добавил приглашение «вы уверены», & amp; выход обратной связи

#!/bin/bash
# reset the current repository
# WF 2012-10-15
# AT 2012-11-09
# see http://stackoverflow.com/questions/1628088/how-to-reset-my-local-repository-to-be-just-like-the-remote-repository-head
timestamp=`date "+%Y-%m-%d-%H_%M_%S"`
branchname=`git rev-parse --symbolic-full-name --abbrev-ref HEAD`
read -p "Reset branch $branchname to origin (y/n)? "
[ "$REPLY" != "y" ] || 
echo "about to auto-commit any changes"
git commit -a -m "auto commit at $timestamp"
if [ $? -eq 0 ]
then
  echo "Creating backup auto-save branch: auto-save-$branchname-at-$timestamp"
  git branch "auto-save-$branchname-at-$timestamp" 
fi
echo "now resetting to origin/$branchname"
git fetch origin
git reset --hard origin/$branchname