Эта вещь «принудительного обновления» может быть очень запутанной, но вы задали важный вопрос.
Есть ли какая-либо реальная проблема здесь - я подозреваю, что нет - зависит от того, что вы означает, когда вы говорите:
... и закончено bug/12 branch.
Git не имеет понятия под названием отделка . Так что неясно, какие фактические операции Git вы вызвали, в каких репозиториях.
Git распространяется, поэтому существует более одного репозитория
Если был только один репозиторий и у него были различные имена веток, такие как bug/12, и вы сделали что-то вроде:
git checkout master
git merge bug/12
git branch -d bug/12
(что объединит коммит в кончиках bug/12 с master, затем delete имя ветки bug/12) такого рода проблемы никогда не возникнут: если удалить имя, оно больше не существует.
Но не существует только одного хранилища. Вы:
- создали имя
bug/12 в вашем хранилище - проделали определенную работу в вашем хранилище, создав коммиты
- отправил эти коммиты в другое хранилище и них создал имя
bug/12 в их хранилище - имел ваш Git получать новые коммиты и / или имена веток от них: при этом обнаружилось, что у них теперь есть
bug/12 в их хранилище, поэтому ваш Git создал origin/bug/12 в вашем хранилище помнить их bug/12
Теперь, после всего этого, я подозреваю , что вы сделали - что вы имеете в виду «закончено bug/12 branch» - это то, что вы использовали GitHub, Bitbucket, GitLab или аналогичный, и вы перешли на их веб-интерфейс и использовали различные маленькие щелкающие кнопки, чтобы объединить bug/12 в master в их хранилище, а затем удалили их bug/12 имя . Это очень похоже на три гипотетические команды, показанные выше, за исключением того, что `git ошибка слияния / 12 может выполнять операцию ускоренной перемотки вместо истинного слияния, в то время как кнопка GitHub запрос на слияние никогда не будет выполните операцию ускоренной перемотки вперед.
Но я не знаю , что это то, что вы сделали. Я просто подозреваю это.
Устаревшие имена для удаленного слежения
Предполагая, что это является , что вы сделали, вы, вероятно, продолжили вручную удалять имя ветки bug/12 из вашего собственного репозитория:
git branch -D bug/12
С тех пор вы, вероятно, запустили git fetch (или git pull запустили git fetch таким образом, чтобы исправить ситуацию), но вы, вероятно, не не установили fetch.prune на true. Когда вы запускаете git fetch, ваш Git вызывает Git на origin и заставляет их перечислить имена своих ветвей. У них нет bug/12 имени ветви на данный момент , но ваш Git сделал свой собственный origin/bug/12 ранее, когда у них было их имя bug/12 ветви , Поэтому ваш Git ничего не делает с вашим собственным origin/bug/12 именем: для этого имени нет нового значения, но вы не указали своим Git to удалить origin/* имен, которые больше не имеют другое имя.
Это означает, что в отношении вашего Git, origin/bug/12 все еще помнит действительное имя bug/12 в другом хранилище Git, , даже если нет такое имя уже не . Если бы вы установили fetch.prune на true или запустили git fetch --prune, ваш Git удалил бы это origin/bug/12. Итак, на данный момент ваше origin/bug/12 является устаревшим именем . (Git не определяет этот термин - у него нет понятия под названием устаревшие имена - но это похоже на хороший термин для этого вида имени.)
Опять же, все это вычет из фактов, которые на самом деле не в качестве доказательства. Это действительно то, что случилось? Я не могу знать: вы не сказали мне достаточно.
Устаревшие имена могут привести к такому поведению
Теперь, если предположить, что все вышеперечисленное верно, ваш origin/bug/12 помнит, что bug/12 на origin вспомнил какое-то время go. Это было до того, как вы нажали на объединить или , перебазировать и объединить или squa sh и объединить кнопку веб-браузера. На этом этапе я должен сделать хотя бы еще одно предположение: кнопка, которую вы использовали, была не просто слиянием , а скорее перебазировкой и слиянием или squa sh и слиянием .
Давайте нарисуем ситуацию перед операцией rebase-and-merge или squa sh-and-merge. У вас в репозитории Git на GitHub - я собираюсь предположить, что на этом этапе GitHub - серия коммитов, каждый из которых заканчивается коммитом, на который указывают некоторые ветви:
...--A--B--C--D <-- parent/1.2.3
\
E--F <-- bug/12
Здесь E и F - это два коммита, которые исправляют ошибку. Теперь вы нажимаете , перебазируете и объединяете или squa sh, объединяете и получаете два или один новый коммит:
...--A--B--C--D--E'-F' <-- parent/1.2.3
\
E--F <-- bug/12
или:
...--A--B--C--D--G <-- parent/1.2.3
\
E--F <-- bug/12
(я буду go с этим рисунком, потому что он проще). Теперь GitHub удаляет его bug/12 имя:
...--A--B--C--D--G <-- parent/1.2.3
\
E--F [abandoned]
В какой-то момент в вашем хранилище вы обновляете собственную Git память из веток GitHub Git:
...--A--B--C--D--G <-- origin/parent/1.2.3
\
E--F <-- origin/bug/12
Обратите внимание, что ваше устаревшее origin/bug/12 имя все еще помнит commit F!
На этом этапе вы можете добавлять или не добавлять еще больше фиксирует origin/parent/1.2.3 и / или обновляет ваше собственное имя parent/1.2.3. Давайте нарисуем еще один коммит и покажем эти два в синхронном виде c:
...--A--B--C--D--G--H <-- parent/1.2.3, origin/parent/1.2.3
\
E--F <-- origin/bug/12
Помните, это рисунок того, что находится в вашем хранилище. Репозиторий GitHub имеет это вместо:
...--A--B--C--D--G--H <-- parent/1.2.3
У него нет origin/* имен: у него есть только его имен ветвей. Ваш Git является именем с origin/* именами, включая устаревшие origin/bug/12. К настоящему времени их Git полностью отказались от коммитов E-F. Ваш Git по-прежнему сохраняет другие нежелательные E-F коммиты из-за вашего origin/bug/12 имени.
Теперь вы что-то делаете в их Git это создает имя bug/12, указывающее на коммит H:
...--A--B--C--D--G--H <-- parent/1.2.3, bug/12
Теперь вы запускаете git fetch (через git pull) в вашем хранилище. Ваш Git видит их bug/12, указывающих на коммит H. Ваш Git в настоящее время имеет это:
...--A--B--C--D--G--H <-- parent/1.2.3, origin/parent/1.2.3
\
E--F <-- origin/bug/12
, но ваш Git теперь собирается взять ваш origin/bug/12 и вырвать его из коммита F и переместите его, чтобы указать H вместо:
...--A--B--C--D--G--H <-- parent/1.2.3, origin/parent/1.2.3, origin/bug/12
\
E--F [abandoned]
Ваш Git теперь делает это необычное движение из ваше имя origin/bug/12 , извлекая его из коммита, который вы все еще сохраняете - коммит F - для фиксации H, то есть , а не * потомок коммит F. (Единственный родительский элемент для H - G. Родительский G - D, чей родитель C, родительский элемент B. Следовательно, H не является потомок F, хотя они оба имеют одинаковое происхождение при коммите B.) Эта операция не ускоренная перемотка вперед и, следовательно, ваш Git печатает:
+ 6cca7ee...32eb5b2 bug/12 -> origin/bug/12 (forced update)
Знак плюса на передней панели (который вы пропустили) указывает на то, что это принудительное обновление , потому что это без быстрой перемотки вперед .
Два идентификатора ha sh здесь, 6cca7ee и 32eb5b2, являются сокращенными версиями полных идентификаторов ha sh коммитов, которые я звонил F и H выше. , Вывод git fetch включает три точки между этими двумя идентификаторами ha sh, указывающими, что 6cca7ee не является предком 32eb5b2.
Имя bug/12 в левой части стрелка - это имя ветви, как видно в их хранилище (в GitHub или где бы то ни было). Имя origin/bug/12 - это память Git их bug/12.
(forced update) в конце означает то же самое, что и знак плюс и три точки : это не было перемоткой вперед, и поэтому оно было выполнено как принудительное обновление.
Поэтому команда git fetch трижды сообщала вам, что произошло принудительное обновление.
Здесь есть проблема?
Ответ , вероятно, не , но это зависит не от этого изменения ваших origin/bug/12, а от ваших собственных названий ветвей. На рисунках выше мы рисовали некоторые из ваших названий ветвей, некоторые из ваших удаленных трекингов origin/* имен и некоторые из других Git имен ветвей, в зависимости от того, какие Git хранилище, о котором мы говорим. Но мы не рисовали все названий ваших ветвей.
Ваши имена ветвей ваши . Они могут указывать на любой коммит, который у вас есть в вашем репозитории, включая E-F коммиты, которые другие Git, на GitHub или где бы то ни было, были сброшены. Если вы позволите одному из имен вашей ветви повторно ввести эти старые коммиты, это, вероятно, не очень хорошо. Если вы этого не допустите, это нормально. Если у вас нет названий ветвей, которые указывают на эти старые коммиты, вы случайно не будете вводить их заново.
Это ключ к загадке. коммиты имеют значение. Коммиты имеют коммиты с га sh и каждый Git по всему миру соглашается, что эти коммиты получают эти га sh ID. Никакой другой коммит, где бы то ни было или когда-либо, не может иметь эти sh идентификаторы! У вашего Git все еще были они под вашим именем удаленного слежения, origin/bug/12. Он больше не имеет их под этим именем: это имя было обновлено, чтобы вспомнить какой-то другой коммит ha sh ID. Но у вас все еще есть ваши названия филиалов. Кто-нибудь из них помнит тот же самый номер sh, что и устаревший origin/bug/12, который у вас был до git fetch, когда ваш git pull обновил его, совсем недавно?
Только вы может ответить на это, потому что только у вас есть ваше Git хранилище.