Сбросьте локальную ветвь репозитория, чтобы быть похожим на удаленную головку репозитория
как сбросить локальную ветвь, чтобы она была такой же, как ветвь в удаленном репозитории?
Я:
git reset --hard HEAD
но когда я запускаю git status
,
On branch master
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)
modified: java/com/mycompany/TestContacts.java
modified: java/com/mycompany/TestParser.java
не могли бы вы сказать мне, почему у меня есть эти "модифицированные"? Я не трогал эти файлы? Если бы я это сделал, я хочу удалить их.
19 ответов:
установка вашей ветви точно соответствует удаленной ветви может быть сделано в два этапа:
git fetch origin git reset --hard origin/master
Если вы хотите сохранить состояние вашей текущей ветви, прежде чем делать это (на всякий случай), вы можете сделать:
git commit -a -m "Saving my work, just in case" git branch my-saved-work
теперь ваша работа сохраняется в ветке "my-saved-work", если вы решите, что хотите ее вернуть (или хотите посмотреть на нее позже или отличить ее от обновленной ветки).
обратите внимание, что в первом примере предполагается, что имя удаленного РЕПО - "origin" и что ветвь с именем "master" в удаленном РЕПО соответствует текущей извлеченной ветви в вашем локальном РЕПО.
кстати, эта ситуация, в которой вы находитесь, очень похожа на обычный случай, когда толчок был сделан в текущую извлеченную ветвь не-голого репозитория. Вы недавно вошли в свое местное РЕПО? Если нет, то не беспокойтесь-что-то еще должно было привести к тому, что эти файлы неожиданно будут изменены. В противном случае, вы должны знать, что это не рекомендуется чтобы протолкнуть в не-голый репозиторий (а не в текущую извлеченную ветвь, в частности).
мне нужно было сделать (решение в принятом ответе):
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
фактически сбрасывается только до последнего зафиксированного состояния. В этом случае руководитель относится к руководителю вашего филиала.Если у вас есть несколько коммитов, это не сработает..
то, что вы, вероятно, хотите сделать, сбрасывается в голову происхождения или то, что вы удаленный репозиторий называется. Я бы, наверное, просто сделал что-то вроде
git reset --hard origin/HEAD
будьте осторожны. Жесткие сбросы не могут быть легко отменены. Лучше сделать так, как предлагает Дэн, и разветвить копию вашего изменения перед сбросом.
все вышеперечисленное говорит о том, что они правы, но часто действительно сбросьте свой проект, вам также нужно удалить даже файлы, которые находятся в вашем
.gitignore
.чтобы получить моральный эквивалент удаление каталога проекта и повторное клонирование с пульта дистанционного управления:
git fetch git reset --hard git clean -x -d -f
предупреждение:
git clean -x -d -f
и необратимые и вы можете потерять файлы и данные (например, вещи, которые вы проигнорировали с помощью.gitignore
).
вопрос смешивает два вопроса здесь:
- как сбросить локальную ветку до точки, где находится пульт
- как очистить промежуточную область (и, возможно, рабочий каталог), так что
git status
говоритnothing to commit, working directory clean.
один-стоп-ответ:
git fetch --prune
(необязательно) обновляет локальный снимок удаленного РЕПО. Дальнейшие команды являются локальными только.git reset --hard @{upstream}
помещает указатель локальной ветви туда, где находится снимок удаленного устройства, а также устанавливает индекс и рабочий каталог для файлов этой фиксации.git clean -d --force
удаляет неотслеженные файлы и каталоги, которые мешают git сказать "рабочий каталог чистый".
Это то, с чем я сталкиваюсь регулярно, и я обобщил сценарий Wolfgang, представленный выше, для работы с любой веткой
Я также добавил приглашение "вы уверены", и некоторые выходные данные обратной связи
#!/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>
ответвление к тому, что вы только что принесли. Элемент--hard
опция изменяет все файлы в ваше рабочее дерево соответствует файлам вorigin/branch_name
.
вот скрипт, который автоматизирует то, что самый популярный ответ напрашивается ... См.https://stackoverflow.com/a/13308579/1497139 для улучшенной версии, которая поддерживает ветви
#!/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
чтобы полностью сбросить филиала
Примечание, Вы должны проверить в другую ветку, чтобы иметь возможность удалить необходимую ветку
Если у вас была проблема, как я, что вы уже совершили некоторые изменения, но теперь, по какой-либо причине вы хотите избавиться от него, самый быстрый способ-использовать
git reset
такой:git reset --hard HEAD~2
у меня было 2 не нужны коммиты, следовательно, число 2. Вы можете изменить его на свое собственное количество коммитов для сброса.
Итак, отвечая на ваш вопрос - если вы на 5 коммитов опережаете удаленную голову репозитория, вы должны запустить эту команду:
git reset --hard HEAD~5
обратите внимание, что вы потеряете изменения, которые вы сделали, так что будьте осторожны!
если вы хотите вернуться к
HEAD
состояние для рабочего каталога и индекса, то вы должныgit reset --hard HEAD
, а неHEAD^
. (Это, возможно, была опечатка, так же, как одиночный и двойной тире для--hard
.)Что касается вашего конкретного вопроса о том, почему эти файлы отображаются в статусе "изменено", похоже, что вы сделали мягкий сброс вместо жесткого сброса. Это вызовет файлы, которые были изменены в
HEAD
фиксация, чтобы выглядеть так, как если бы они были инсценированы, что, вероятно, то, что вы видите здесь.
предыдущие ответы предполагают, что ветвь, которая будет сброшена, является текущей ветвью (извлечена). В комментариях, ОП hap497 уточнил, что ветка действительно проверена, но это явно не требуется в исходном вопросе. Так как есть хотя бы один "дубликат" вопроса, полностью сбросить ветку в состояние репозитория, который не предполагает, что ветка проверена, вот альтернатива:
если ветка "mybranch" составляет не в настоящее время проверено, чтобы сбросить его в удаленную ветку"myremote/mybranch", вы можете использовать это низкий уровень:
git update-ref refs/heads/mybranch myremote/mybranch
этот метод оставляет извлеченную ветвь как есть, а рабочее дерево нетронутым. Он просто перемещает голову mybranch к другому фиксации, что бы ни было дано в качестве второго аргумента. Это особенно полезно, если необходимо обновить несколько ветвей до новых удаленных головок.
будьте осторожны при этом, хотя, и использовать
gitk
или аналогичный инструмент для двойной проверки источника и назначения. Если вы случайно сделаете это на текущей ветке (и git не удержит вас от этого), вы можете запутаться, потому что новое содержимое ветки не соответствует рабочему дереву, которое не изменилось (чтобы исправить, обновите ветку снова, где она была раньше).
никакое количество сброса и очистки, казалось, не повлияло на неотслеженные и измененные файлы в моем локальном репозитории git (я пробовал все варианты выше). Мое единственное решение для этого состояло в том, чтобы rm локальное РЕПО и повторно клонировать его с пульта дистанционного управления.
к счастью, у меня не было других ветвей, о которых я заботился.
единственное решение, которое работает во всех случаях, которые я видел, это удалить и повторно клонировать. Может быть, есть другой способ, но очевидно, что этот способ не оставляет шансов на то, что старое государство останется там, поэтому я предпочитаю его. 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 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 вы также можете проверить ветку с тем же именем, что и локальная, чтобы сохранить работу там, хотя это не обязательно, если origin develop имеет те же изменения, что и локальная ветвь сохраненной работы. Я использую ветвь разработки в качестве примера, но это может быть любое существующее имя ветви.
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/develop вы можете использовать хэш фиксации, другое имя ветви и т. д. Используйте инструмент CLI, такой как Oh My Zsh, чтобы проверить, что ваша ветвь зеленая, указывая, что нет ничего для фиксации, а рабочий каталог чист (что подтверждается или также проверяется
git status
). Обратите внимание, что это может фактически добавить коммиты по сравнению с восходящей разработкой, если есть что-то автоматически добавленное a фиксация, например, UML-диаграмм, заголовков лицензий и т. д., так что в этом случае, вы можете затем вытащить изменения наorigin develop
доupstream develop
, если это необходимо.
использовать сброс --мягкое происхождение/ это приведет к возврату к исходной головке и даст вам возможность работать с изменениями. они могут быть отброшены или