Как reset моя локальная ветвь будет похожа на ветку в удаленном репозитории?
Я сделал:
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
Не могли бы вы рассказать мне, почему у меня эти "измененные"? Я не касался этих файлов? Если бы я это сделал, я хочу удалить их.
Настройка ветки точно в соответствии с удаленной ветвью может быть выполнена в два этапа:
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" в случае, если вы решите, что хотите ее вернуть (или хотите посмотреть на нее позже или отнести ее к обновленной ветке).
Обратите внимание, что в первом примере предполагается, что имя удаленного репо является "источником" и что ветвь с именем "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 фактически только сбрасывается до последнего зафиксированного состояния. В этом случае 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).
Вопрос содержит два вопроса:
git status говорит nothing to commit, working directory clean.Одностановочный ответ:
git fetch --prune (необязательно) Обновляет локальный снимок удаленного репо. Другие команды только локальные.git reset --hard @{upstream} Помещает указатель локальной ветки, где находится моментальный снимок удаленного, а также задает индекс и рабочий каталог файлам этого коммита.git clean -d --force Удаляет ненужные файлы и каталоги, которые мешают git сказать "рабочий каталог чистым".Используйте команды ниже. Эти команды также удалят все неотслеживаемые файлы из локального git
git fetch origin
git reset --hard origin/master
git clean -d -f
Это то, с чем я сталкиваюсь регулярно, и я обобщил приведенный выше 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, который автоматизирует то, что предлагает самый популярный ответ... См. fooobar.com/questions/477/... для улучшенной версии, поддерживающей ветки
#!/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
Обратите внимание, что вы потеряете сделанные вами изменения, поэтому будьте осторожны!
Предыдущие ответы предполагают, что ветвь, которая будет сброшена, является текущей веткой (проверено). В комментариях OP hap497 пояснил, что ветка действительно проверена, но это не требуется явно в исходном вопросе. Поскольку существует хотя бы один "повторяющийся" вопрос, полностью сбросить ветвь до состояния хранилища, что не предполагает, что ветвь извлечена, вот альтернатива:
Если ветвь "mybranch" в настоящее время не извлечена, чтобы вернуть ее в заголовок удаленной ветки "myremote/mybranch", вы можете использовать эту команду низкого уровня :
git update-ref refs/heads/mybranch myremote/mybranch
Этот метод оставляет извлеченную ветвь такой, какая она есть, и рабочее дерево нетронутым. Он просто перемещает голову моего ветки в другой коммит, независимо от того, что указано в качестве второго аргумента. Это особенно полезно, если необходимо обновить несколько веток до новых удаленных голов.
При этом соблюдайте осторожность и используйте gitk или аналогичный инструмент для двойной проверки источника и назначения. Если вы случайно сделаете это в текущей ветке (и 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
чтобы сохранить конфликтующие изменения имя_в ветки. В противном случае используйте 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.
Если вы хотите вернуться в состояние HEAD как для рабочего каталога, так и для индекса, вы должны git reset --hard HEAD, а не HEAD^. (Возможно, это была опечатка, точно так же, как одиночная или двойная тире для --hard.)
Что касается вашего конкретного вопроса о том, почему эти файлы отображаются в статусе как измененном, похоже, что вы сделали мягкий reset вместо жесткого reset. Это приведет к тому, что файлы, которые были изменены в объявлении HEAD, будут отображаться так, как если бы они были поставлены, что, скорее всего, вы видите здесь.
Похоже, что никакое количество сброса и очистки не повлияло на неотслеживаемые и измененные файлы в моем локальном git-репо (я перепробовал все варианты выше). Мое единственное решение этого состояло в том, чтобы восстановить локальное хранилище и повторно клонировать его с удаленного компьютера.
К счастью, у меня не было других ветвей, о которых я заботился.
Единственное решение, которое работает во всех случаях, которые я видел, - это удаление и повторное использование. Может быть, есть другой путь, но, очевидно, этот путь не оставляет шансов остаться прежним государством, поэтому я предпочитаю это. 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 файлы не повреждены
Вы забыли создать функциональную ветвь и по ошибке совершили прямой переход на мастер?
Теперь вы можете создать ветвь компонента и установить master обратно, не затрагивая рабочее дерево (локальную файловую систему), чтобы избежать запуска сборок, тестов и проблем с блокировками файлов:
git checkout -b feature-branch
git branch -f master origin/master
Если вы не против сохранения локальных изменений, но все же хотите обновить свой репозиторий, чтобы он совпал с origin/HEAD, вы можете просто скопировать свои локальные изменения, а затем потянуть:
git stash
git pull
Если вы хотите, чтобы текущие изменения были использованы позже, тогда спрячьте изменения, другие мудрые вы можете использовать эти две команды,
git fetch origin
git reset --hard origin/master