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


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

Я:

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 2641

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).

вопрос смешивает два вопроса здесь:

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

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

  1. git fetch --prune(необязательно) обновляет локальный снимок удаленного РЕПО. Дальнейшие команды являются локальными только.
    git reset --hard @{upstream}помещает указатель локальной ветви туда, где находится снимок удаленного устройства, а также устанавливает индекс и рабочий каталог для файлов этой фиксации.
  2. 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 локальное РЕПО и повторно клонировать его с пульта дистанционного управления.

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

xkcd: Git

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

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

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

git stash
git pull

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

git fetch origin
git reset --hard origin/master