Комментарии 14
Уважаемый автор, попробуйте использовать GitKraken (Git GUI). Он тоже так умеет
Вопрос на засыпку. Допустим я надергал из ветки feature в ветку main багфиксов. Далее я продолжаю разработку в ветке feature. В какойто момент разрабатываемая фича признается годной для вноса её в основную ветку и в этом случае обычно делается merge ветки feature с веткой main. Но, в основной ветке уже есть кучка надерганных ранее коммитов из ветки feature. Возникнет ли в этом случае конфликт и как его правильно разрезолвить ? Логично было бы удалить из главной ветки то, что было надергано и продолжить merge, но, на сколько я понимаю, постого способа для этого нет. Или есть ?
Если из главной удалить фиксы, то при таком мерже они не восстановятся. Я как то раз переносил черрипиками кучу коммитов, потомучто ветки давно разошлись и смержить их было невозможно. Зато от этой главной ветки все остальные подтянули изменения без проблем
по-моему гит сам это резолвит.
Но у меня появились сомнения, т.к. как автор и сказал - новый коммит теряет связь со старым. Но гит ведь все же узнает как-то перенесен ли уже коммит в команде `git checkout -v master feature`. Возможно сравнением исходников просто.
Интересный вопрос! Спасибо что спросили) Сами по себе конфликты возникают, если в одной и той же строке кода были сделаны изменения, и при этом, эти изменения расходятся. В самом простом и идеальном случае, если черри-пикнуть из feature ветки коммит в main, затем добавить еще коммитов в feature, после чего смерджить, то конфликтов возникнуть не должно, так как bugfix-коммит в feature ветке и bugfix-коммит в main ветке будут содержать идентичные изменения. Но это в идеально случае.
В реальности же, вероятнее всего, конфликты могут быть, просто потому что те же самые строки впоследствие могут быть снова изменены в ветке feature.
На черри-пик коммит в этом случае можно смотреть просто как на коммит, который кто-то сделал в ветке main. И если ваши финальные изменения, которые мерджатся из ветки feature никак не конфликтуют с изменениями в коммитах main, то все будет ок.
Решил для верности потестировать (репо):
- мердж ветки feature прошел с конфликтом из-за того, что нечаянно где-то тронул пустые строки (дифф)
- мердж ветки feature_2 прошел без конфликтов (тот самый "идеальный" случай)
- мердж ветки feature_3 прошел с конфликтом, так как в финальных изменениях ветки feature "перезаписывались" те же строчки кода, которые ранее были перенесены коммитом в main (дифф).
На всю историю репозитория удобнее всего посмотреть во вкладке Repository graph
Логично было бы удалить из главной ветки то, что было надергано и продолжить merge,
Как по мне, то логичнее сделать rebase для feature на текущий master. Git в этом случае перенесенные cherry-pick коммиты просто проигнорирует, будто их и не было (если, конечно, после cherry-pick в тех же строках ничего не менялось). Заодно и merge в master быстрой перемоткой после этого сделать можно.
Будут. Потому что черрипик коммит, это новый отдельный коммит по сути с тем же патчем. То есть при мерже будет конфликт, когда слева строка добавлена, и справа та же самая строка добавлена. То есть конфликт есть, но он автоматически разрешится. В этом и есть основное неудобство черрипиков, почему по возможности стоит пользоваться мержем.
✅ Подходящие случаи:
Лично я использую cherry-pick для модификации проекта с примерами использования моей библиотеки на C#. На GitHub публикуется версия, ссылающаяся на NuGet-пакет библиотеки, но во время разработки делать по каждому чиху пакет, пусть даже локально, непрактично. Потому рабочая версия проекта примеров в отдельной ветке у меня имеет ссылку на проект библиотеки с его текущей DLL, а после завершения и публикации нового пакета библиотеки я переношу все изменения в публикуемую ветку проекта примеров как раз с помощью cherry-pick (и заменяю в ней версию пакета, на новую опубликованную). Благо в VS 2022, наконец-то, довели git-овский плагин до ума, и можно делать cherry-pick, не переключаясь в косоль.
Любителям черри-пикинга обязательна к прочтению статья Раймонда Чена Stop cherry-picking, start merging
Там описаны неочевидные подводные камни такого процесса и показано как правильно их избежать.
Мастер-класс по точечному переносу изменений между ветками в git