Git Merge сообщает «Уже в актуальном состоянии», хотя есть разница

У меня есть git-репозиторий с 2 ​​ветками: master и test.

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

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

Если я сделаю:

мастер проверки

тест на git diff

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

Git Merge Test

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

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

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

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

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

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

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

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

git checkout master
git reset --hard test

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

Затем сделайте:

git push --force origin master

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

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

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

Допустим, у вас есть ветка 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, поэтому ветвь master имеет следующую историю коммитов:

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

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

git reset --hard H

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

Вы открываете командную строку git, идете в корневую папку branch2 и набираете:

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

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

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

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

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

Это происходит потому, что ваша локальная копия ветви, которую вы хотите объединить, устарела. Я получил свою ветку, позвонил 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.

И теперь у меня есть еще одна проблема, чтобы исправить ...

Это случилось со мной, потому что странно GIT думал, что локальный филиал отличается от удаленного филиала. Это было видно на графике ветвей: он отображал две разные ветви: remotes / origin / branch_name и 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>

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

git checkout feature_branch
git merge origin/master

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

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

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

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

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

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

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

Пример:

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

На этом этапе слияние от А до Б сообщает «Уже в курсе», но ветви отличаются, потому что ветвь В имеет обновления от главного, а ветвь А - нет.

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

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

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

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

мерзавец происхождения

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

Таким образом, чтобы исправить это проверил 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 :), что и ожидалось

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

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

Глупо, но это может случиться. Предположим, что перед именем вашей ветки стоит ссылка на проблему (например #91-fix-html-markup), если вы выполните это слияние:

$ git merge #91-fix-html-markup

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

В этом случае вы можете переименовать ветку Опуская #или использовать одиночные кавычки , чтобы окружить имя ветви: git merge '#91-fix-html-markup'.