Посмотрите на документацию здесь , что вы хотите:
intent.setClassName("com.x.y", "className");
Настройка вашей ветви точно в соответствии с удаленной веткой может быть выполнена в два этапа:
git fetch origin
git reset --hard origin/master
Если вы хотите сохранить состояние текущего филиала, прежде чем делать это (на всякий случай), вы можете сделать :
git commit -a -m "Saving my work, just in case"
git branch my-saved-work
Теперь ваша работа сохраняется на ветке «моя сохраненная работа», если вы решите, что хотите ее вернуть (или хотите посмотреть на нее позже или разделить ее с обновленной веткой) .
Обратите внимание, что в первом примере предполагается, что имя удаленного репо «origin» и что ветвь с именем «master» в удаленном репо совпадает с текущей выпиской в вашем локальном репо.
Кстати, эта ситуация, в которой вы находитесь, выглядит очень странно, как обычный случай, когда в текущую проверочную ветвь не-годового репозитория делается толкание. Вы недавно натолкнулись на свое местное репо? Если нет, то не беспокойтесь - что-то еще должно было заставить эти файлы неожиданно в конечном итоге изменить. В противном случае вы должны знать, что не рекомендуется вставлять в не-голый репозиторий (а не в текущую отмеченную ветвь, в частности).
Если у вас была проблема, как у меня, что вы уже внесли некоторые изменения, но теперь по какой-либо причине вы хотите избавиться от нее, самый быстрый способ - использовать git reset
следующим образом:
git reset --hard HEAD~2
У меня было 2 не необходимых фиксации, следовательно, число 2. Вы можете изменить его на свой собственный номер фиксации для сброса.
Так что отвечая на ваш вопрос - если вы на 5 коммитов впереди удаленный репозиторий HEAD, вы должны запустить эту команду:
git reset --hard HEAD~5
Обратите внимание, что вы потеряете сделанные вами изменения, поэтому будьте осторожны!
origin/master
– Jon z
22 September 2015 в 15:10
Мне нужно было сделать (решение в принятом ответе):
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 локальное репо и повторное клонирование его с удаленного.
К счастью, у меня не было никаких других ветвей, о которых я заботился.
git reset --hard HEAD
фактически только сбрасывается до последнего зафиксированного состояния. В этом случае HEAD ссылается на HEAD вашего филиала.
Если у вас несколько коммитов, это не сработает.
То, что вы, вероятно, захотите сделать, сбрасывается в голову источника или что бы вы ни называли удаленным репозиторием. Я бы, вероятно, просто сделал что-то вроде
git reset --hard origin/HEAD
Будьте осторожны. Жесткие списания не могут быть легко отменены. Лучше делать то, что предлагает Дэн, и отбрасывать копию ваших изменений перед сбросом.
В этом вопросе смешиваются два вопроса:
git status
говорит nothing to commit, working directory clean.
. Один-стоп-ответ:
git fetch --prune
(необязательно) Обновляет локальный снимок удаленного репо. Дальнейшие команды являются только локальными. git reset --hard @{upstream}
Помещает указатель локальной ветви, где находится моментальный снимок удаленного, а также задает индекс и рабочий каталог файлам этого коммита. git clean -d --force
Удаляет неподготовленные файлы и каталоги, которые [gg] @{upstream}
требует установки восходящего потока, который будет выполняться по умолчанию, если вы git checkout <branchname>
. - В противном случае замените его на origin/<branchname>
.
– Robert Siemer
31 January 2016 в 02:31
-x
в git clean
, чтобы удалить все, что не происходит в фиксации (т. Е. Даже файлы игнорируются с помощью механизма .gitignore).
– Robert Siemer
31 January 2016 в 02:34
Если вы хотите, чтобы текущие изменения были использованы позже, тогда спрячьте изменения другим, вы можете использовать эти две команды,
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
git reset FETCH_HEAD --hard
, а также, это то же самое. – Jean 30 April 2013 в 22:21