Avoding других членов команды фиксирует в моем слиянии

Question

Я недавно перешел из TFS в Git и мне это очень нравится.

Моя команда на работе использует git-flow. Для каждой функции мы создаем ветку объектов. Однако одна вещь, которая иногда случается, заключается в том, что при перемещении ветви функций и создании запроса извлечения в master возникает конфликт слияния. Чтобы разрешить этот конфликт слияния, я синхронизирую ветку master с удаленным и сливаю master с моей веткой функций и решаю этот конфликт слияния.

Но теперь в моих исходящих коммитах не только у меня будет«исправление конфликта слияния», но у меня также будут все остальные коммиты в master, которые были сделаны в тот же запрос на извлечение.

Потому что, если я объединю свою локальную ветвь с моей локальной master и нажму на master, я пропущу запрос на извлечение (даже если это технически возможно здесь), но это не так. Я ошибаюсь?

Эта проблема не только во время конфликтов слияния - я думаю, это просто о синхронизации ветви функции с master. Как другие люди решают это? Я слышал о перебазировании, но, похоже, его редко используют в моей команде.

Answer 1

Комментарий Флиппа является правильным: это нормально, потому что то, что вы видите (в Visual Studio, я полагаю?), Это любые коммиты в вашей ветви функций, которые еще не были переданы на удаленный компьютер.

Ваша история коммитов может выглядеть примерно так:

A--B--C--D--E [master, origin/master]
 \           \
  X--Y--Z-----M [feature/mine]
         \
         [origin/feature/mine]

В тех случаях, когда ваша работа над функциональной ветвью фиксирует от X до Z, а коммиты от B до E на мастере были чужой работой.

Когда вы упоминаете "исходящие коммиты", это, вероятно, сравнивает вашу локальную ветку feature/mine с удаленной origin/feature/mine. Последний «содержит» коммит A и все, что перед ним, а также ваши изменения X, Y и Z. Ваша локальная ветвь, в настоящее время находящаяся в коммите M, также содержит от B до E, поскольку вы слили эти изменения в свою ветвь функций,вот почему вы видите эти коммиты, перечисленные там.

Это не проблема, потому что Git все еще отслеживает, кто создал коммиты от B до E, вы волшебным образом не претендовали на владение ими или чем-то еще. Кроме того, поскольку эти коммиты уже содержатся в origin/master, они уже находятся на сервере, поэтому вам не нужно будет их снова нажимать.

---

Я бы также рекомендовал вам рассмотреть возможность перебазирования вместослияния. Если бы вы были на feature/mine в коммите Z, вы могли бы сделать:

git rebase master

После разрешения любых конфликтов и завершения перебазировки ваша история может выглядеть так:

A--B--C--D--E [master, origin/master]
 \           \
  \           X'--Y'--Z' [feature/mine]
   \
    X--Y--Z [origin/feature/mine]

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

git push --force-with-lease

, чтобы обновить удаленную ветвь функций.

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

Обратите внимание, что в этом случае ваша ветвь функций по-прежнему содержит коммиты от B до E, онипросто наследуется от master, а не входит через коммит слияния. Это нормально и желательно: единственный способ разрешить конфликт слияния - это внести изменения в вашу ветку, где с этим конфликтом можно разобраться.