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

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

git fetch origin
git reset --hard origin/master

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

git clean -f

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

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

git clean -n -f

Сначала вернемся к ранее извлеченному HEAD соответствующей ветки восходящего направления:

git reset --hard @{u}

Преимущество указания @{u} или его подробной формы @{upstream} заключается в том, что имя удаленного репо и ветки не нужно указывать явно.

Затем, при необходимости, удалите неотслеживаемые файлы, при необходимости также с помощью -x:

git clean -df

Наконец, по мере необходимости, получите последние изменения:

git pull

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

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

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

git reset --hard origin/HEAD

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

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

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

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

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

Вопрос содержит два вопроса:

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

Одностановочный ответ:

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

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

Я также добавил приглашение "вы уверены", и какой-то результат обратной связи

#!/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

При условии, что удаленный репозиторий 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> к тому, что вы только что <branch_name>. Опция --hard изменяет все файлы в вашем рабочем дереве в соответствии с файлами в origin/branch_name.

Вот script, который автоматизирует то, что предлагает самый популярный ответ... См. https://stackoverflow.com/questions/1628088/reset-local-repository-branch-to-be-just-like-remote-repository-head для улучшенной версии, поддерживающей ветки

#!/bin/bash
# reset the current repository
# WF 2012-10-15
# see https://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"`
git commit -a -m "auto commit at $timestamp"
if [ $? -eq 0 ]
then
  git branch "auto-save-at-$timestamp" 
fi
git fetch origin
git reset --hard origin/master

Я сделал:

git branch -D master
git checkout master

полностью reset ветвь

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

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

git reset --hard HEAD~2

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

Итак, отвечая на ваш вопрос: если вы заработали 5 бит перед удаленным хранилищем HEAD, вы должны запустить эту команду:

git reset --hard HEAD~5

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

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

Если ветвь "mybranch" в настоящий момент проверена не, до reset на удаленной ветке "myremote/mybranch", вы можете использовать эту команда низкого уровня:

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

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

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

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

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

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

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

xkcd: Git

Это то, что я использовал регулярно:

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

Обратите внимание, что хорошей практикой является не вносить изменения в свой локальный мастер, а вместо этого извлекать изменения в другую ветвь для любого изменения с именем ветки, которому предшествует тип изменения, например, feat/, chore/, fix/ и т.д. Таким образом, вы только нужно вытягивать изменения, а не выдвигать какие-либо изменения у мастера То же самое для других отраслей, которым способствуют другие. Таким образом, вышеприведенное следует использовать только в том случае, если вы зафиксировали изменения в ветке, в которую зафиксированы другие, и вам необходимо выполнить сброс. В противном случае в будущем избегайте нажатия на ветку, к которой другие подталкивают, вместо этого извлекайте и передавайте в указанную ветку через извлеченную ветку.

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

Проверьте свои пульты, убедитесь, что ваш исходящий и исходный код соответствуют вашим ожиданиям, если не так, как ожидалось, используйте 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

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

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

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

Единственное решение, которое работает во всех случаях, которые я видел, - это удаление и повторное использование. Может быть, есть другой путь, но, очевидно, этот путь не оставляет шансов остаться прежним государством, поэтому я предпочитаю это. Bash один лайнер вы можете установить как макрос, если вы часто испортите вещи в 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 файлы не повреждены

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

git stash
git pull

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

git fetch origin
git reset --hard origin/master