Git слияние отчетов "Уже обновлено", хотя есть разница

У меня есть репозиторий git с двумя ветвями: master и test.

Существуют различия между ведущими и тестовыми ветвями.

Обе ветки зафиксировали все изменения.

Если я это сделаю:

git checkout master
git diff test

Появится экран, полный изменений, показывающий различия. Я хочу объединить изменения в тестовой ветке, и так:

git merge test

Но получите сообщение "Уже обновлено"

Тем не менее, при анализе файлов в каждой отдельной ветки четко отображаются различия.

В чем проблема и как ее решить?

Ответы

Ответ 1

Сообщение "Уже обновлено" означает, что все изменения из ветки, которую вы пытаетесь объединить, уже объединены с веткой, в которой вы находитесь. Более конкретно, это означает, что ветвь, которую вы пытаетесь объединить, является родительской для вашей текущей ветки. Поздравляю, это самое легкое слияние, которое ты когда-либо делал. :)

Используйте gitk, чтобы взглянуть на ваш репозиторий. Метка для ветки 'test' должна быть где-то ниже вашей метки 'master'.

Ваш филиал обновлен по отношению к своему родителю. Согласно слиянию нет никаких новых изменений в родительском элементе с момента последнего слияния. Это не означает, что ветки одинаковы, потому что вы можете иметь множество изменений в вашей рабочей ветке, и это звучит так же, как и вы.

Изменить 10/12/2019:

Согласно Чарльзу Дрейку в комментарии к этому ответу, одним из решений этой проблемы является:

git checkout master
git reset --hard test

Это возвращает его к уровню "теста".

Затем выполните:

git push --force origin master

чтобы заставить изменения вернуться к центральному репо.

Ответ 2

Это часто случается со мной, когда я знаю, что на удаленном сервере есть изменения, поэтому я пытаюсь объединить их с помощью git merge master. Однако это не сливается с удаленным мастером, а с вашим локальным мастером.

Итак, прежде чем выполнять слияние, мастер проверки, а затем git pull. Затем вы сможете объединить новые изменения в свою ветку.

Ответ 3

Скажем, у вас есть ветвь master со следующей историей фиксации:

A -- B -- C -- D

Теперь вы создаете тест ветвления, работаете над ним и делаете 4 фиксации:


                 E -- F -- G -- H
                /
A -- B -- C -- D

master точки головы до D и test точки головы до H.

Сообщение "Уже обновлено" появляется, когда HEAD ветки, в которую вы сливаетесь, является родителем цепочки фиксаций ветки, которую вы хотите объединить. В этом случае здесь: D является родителем E.

Нельзя слить от test до master, так как с тех пор ничего не изменилось на master. То, что вы хотите сделать здесь, буквально означает, что Git имеет головку master, чтобы указать на H, поэтому главная ветвь имеет следующую историю фиксации:

A -- B -- C -- D -- E -- F -- G -- H

Это задание для команды Git reset. Вы также хотите, чтобы рабочий каталог отражал это изменение, поэтому вы будете выполнять жесткий reset:

git reset --hard H

Ответ 4

Что работает для меня, скажем, у вас есть branch1, и вы хотите объединить его в branch2.

Откройте командную строку git, перейдите в корневую папку ветки2 и введите:

git checkout branch1
git pull branch1
git checkout branch2
git merge branch1
git push

Если у вас есть конфликты, вам не нужно делать git push, но сначала разрешите конфликты, а затем нажмите.

Ответ 5

Слияние всегда между текущим HEAD и одним или несколькими записями (обычно, веткой головы или тегом),
и индексный файл должен соответствовать дереву фиксации HEAD (т.е. содержимому последнего коммита), когда он начнется.
Другими словами, git diff --cached HEAD не должен сообщать о каких-либо изменениях.

Объединенная фиксация уже содержится в HEAD. Это самый простой случай, называемый "Уже обновленный".

Это означает, что коммиты в тесте уже объединены в master, но поскольку другие коммиты выполняются на master, git diff test все равно будут давать некоторые отличия.

Ответ 6

Это случилось со мной, потому что странно GIT считал, что локальная ветвь отличается от удаленной ветки. Это было видно на графике ветвей: оно отображало две разные ветки: remotes/origin/branch_name и имя_панели.

Решением было просто удалить локальное репо и повторно клонировать его с удаленного. Таким образом, GIT понял бы, что remotes/origin/branch_name > и branch_name действительно совпадают, и я мог бы выпустить git merge branch_name.

rm <my_repo>
git clone <my_repo>
cd <my_repo>
git checkout <branch_name>
git pull
git checkout master
git merge <branch_name>

Ответ 7

Это происходит потому, что ваша локальная копия ветки, которую вы хотите объединить, устарела. У меня есть ветвь, которая называется MyBranch, и я хочу объединить ее с ProjectMaster.

_>git status
On branch MyBranch-Issue2
Your branch is up-to-date with 'origin/MyBranch-Issue2'.

nothing to commit, working tree clean

_>git merge ProjectMaster
Already up-to-date.

Но я знаю, что есть изменения, которые нужно объединить!

Здесь, когда я набираю git merge ProjectMaster, git просматривает мою локальную копию этой ветки, которая может быть не текущей. Чтобы проверить, так ли это, я сначала говорю Git проверить, устарели ли мои ветки и извлекать ли какие-либо изменения, если это так, используя, fetch. Затем я прыгаю в ветку, которую хочу объединить, чтобы посмотреть, что там происходит...

_>git fetch origin

_>git checkout ProjectMaster
Switched to branch ProjectMaster
**Your branch is behind 'origin/ProjectMaster' by 85 commits, and can be fast-forwarded.**
  (use "git pull" to update your local branch)

Ах-ха! Моя локальная копия устарела на 85 коммитов, это все объясняет! Теперь я Pull записываю пропущенные изменения, затем переключаюсь на MyBranch и снова пытаюсь выполнить слияние.

_>git pull
Updating 669f825..5b49912
Fast-forward

_>git checkout MyBranch-Issue2
Switched to branch MyBranch-Issue2
Your branch is up-to-date with 'origin/MyBranch-Issue2'.

_>git merge ProjectMaster
Auto-merging Runbooks/File1.ps1
CONFLICT (content): Merge conflict in Runbooks/Runbooks/File1.ps1

Automatic merge failed; fix conflicts and then commit the result.

А теперь мне нужно исправить еще одну проблему...

Ответ 8

произошел со мной и был отправлен на эту страницу, не уверен, что у меня был такой же сценарий, но мой был мной, пытающимся "повторно объединить" эту ветвь "test".

Итак, я ранее объединил его, но я намеренно исключаю некоторые конкретные изменения во время этого слияния, поэтому он явно имеет разницу между ветвями. Затем я пытался повторно объединить его, потому что я осознал/забыл, что должен иметь и хотел бы добавить конкретное изменение/файл, который я ранее исключил, и я надеялся, что если я снова сделаю слияние, будут показаны все изменения, которые я исключил раньше, но я ошибся, и вместо этого я получил сообщение "Уже обновленное".

При чтении комментария/ответа @Bombe он прав, и git Я думаю, что так поступает, поэтому я сделал, чтобы сделать жесткую резервную копию файлов на тестовой ветке, затем проверить мастер-ветку и вручную вставить файлы в нем и передать его, как если бы это были новые изменения.

Я не уверен, что это правильный путь или может помочь другим, имеющим эту проблему, но это обеспечило решение моего конкретного случая.

Ответ 9

git merge origin/master вместо этого git merge master работал для меня. Таким образом, чтобы объединить мастер в ветвь функций, вы можете использовать:

git checkout feature_branch
git merge origin/master

Ответ 10

Обязательно сначала извлеките ветку, которую хотите объединить, а затем извлеките ее (чтобы ваша локальная версия соответствовала удаленной версии).

Затем вернитесь в свою ветку, на которой вы хотите выполнить слияние, и ваш git merge должен работать.

Ответ 11

Если объединение ветки А в ветку B сообщает "Уже обновлено", обратное не всегда верно. Это верно, только если ветвь B является потомком ветки A, иначе ветвь B просто может иметь изменения, которые не входят в A.

Пример:

  • Вы создаете ветки A и B от мастера
  • Вы вносите некоторые изменения в master и объединяете эти изменения только в ветвь B (не обновляя или забывая обновлять ветвь A).
  • Вы делаете некоторые изменения в ветке A и объединяете A в B.

В этот момент слияние от A до B отчетов "Уже обновлено", но ветки разные, потому что ветвь B имеет обновления от мастера, а ветка A - нет.

Ответ 12

Столкнувшись с этим сценарием, используя Git Bash.

Наш репозиторий имеет несколько ветвей, и каждая ветвь имеет другой цикл фиксации, и слияние происходит раз в то время. Old_Branch использовался в качестве родителя для New_Branch

Old_Branch был обновлен с некоторыми изменениями, которые необходимо объединить с New_Branch

Использул команду pull без какой-либо ветки, чтобы получить все источники из всех ветвей.

git pull origin

Странно это не тянет все коммиты со всех ветвей. Если бы это было так, как показано на рисунке, вы увидите почти все ветки и теги.

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

git checkout Old_Branch

git pull origin Old_Branch

Теперь выберет New_Branch

git checkout New_Branch

Вытащил его, чтобы быть уверенным

git pull origin New_Branch

git merge Old_Branch

И у альта возникли конфликты, чтобы исправить от Old_Branch до New_Branch:), который ожидался

Ответ 13

То же самое случилось со мной. Но сценарий был немного другим, у меня была мастерская ветка, и я вырезал release_1 (скажем) из него. Сделал некоторые изменения в ветки release_1 и объединил его в исходное. то я сделал ssh и на удаленном сервере Я снова проверяю release_1, используя команду git checkout -b release_1, которая на самом деле вырезает новую ветвь release_! от мастера, а не проверять уже существующую ветвь release_1 от источника. Решив проблему, удалив переключатель "-b"

Ответ 14

У меня такая же проблема. У меня были изменения в пульте, и он все еще показывал "Уже в курсе". Перемещение репозитория устранило проблему для меня.