Я пытаюсь объединить две разные ветки, но git говорит мне, что все обновлено

Question

Я мерзавец, и я знаю, что мне здесь чего-то не хватает. У меня есть три ветви: мастер, Feature1 и Feature2. Нет двух одинаковых ветвей, но любая попытка слияния из одной ветви в другую приводит к появлению «актуального» сообщения. Как вы можете себе представить, я выполнил свою работу над Feature1 и Feature2, и теперь я просто хочу объединить эту работу с моим мастером.

Вот как выглядит мой текущий график:

*   c719e79 master
|\  
| * 3f38259 feature2
| * 4e2af8c
| * a6ee18c
| * 2339052
| * 2e31d49
| * 2586659
| * 8b4a194
| * 56200c1
| * 97598e3
| * c28bc8d
| * 68b2e2f
| * 1ad4ad8
| * 3d5f4ad
| * 83435ca
| * 4049428
| * 581134a
| * 6e5aa2d
* | 2c88093
|/  
* 3130ec9 feature1
* 54a5311 INITIAL COMMIT

Есть идеи?

---

UPDATE

VonC - объяснение имеет смысл, но мое git-репо по-прежнему нет. Когда я переключаюсь на свою основную ветку и затем запускаю «$ git diff --stat feature2», я получаю следующий вывод:

$git diff --stat feature2
File1      |    2 +-
File2      |    6 +++---
File3      |    4 ++--
File4      |    2 +-
File5      |    2 +-
5 files changed, 8 insertions(+), 8 deletions(-)

Я получаю еще более длинный список файлов, если запускаю ту же команду для feature1. Итак ... У меня все еще есть сообщение, что я в курсе, но файлы в каждой ветке разные.

---

ОБНОВЛЕНИЕ 2

@ Скотт - Хорошо, я думаю, ваш ответ помог немного прояснить мою проблему. Я понимаю, что слияние не сделает все ветви идентичными, но просто обновит ветку, на которой я работаю.

Однако, похоже, что мои коммиты вышли из строя или что-то в этом роде. Другими словами, есть изменения, которые существуют в ветви feature2, которые я хочу отображать в моей основной ветви. Git должен думать, что версии файлов в моей главной ветке - «правильные» (что бы это ни значило). Как заставить Git зафиксировать различия в ветви feature2 в моей основной ветке, когда он считает, что изменения в master в настоящий момент самые последние и самые большие?

---

ОБНОВЛЕНИЕ 3 (окончательное)

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

Обдумав некоторые ваши комментарии, я сделал ребаз. График истории коммитов представлял собой прямую линию, как и следовало ожидать. Однако проблема не исчезла: моя ветка feature2 отстала от master на один коммит, но содержала код, который фактически превратил его в ветвь с «последним и лучшим» кодом. Попытка слияния веток ничего не сделала. Наконец, я просто решил создать новую ветку из моей ветки feature2 и назвал ее «самой последней». Так что, в конце концов, я благодарен за то, как легко работать с git. Но ясно, что я что-то упустил ...

Еще раз спасибо всем.

Answer 1

Проблема в том, что вы ожидаете, что ветки feature1 и feature2 изменятся так же, как и ветвь master, когда вы их объедините. Однако слияние влияет только на ветку, в которой вы находитесь в данный момент.Если вы хотите, чтобы все три ветви указывали на один и тот же моментальный снимок фиксации, вы можете запустить

$ git checkout feature1
$ git merge master
$ git checkout feature2
$ git merge master

, который обновит feature1, а затем feature2, где находится master - и вы не получите никаких конфликтов слияния, так как ониоба прямые предки мастера.

Важным моментом является то, что когда вы объединяете ветку в другую ветку, она изменяет только ту ветку, в которой вы находитесь (ту, в которую вы сливаетесь), а не ветку, в которую вы сливаетесь. Другими словами, еслив данный момент вы находитесь в «основной» ветке и объединяетесь с «feature1», она обновляет «master», но не «feature1».

Answer 2

В то время как на главном филиале я использую git merge feature1 и git merge feature2

В IMO произошло так называемое FF (Fast-Forward) -Merge.

со страницы MAN:

определение git merge:

git-merge - объединение двух или более историй разработки вместе

Что произошло:

FAST-FORWARD MERGE

Часто текущий руководитель ветви является предком указанного коммита.Это наиболее распространенный случай, особенно> когда он вызывается из git pull: вы отслеживаете вышестоящий репозиторий, вы не зафиксировали локальных изменений> и теперь вы хотите обновить его до более новой вышестоящей ревизии.В этом случае новый коммит не нужен для хранения> объединенной истории;вместо этого HEAD (вместе с индексом) обновляется, чтобы указывать на именованный коммит, без создания дополнительного коммита слияния.

Это поведение можно подавить с помощью параметра --no-ff.

( Source-Link )

Экскурсия: дополнительная информация о ветвях

Поскольку ветки являются не чем иным, как указателями на коммитыИ feature1 / feature2 являются предками master (как упоминалось ранее), нет никаких причин «копировать» коммиты (и, следовательно, историю коммитов).Более целесообразно просто перенаправить master -ответ (-pointer) на последний коммит.

Почему указатель master-branch не указывается на 3f38259 commit?

Я не совсем уверен, но я думаю:

git merge feature1

имеет параметр авто-фиксации (явный: --commit) по умолчанию.Итак, коммит создан.Кроме того, в master -ветвлении есть фиксация 2c88093, но не в feature2 -ответе, что позволяет не помещать указатель master -ответа только на коммит 3f38259 feature2 для получения чего-то вроде

3f38259 feature2 master(*)

Если бы вы явно перенаправили master на ветку 3f38259, вы бы "потеряли" коммит 2c88093 в своей истории.

Answer 3

«Уже в актуальном состоянии» означает, что одна ветвь в предке другой, все изменения одной ветки уже находятся в другой.
со страницы руководства git merge :

Если все именованные коммиты уже являются предками HEAD, git merge рано выйдет с сообщением «Уже обновлено».

Здесь HEADfeature1 является предком master (master имеет новую работу, сделанную из feature1 HEAD).
Таким образом, git merge feature1 приведет к сообщению "Уже обновлено".

Что касается feature2, ваш журнал графиков показывает, что он был объединен в какой-то момент в master.
Попытка повторить объединение также приведет к «Уже обновленному».

Answer 4

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

Answer 5

Как заставить Git зафиксировать различия в ветке feature2 в моей основной ветке, когда он считает, что изменения в master в настоящий момент самые последние и самые большие?

возможно git rebase это то, что вы ищете? Ссылка

Answer 6

Вы можете проверить ветку master, убедиться, что все ваши изменения зафиксированы, а затем попробовать

git pull . feature1 feature2

Но я сам не специалист по git, поэтому я не мог с уверенностью сказать вам, что это будет делать. Я имею в виду, я знаю, что он должен объединиться feature1 и feature2 в master, но я не могу гарантировать, что он объединит их именно так, как вы хотите.

Я бы посоветовал сначала сделать резервную копию хранилища, на всякий случай. Хотя я полагаю, что вы всегда можете git reset --hard HEAD^ потом, если что-то пойдет не так.

Answer 7

Вы находитесь в ветке 'master' при выполнении команды слияния?

git checkout master
git merge feature1
git merge feature2