Расскажите пожалуйста, что может произойти, если ответвить ветку от родительской с текущим кодом, а потом изменить родительскую ветку?

Question

[ChipiLina]

Работаю над проектом и появился такой вопрос, который не хочу проверять на своём проекте - вдруг что сломается.
Например, есть ветка develop со стабильным кодом, от неё ответвляется ветка feature/FEATURE_NAME для написания новой функции. А что если после ответвления изменить ветку develop, а потом слить туда изменения из feature/FEATURE_NAME? Возникнут ли конфликты и если да, то как их можно решить?

Comments

[Сергей delphinpro]

Конфликты могут возникнуть, если в обоих ветках были изменены одинаковые участки кода, и гит не смог самостоятельно определить, какой вариант следует оставить.
Тогда вы должны будете при слиянии вручную разрешить конфликты (по сути отредактировать конфликтные файлы, в которые гит вам накидает по две версии кода) и застейджить их.

[Василий Банников]

Сергей delphinpro, напишите в ответы

Answer 1

[Сергей delphinpro]

Конфликты могут возникнуть, если в обеих ветках были изменены одинаковые участки кода, и гит не смог самостоятельно определить, какой вариант следует оставить.
Тогда вы должны будете при слиянии вручную разрешить конфликты (по сути отредактировать конфликтные файлы, в которые гит вам накидает по две версии кода) и застейджить их.

Answer 2

[lolrofl01]

Странный вопрос. Конфликты возникнут только если один и тот же файл был изменен в обеих ветках. Если, например, на одной ветке вы пилили модуль загрузки, а на другой - модуль выгрузки, то конфликтов никаких не будет (надеюсь, они в разных файлах?). Что касается мержа одинаковых файлов - тут вручную надо выбрать какой код оставить, какой убрать, или же оставить оба варианта кода, объединив их в один файл.

Answer 3

[Сергей Кузнецов]

вдруг что сломается

Если вы работаете в Git то вы ничего не можете сломать. Не бойтесь экспериментировать.
А тематические ветки на то и придуманы, чтобы в них отлаживать фичу перед отправкой в главную ветку.

Возникнут ли конфликты и если да, то как их можно решить?

Могут возникнуть, а могут и нет. В любом случае — конфликты это хорошо, это нормальный рабочий процесс. И конфликты разрешаются инструментом разрешения конфликтов или просто руками в текстовом редакторе. Чтобы не ломать общую ветку, можно предварительно забрать обновления оттуда к себе в тематическую, разрешить конфликты, прогнать тесты, и уже потом слить работу в основную ветку. Тогда конфликтов уже не будет.

Comments

[Vitsliputsli]

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

[Сергей Кузнецов]

Vitsliputsli, вопрос в том, как работать, чтобы конфликтов было меньше.

• Делать мелкие атомарные коммиты, а не пихать всю задачу в один коммит.
  
• Почаще подгружать к себе обновления из основной ветки.
  

Ещё советую включить фичу rerere, чтобы Git запоминал как вы решаете конфликты и при повторении их, он повторял бы работу самостоятельно.

[Vitsliputsli]

Сергей Кузнецов, ну так, я ж про это и писал.
Что касается rerere, не представляю где это может понадобится. Решать одни и те же конфликты повторно - это какой-то мазохизм, при нормальном git flow такое не нужно.

[Сергей Кузнецов]

Vitsliputsli, не существует какого-то идеального и единственно-правильного flow ))
Рабочие процессы могут отличаться в разных командах.
Rerere помогает легко делать частые rebase короткоживущей тематической ветки вместо захламления истории множеством коммитов слияния.
Можно придумать и другие сценарии где он полезен.

[Vitsliputsli]

Сергей Кузнецов, спасибо, понял.
Не существует, но я не сторонник перезаписи истории ради красивой картинки.

[Сергей Кузнецов]

А я сторонник прозрачной и простой истории. Усложнять граф означает увеличивать шансы на случайные ошибки и добавлять дополнительную работу тем, кто будет читать код после нас. Но это скорее уже религиозный вопрос, оставим его адептам покойного Mercurial.