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

команда, с которой я работаю, не принимает тот факт, что ветвь master должна быть объединена с develop, чтобы согласовать develop с исправлениями / исправлениями ошибок master.

Они напуганы тем, что когда они каким-то образом объединят master (наша стабильная производственная ветвь) с develop (ветвь со всеми объединенными ветвями функций, которые еще не развернуты в производственную среду), впереди работа над develop, который еще предстоит протестировать, может быть потерянный.

И это происходило несколько раз (правда, не со мной), когда кто-то из нашей команды сказал нам: «Я объединил master с develop, и это отменило предстоящие изменения, сделанные в develop X (другим разработчиком)».

Итак, я предполагаю, что, возможно, кто-то использует git неправильно, поскольку у меня не было этой проблемы, когда я объединяю master в develop, каким-то образом приводя develop к старой версии без тестирования нового материала, который был там до слияния .

Есть мысли и идеи о том, почему это могло произойти? Как вы думаете, с какой проблемой мы иногда сталкиваемся, когда объединяем master в develop?

Я знаю, что master следует снова включить в разработку, как только появится исправление / исправление ошибок, иначе у develop не будет этого исправления. Мои коллеги продолжают утверждать, что это может привести к вышеупомянутой проблеме. Кто прав?

Но логически, если вы объедините master в develop, это то же самое, что объединить master в ваш feature-branch-1, а затем объединить эту ветвь feature-branch-1 в develop (вы просто переносите изменения, сделанные на master, в develop через третью ветвь, в данном случае feature-branch-1). . Как вы думаете?

Спасибо за внимание!

РЕДАКТИРОВАТЬ: Я все еще изучаю, пожалуйста, даже если я приму ответ, скажите, что вы думаете, я хотел бы получить как можно больше мнений по этому факту.

Фактически, в git flow вы не объединяете master обратно в develop. Исправления на главном сервере обычно cherry-pick возвращаются в разработку. Не то чтобы слияние должно вызывать описанные вами проблемы, но обычно вы не хотите засорять свою ветку develop всеми этими merge develop into master-коммитами ...

kowsky 11.04.2018 12:56

Я не понял вашу последнюю часть Not that a merge should cause the problems you described, but you usually don't want to pollute your develop branch with all those merge develop into master-commits..., не могли бы вы привести пример?

tonix 11.04.2018 13:01

@kowsky gitflow, как это описано, прописывает слияние хотфиксов. В любом случае, если вы выбрали что-то между ветвями, вам следует избегать их слияния, иначе вы получите конфликты вместо выбранного кода.

max630 11.04.2018 13:04

Ах ты прав @ max630. Я не знал об этом, поскольку слияние master с develop казалось несколько неестественным. Однако включение исправлений Cherry в разработку никогда не приводило к конфликтам при будущих слияниях develop и master. @tonix: Я имел в виду, что слияние master с develop должно быть возможным без проблем, мы просто предпочитаем выбор вишни из эстетических соображений, чтобы у нас никогда не было коммитов merge branch develop into master в истории нашей ветки разработки.

kowsky 11.04.2018 13:13

Итак, если вы говорите we just prefer cherry-picking because of aesthetic reasons so that we will never have, это означает, что слияние с master на develop (запись исправления на главном входе в hotfix-branch-*) фактически то же самое, что и разветвление нового hotfix-branch-* из master, сделайте исправление здесь, а затем слейте с develop, верно?

tonix 11.04.2018 13:52
0
5
149
1

Ответы 1

Поскольку есть реальный случай для расследования, вы можете воссоздать каждую ситуацию слияния. Проверьте родительский коммит из develop, объедините родительский коммит из master. Затем посмотрите, есть ли у вас тот же результат, что и в истории.

--A--C (develop)
    /
--B+ (master)

Для истории, приведенной выше, команды будут такими:

$ git checkout -B test_merge A
$ git merge -m "testing merge C" B
$ git diff C

Обратите внимание, что даже если слияние закончилось конфликтом, у вас должна быть возможность сразу запустить diff, чтобы оценить разрешение конфликта, или попытаться сначала разрешить его самостоятельно, а затем сравнить с записанной версией.

Мое предположение, что люди, которые жалуются на это, могут использовать некоторые флаги -X(ours|theirs) или средства разрешения конфликтов графического интерфейса, которые поощряют «выбрать сторону» одним щелчком мыши. Это неверно, тогда есть независимые изменения с обеих сторон (и если вы сделаете это правильно, у вас должны быть только независимые изменения).

Также неправильное разрешение может быть запомнено при повторном повторении, обратите внимание на строку типа «Решено '***' с использованием предыдущего разрешения»

But, logically, if you merge master into develop, it's the same as merging master into your feature-branch-1 and then merge this branch feature-branch-1 into develop (you are just bringing the changes made on master to develop through a third branch, in this case feature-branch-1). What do you think?

Я согласен. Нет никакой разницы. Это все частный случай каскадный рабочий процесс (по ссылке есть самоуверенное описание, но с красивой картинкой)

Спасибо! Не могли бы вы пояснить, как я могу проверить историю, чтобы узнать, что не так с каким слиянием? Какие команды мне нужно делать и что я должен видеть, когда нахожу изменение, которое отменяется более старым на develop?

tonix 11.04.2018 14:14

добавлен в ответ

max630 11.04.2018 14:38

Когда я это делаю, я вижу несколько удаленных файлов: Changes not staged for commit: ...deleted: some/file.phpdeleted: some/otherfilefile.php ... Что это тогда значит? Эти файлы все еще были удалены при фиксации A

tonix 11.04.2018 20:43

Я думаю, вам следует задать это как еще один вопрос с подробными деталями: что находится в A, что в B, что находится в их базе слияния, что вы видите при слиянии, отличается ли он от C, есть ли другие изменения между коммиты, которые могут повлиять на него из-за паршивого обнаружения переименования.

max630 11.04.2018 23:25

Вы правы, я думаю, мне нужно продолжить расследование, я также попрошу моего коллегу дополнительную информацию! И продолжайте публиковать любые обновления.

tonix 13.04.2018 00:58

Другие вопросы по теме