Почему Git говорит, что моя главная ветка "уже обновлена", хотя это не так?

я думаю, что ваша основная проблема здесь в том, что вы неправильно интерпретируете и/или не понимаете, что делает git и почему он это делает.

когда вы клонируете какой-то другой репозиторий, git делает копию того, что "там". Он также принимает" свои " метки ветвей, такие как master, и делает копию этого ярлыка, чье "полное имя" в код дерево git (обычно)remotes/origin/master (но в вашем случае, remotes/upstream/master). Большую часть времени вы можете опустить remotes/ часть тоже, так что вы можете обратитесь к этой оригинальной копии как upstream/master.

если вы теперь сделаете и зафиксируете некоторые изменения в некоторых файлах, вы единственный, у кого есть эти изменения. Между тем другие люди могут использовать исходный репозиторий (из которого вы сделали свой клон) для создания других клонов и изменения этих клонов. Конечно, они единственные, у кого есть изменения. В конце концов, у кого-то могут быть изменения, которые они отправляют обратно первоначальному владельцу (через "push" или патчи или что-то еще).

в git pull команда в основном просто стенография для git fetch следовал по git merge. Это важно, потому что это означает, что вам нужно понять, что на самом деле делают эти две операции.

на git fetch команда говорит, чтобы вернуться туда, откуда вы клонировали (или иным образом настроили как место для извлечения) и найти "новый материал, который кто-то добавил или изменил или удалил". Эти изменения копируются и применяются к вашей копии того, что вы получили от них ранее. Они не применяется к вашей собственной работе, только к их.

на git merge команда сложнее и там, где вы идете наперекосяк. Что он делает, немного упрощенный, сравнивает "то, что вы изменили в своей копии" с "изменениями, которые вы получили от кого-то другого и, таким образом, добавили к своей копии чужой работы". Если ваши изменения и их изменения, похоже, не конфликтуют,merge операция смешивает их вместе и дает вам "слияние", которое связывает ваши развитие и их развитие вместе (хотя есть очень распространенный " легкий "случай, в котором у вас нет изменений, и вы получаете"быструю перемотку").

ситуация, с которой вы столкнулись сейчас, - это та, в которой вы внесли изменения и совершили их-девять раз, фактически, отсюда "вперед 9" - и они сделали нет изменения. Итак,fetch покорно ничего не приносит, а потом merge принимает их отсутствии изменений, а также ничего не делает.

что вы хотите чтобы посмотреть или, может быть, даже "сбросить" на "свою" версию кода.

если вы просто хотите взглянуть на него, вы можете просто проверить эту версию:

git checkout upstream/master

это говорит git, что вы хотите переместить текущий каталог в ветку, полное имя которой на самом деле remotes/upstream/master. Вы увидите их код с момента последнего запуска git fetch и получил их последний код.

если вы хотите отказаться все ваши собственные изменения, что вам нужно сделать, это идея изменения в Git пересмотра метки master, следует назвать. В настоящее время он называет ваш последний commit. Если вы вернетесь на эту ветку:

git checkout master

тут git reset команда позволит вам "переместить метку", как это было. Единственная оставшаяся проблема (при условии, что вы действительно готовы отказаться от всего, что у вас есть) - найти, куда должна указывать метка.

git log позволит вам найти числовые имена-такие вещи, как 7cfcb29-которые постоянные (никогда не изменяющиеся) имена, и есть смешное количество других способов назвать их, но в этом случае вы просто хотите имя upstream/master.

чтобы переместить метку, стирая свои собственные изменения (любые, которые вы совершили, на самом деле восстанавливаются довольно долго, но после этого намного сложнее, так что очень обязательно):

git reset --hard upstream/master

на --hard говорит git стереть то, что вы делали, переместить текущую метку ветви, а затем проверить дано поручение.

это не супер-общие действительно хотите git reset --hard и уничтожить кучу работы. Более безопасный метод (что делает его намного проще восстановить эту работу, если вы решите, что некоторые из них стоили того) - переименовать существующую ветку:

git branch -m master bunchofhacks

а затем создайте новую локальную ветвь с именем master это " треки "(мне не очень нравится этот термин, поскольку я думаю, что он смущает людей, но это термин git: -)) происхождение (или вверх по течению) мастер:

git branch -t master upstream/master

который вы можете получить себя с:

git checkout master

что делают последние три команды (есть ярлыки, чтобы сделать это только две команды), чтобы изменить имя, вставленное на существующую метку, затем сделать новую метку, а затем переключиться на нее:

прежде чем что-то делать:

C0 -    "remotes/upstream/master"
    \
     \- C1 --- C2 --- C3 --- C4 --- C5 --- C6 --- C7 --- C8 --- C9    "master"

после git branch -m:

C0 -    "remotes/upstream/master"
    \
     \- C1 --- C2 --- C3 --- C4 --- C5 --- C6 --- C7 --- C8 --- C9    "bunchofhacks"

после git branch -t master upstream/master:

C0 -    "remotes/upstream/master", "master"
    \
     \- C1 --- C2 --- C3 --- C4 --- C5 --- C6 --- C7 --- C8 --- C9    "bunchofhacks"

здесь C0 последний коммит (полный исходное дерево), которое вы получили, когда вы впервые сделали свой git clone. C1-C9-ваши коммиты.

обратите внимание, что если вы git checkout bunchofhacks а то git reset --hard HEAD^^, это изменит последнее изображение на:

C0 -    "remotes/upstream/master", "master"
    \
     \- C1 --- C2 --- C3 --- C4 --- C5 --- C6 --- C7 -    "bunchofhacks"
                                                      \
                                                       \- C8 --- C9

причина в том, что HEAD^^ называет ревизию двумя вверх от главы текущей ветви (которая непосредственно перед сбросом будет bunchofhacks), и reset --hard затем перемещает метку. Совершает С8 и С9 сейчас в основном Невидимый (вы можете использовать такие вещи, как reflog и git fsck найти их, но это уже не тривиально). Ваши ярлыки Ваши, чтобы двигаться, как вам нравится. The заботится о тех, которые начинаются с remotes/. Принято сопоставлять "ваше" с "их" (так что, если у них есть remotes/origin/mauve назови свое mauve тоже), но вы можете ввести "их", когда захотите назвать/увидеть коммиты, которые вы получили "от них". (Помните, что" одна фиксация " - это целое дерево источников. Вы можете выбрать один конкретный файл из одной фиксации с помощью git show например, если и когда вы этого захотите.)