Что касается альтернатив
git checkout iphone -b iphone31
git merge master
и
git checkout master -b iphone31
git merge iphone
они будут иметь одинаковую легкость или трудность, это все равно что спорить, наполовину полон стакан или наполовину пуст.
Восприятие дерева версий
То, как мы смотрим на деревья версий, в некотором роде - всего лишь наше произвольное восприятие. Допустим, у нас есть дерево версий, подобное следующему:
A----------+
| |
| |
\_/ \_/
B X
| |
| |
\_/ \_/
C Y
|
|
\_/
D
|
|
\_/
E
И предположим, что мы хотим, чтобы новая версия Z была извлечена из Y на основе изменений с C на E, но не включая изменения, сделанные с A на C.
«О, это будет сложно, потому что нет общей отправной точки». Ну не совсем. Если мы просто разместим объекты в графическом макете немного иначе, как это
/
C+---------+
| \ |
| |
\_/ |
D B
| / \
| |
\_/ |
E A
|
|
\_/
X
|
|
\_/
Y
теперь все становится многообещающим. Обратите внимание, что здесь я не менял никаких отношений, все стрелки указывают так же, как на предыдущем рисунке, и версия A по-прежнему является общей базой. Изменена только раскладка.
Но теперь тривиально представить себе другое дерево.
C'---------+
| |
| |
\_/ \_/
D B'
| |
| |
\_/ \_/
E A
|
|
\_/
X
|
|
\_/
Y
где задача состояла бы в обычном слиянии версии E.
Таким образом, вы можете объединить все, что захотите, единственное, что влияет на легкость или сложность, - это совокупность изменений, сделанных между тем, где вы выбираете в качестве отправной точки или общей базы, и тем, где вы сливаетесь. Вы не ограничены использованием естественной отправной точки, которую предлагает ваш инструмент управления версиями.
Это может быть непросто с некоторыми системами / инструментами контроля версий, но если все остальное не помогает, ничто не мешает вам сделать это вручную, проверяя версию C и сохраняя файл как file1, проверяя версию E и сохраняя файл как file2 , проверяя версию Y, сохраните файл как file3 и запустите kdiff3 -o merge_result file1 file2 file3.
Отвечать
Теперь для вашей конкретной ситуации трудно точно сказать, какая стратегия вызовет наименьшее количество проблем, но если есть много изменений, которые создают какой-то конфликт, вероятно, легче разделить и объединить более мелкие части.
Мое предложение заключалось в том, что, поскольку между последним работающим и iphone есть 32 коммита, вы могли бы, например, начать с разветвления мастера, а затем объединить первые 16 коммитов. Если это окажется слишком большой проблемой, вернитесь и попробуйте объединить 8 первых коммитов. И так далее. В худшем случае вы закончите слияние каждого из 32 коммитов один за другим, но это, вероятно, будет проще, чем обрабатывать все накопленные конфликты за одну единственную операцию слияния (и в этом случае вы работаете с действительно < / em> расходящаяся база кода).
Советы:
Нарисуйте на бумаге дерево версий и отметьте стрелками, что вы хотите объединить. Вычеркивайте вещи по мере их выполнения, если вы разделите процесс на несколько этапов. Это даст вам более четкое представление о том, чего вы хотите достичь, что вы уже сделали и что осталось.
Я действительно могу порекомендовать KDiff3, это отличный инструмент для сравнения / слияния.
person
hlovdal
schedule
28.02.2010
git checkout -b iphone31эквивалентноgit checkout iphone -b iphone31? - person Gerald schedule 21.05.2015