Основная проблема
Я просто удалил ВСЕ код из файла в моем проекте и зафиксировал изменения в моем локальном git (специально). я сделал
git pull upstream master
для извлечения и слияния из восходящего потока (теоретически, удаленный код должен быть возвращен).
Git сообщает мне, что все обновлено.
Все определенно НЕ обновлено - весь удаленный код все равно удаляется.
Другая важная информация
У меня только одна ветка называется "master".
Недавно я установил "master" для отслеживания восходящего потока следующим образом:
Мастер ветки настроен для отслеживания удаленного мастера ветки из восходящего потока.
Команда git branch -vv
дает:
* master 7cfcb29 [upstream/master: ahead 9] deletion test
Почему почему это происходит? Я собираюсь просто послать своему менеджеру проекта по электронной почте любые изменения, которые я внесу в наш код.
Обновить
Я думал, что это очевидно, но в любом случае это моя цель:
Получите самый последний код в моей системе.
Простите меня за гнев, но почему такая простая задача может быть такой сложной?
Ответы:
Я думаю, ваша основная проблема здесь в том, что вы неверно истолковываете и / или не понимаете, что делает git и почему он это делает.
Когда вы клонируете какой-либо другой репозиторий, git делает копию того, что находится «там». Он также берет «свои» метки веток, такие как
master
, и делает копию той метки, чье «полное имя» в вашем дереве git (обычно)remotes/origin/master
(но в вашем случаеremotes/upstream/master
). В большинстве случаев вы можете опустить и этуremotes/
часть, поэтому вы можете ссылаться на эту оригинальную копию какupstream/master
.Если вы сейчас внесете и зафиксируете некоторые изменения в каком-то файле (файлах), вы единственный, кто внесет эти изменения. Тем временем другие люди могут использовать исходный репозиторий (из которого вы создали свой клон) для создания других клонов и изменения этих клонов. Конечно, только они со своими изменениями. В конце концов, у кого-то могут быть изменения, которые они отправляют обратно первоначальному владельцу (с помощью "push", патчей или чего-то еще).
Команда
git pull
в основном является сокращением отgit fetch
Followgit merge
. Это важно, потому что это означает, что вам нужно понимать, что на самом деле делают эти две операции.Команда
git fetch
говорит вернуться туда, откуда вы клонировали (или иным образом настроили как место для извлечения), и найти «новые вещи, которые кто-то добавил, изменил или удалил». Эти изменения копируются и применяются к вашей копии того, что вы получили от них ранее . Они не применяются к вашей собственной работе, только к их.Команда
git merge
более сложная, и вы ошибаетесь. Что он делает, немного упрощенно, - это сравнивает «то, что вы изменили в своей копии», с «изменениями, которые вы получили от кого-то другого и, таким образом, были добавлены в вашу копию чужой-работы». Если ваши изменения и их изменения не конфликтуют,merge
операция объединяет их вместе и дает вам «фиксацию слияния», которая связывает вашу разработку и их разработку вместе (хотя есть очень распространенный «простой» случай, когда у вас нет меняется и вы получаете "перемотку вперед").Ситуация, с которой вы сейчас сталкиваетесь, - это та, в которой вы внесли изменения и зафиксировали их - фактически девять раз, отсюда «впереди 9» - и они не внесли никаких изменений. Итак,
fetch
послушно ничего не получает, а затемmerge
принимает их отсутствие изменений и тоже ничего не делает.Вы хотите посмотреть или, может быть, даже "сбросить" до "их" версию кода.
Если вы просто хотите взглянуть на него, вы можете просто проверить эту версию:
Это говорит git, что вы хотите переместить текущий каталог в ветку, чье полное имя действительно
remotes/upstream/master
. Вы увидите их код на момент последнего запускаgit fetch
и получения последнего кода.Если вы хотите отказаться от всех собственных изменений, вам нужно изменить представление git о том, какую ревизию
master
должен называть ваш ярлык . В настоящее время он называет вашу самую последнюю фиксацию. Если вы вернетесь в эту ветку:тогда
git reset
команда позволит вам как бы "переместить метку". Единственная оставшаяся проблема (при условии, что вы действительно готовы отказаться от всего, что делали) - это найти, куда должна указывать этикетка.git log
позволит вам найти числовые имена - такие вещи, как -7cfcb29
которые являются постоянными (никогда не меняющимися) именами, и есть смехотворное количество других способов назвать их, но в этом случае вам просто нужно имяupstream/master
.Чтобы переместить метку, удалив свои собственные изменения (все, что вы зафиксировали, на самом деле можно восстановить в течение некоторого времени, но после этого будет намного сложнее, поэтому будьте очень уверены):
--hard
Рассказывает мерзавец , чтобы уничтожить то , что вы делаете, переместить текущую метку ветви, а затем проверить данное обязательство.Это не очень распространенное явление - действительно захотеть
git reset --hard
и уничтожить кучу работы. Более безопасный метод (значительно упрощающий восстановление этой работы, если вы решите, что некоторые из них в конце концов стоили) - переименовать существующую ветку:а затем создайте новую локальную ветку с именем,
master
которая «отслеживает» (мне не очень нравится этот термин, поскольку я думаю, что он сбивает людей с толку, но это термин git :-)) исходный (или восходящий) мастер:с которыми вы можете заняться:
Что делают последние три команды (есть ярлыки, чтобы сделать это всего лишь двумя командами), так это изменить имя, вставленное в существующую метку, затем создать новую метку, а затем переключиться на нее:
прежде чем что-либо делать:
после
git branch -m
:после
git branch -t master upstream/master
:Вот
C0
последний коммит (полное дерево исходных текстов), который вы получили, когда впервые сделали свойgit clone
. С C1 по C9 - ваши коммиты.Обратите внимание, что если бы вы сделали
git checkout bunchofhacks
и затемgit reset --hard HEAD^^
, это изменило бы последнее изображение на:Причина в том, что
HEAD^^
имя ревизии два выше заголовка текущей ветки (которая была бы непосредственно перед сбросомbunchofhacks
), аreset --hard
затем перемещает метку. Коммиты C8 и C9 теперь в основном невидимы (вы можете использовать такие вещи, как reflog, иgit fsck
находить их, но это уже не тривиально). Ваши ярлыки принадлежат вам, чтобы перемещать их как хотите. Командаfetch
позаботится о тех, которые начинаются сremotes/
. Принято сопоставлять «ваш» с «их» (так что, если у них есть,remotes/origin/mauve
вы быmauve
тоже назвали свое ), но вы можете ввести «их», когда захотите назвать / увидеть коммиты, которые вы получили «от них». (Помните, что «одна фиксация» - это все дерево исходных текстов. Вы можете выбрать один конкретный файл из одной фиксации,git show
например,источник
git merge
команду из командной строки (это то, что я делаю сам, это разумный метод). Однако обратите внимание, что этоgit pull
начинается сначала с запускаgit fetch
, а затем с запускаgit merge
(или,git rebase
если вы скажете ему сделать это вместо этого). Это шаг выборки, который фактически переносит новые коммиты для объединения (или только для перебазирования).git status
, которую я могу использовать, чтобы увидеть, опережает ли вышестоящее репо мое текущее репо? Сообщение, которое я получаюgit status
, говорит: «Ваша ветка обновлена с помощью 'origin / master'», сбивает меня с толку, заставляя думать, что у меня есть последние изменения, а у меня нет. Иногда я получаю сообщение вроде «origin / master на 5 коммитов впереди вашей ветки» (перефразируя). Но это непоследовательно.git status
говорится: «Ваша ветка обновлена», когда немедленноеgit fetch
затем опускает более сотни объектов и разрешает почти сотню дельт, упоминает несколько новых ветвей и пару новых тегов и изменяет основной (удаленный отслеживание), фиксация главы ветки - а затем другой статус git весело и лукаво по-прежнему говорит: «Ваша ветка обновлена». Очевидно, что многое произошло от источника, но ветвь была "актуальной с происхождением" как до, так и после?git pull
git fetch
сначала выполняется , затемgit merge
(или другая вторая команда по вашему выбору). Этотgit fetch
шаг обновляет память вашего Git об их статусе Git, вызывая их Git и получая от них все новое. Выgit status
только проверяете память своего Git об их Git.У меня была такая же проблема, как и у вас.
Я сделал это
git status
git fetch
git pull
, но моя ветвь все еще отставала от происхождения. У меня были папки и файлы, перемещенные на удаленный компьютер, и я видел файлы в Интернете, но на моем локальном компьютере они отсутствовали.Наконец, эти команды обновили все файлы и папки на моем локальном компьютере:
или если вам нужна ветка
источник
Любые изменения, которые вы фиксируете, например удаление всех файлов вашего проекта, останутся в силе после извлечения. Все, что делает вытягивание, - это объединяет последние изменения откуда-то еще в вашу собственную ветку, и если ваша ветка удалила все, то в лучшем случае вы получите конфликты слияния, когда исходящие изменения затрагивают удаленные вами файлы. Короче говоря, да, все в актуальном состоянии.
Если вы опишете, какой результат вы хотели бы получить вместо «все файлы удалены», возможно, кто-нибудь предложит подходящий курс действий.
Обновить:
Вы, кажется, не понимаете, что у вас уже есть самый последний код, который принадлежит вам. Если вы действительно хотите увидеть самые последние работы кого-то еще в главной ветке, просто выполните:
Обратите внимание, что это не даст вам возможности немедленно (повторно) начать свою собственную работу. Если вам нужно знать, как отменить что-то, что вы сделали, или иным образом отменить изменения, внесенные вами или кем-то другим, укажите подробности. Также подумайте о том, для чего нужен контроль версий, поскольку вы, кажется, неправильно понимаете его основную цель.
источник
upstream/master
. Обновил свой ответ.Как говорят другие плакаты, pull объединяет изменения из апстрима в ваш репозиторий. Если вы хотите заменить то, что находится в вашем репозитории, на то, что находится в апстриме, у вас есть несколько вариантов. Без манжеты я бы пошел с
источник
Главный ответ намного лучше с точки зрения широты и глубины предоставленной информации, но похоже, что если вы хотите, чтобы ваша проблема была решена почти немедленно, и не возражаете против того, чтобы наступить на некоторые из основных принципов контроля версий, вы могли бы ...
Перейти к мастеру
Удалите ненужную ветку. (Примечание: он должен иметь -D вместо обычного флага -d, потому что ваша ветка намного опережает ведущую.)
Создать новую ветку
источник
Хотя ни один из этих ответов у меня не сработал, я смог исправить проблему с помощью следующей команды.
git fetch origin
Это помогло мне.
источник
Просто дружеское напоминание, если у вас есть файлы локально, которых нет в github, но вы
git status
говоритеЭто может случиться, если файлы находятся в
.gitignore
Попробуйте бежать
и посмотреть, появляются ли там эти файлы. Это объясняет, почему git не хочет перемещать их на удаленный компьютер.
источник