Рабочий процесс Геррита

Я следил за версией модели ветвления, найденной на nvie.com. По сути, я делаю ответвление от стабильной точки ветки разработки, работаю над функцией, а затем снова объединяюсь, исправляя любые возникающие конфликты слияния и предоставляя подробный обзор того, что влечет за собой эта функция.

Сейчас я начал использовать Gerrit, и эта модель не работает. Слияние функциональной ветки с веткой dev приводит к тому, что на Gerrit появляется только сообщение о коммите. Предполагая, что это задумано, каков рекомендуемый рабочий процесс для Gerrit?

Я искал ответы вверх и вниз и не получил ничего, кроме двух несовершенных решений:

  • раздавленные коммиты (git merge --squash)

    Не идеально, так как он не связан с исходной веткой и приводит к возмутительно длинному сообщению коммита.

  • перебазируется на dev. (git rebase [dev])

    Не идеально, так как это связано либо с большим количеством небольших сообщений о фиксации, размещаемых на dev, либо с потерей детализации (и истории) в ветке функций, если я раздавлю некоторые сообщения о фиксации.

Вся помощь будет оценена по достоинству.


git git-merge gerrit git-rebase
person stephenfin    schedule 07.11.2013    source источник
comment
Не могли бы вы пояснить, что вы имеете в виду под слиянием функциональной ветки с веткой разработки, в результате чего на Gerrit появляется только сообщение о коммите? На работе мы используем Gerrit с ветками функций и не видим проблемы, которую вы описываете.   -  person Greg Hewgill    schedule 08.11.2013
comment
можно ли использовать непрерывную интеграцию, поэтому совершив ветку разработки?   -  person laplasz    schedule 08.11.2013
comment
Когда я сливаюсь, я получаю фиксацию слияния (как и все). Однако нажатие этого показывает только сообщение фиксации (обычно первый элемент/гиль в обзоре) на Геррите... а не объединенные файлы. Единственное, что я знаю о том, что это может отличаться от других мест, это то, что шрифт моих веток разработки проходит через Gerrit, но скорее напрямую, то есть git push origin feature_x, а не git push origin HEAD:refs/for/feature_x   -  person stephenfin    schedule 08.11.2013
comment
Предполагая, что под CI вы подразумеваете регулярную интеграцию с разработчиком, я обнаружил, что это не очень работает при работе над большой функцией. Отправка только одной части набора изменений приводит к поломке тестов, что я бы не назвал приемлемым :/   -  person stephenfin    schedule 08.11.2013
comment
Стивенфин, я использую модель nvie с gerrit, и я не вижу проблемы с объединением ветвей функций с основным стволом, если ветвь функций покрывает все требования определения готовности. Это правда, что gerrit не показывает полную разницу между одной веткой и другой, но мы не видели в этом проблемы в моей организации.   -  person Rasmus Østergaard Kjær Voss    schedule 08.11.2013
comment
Вы должны перебазировать свои изменения поверх ветки разработки, прежде чем объединять ветку функций.   -  person Tim    schedule 13.11.2013
comment
@Jeff В идеале да, однако удаленный репозиторий Git, который я нажимаю, не допускает принудительного нажатия. Если я перебазирую, я не смогу сохранить эти изменения, нажав на пульт. Вместо этого я обычно объединяю из dev (для синхронизации) перед тем, как объединить в dev.   -  person stephenfin    schedule 13.11.2013
comment
Немного смущен, вам не нужно принудительно нажимать, поскольку вы не меняете историю.   -  person Tim    schedule 13.11.2013
comment
Я беру свои изменения из ветки, основанной на старой версии dev (например, HEAD~5), и воспроизводю их поверх текущей dev HEAD. Насколько я знаю, удаленную ветку нельзя перемотать вперед с такими изменениями?   -  person stephenfin    schedule 13.11.2013
comment
Я знаю, что это старый вопрос, но не стесняйтесь проверить мое соответствующее улучшение: stackoverflow.com/a/65724774...   -  person bloody    schedule 18.01.2021

Ответы (1)


arrow_upward
0
arrow_downward

В gerrit вы не увидите затронутых файлов, если это фиксация слияния [слияние одной ветки с другой, которая не является быстрой перемоткой вперед, создает фиксацию слияния]. Вы можете проверить свою фиксацию, потянув ее в локальное репо [если вы попытаетесь выбрать ее, она покажет вам ошибку] ​​или проверить diff в gitweb.

person mrutyunjay    schedule 13.11.2013
comment
Итак, слияние все еще происходит, и код просто не отображается, потому что это слияние? Если это так, какая польза от Геррита? Вы не можете просмотреть код того, чего не видите? - person stephenfin; 13.11.2013
comment
Это не тот случай, когда вы все еще можете просмотреть свои коммиты слияния в gerrit. Для этого вам нужно нажать на ссылку gitweb. Вы получите эту ссылку в той же строке, в которой указан номер набора исправлений. Что-то вроде этого: Набор исправлений 1 (gitweb). Нажмите на ссылку gitweb, а затем выберите diff. - person mrutyunjay; 13.11.2013
comment
относительно вашего первого запроса Итак ... Если это так, то какой смысл в Геррите? В основном коммит слияния представляет собой комбинацию разных коммитов, т.е. он включает в себя более одного коммита, из-за чего вы не видите код для коммитов слияния. Кроме того, в отличие от простого коммита, коммит слияния имеет двух родителей. - person mrutyunjay; 13.11.2013
comment
В моей версии Gerrit нет ссылки на gitweb. Я подозреваю, что это потому, что я не использую gitweb или не имею плагина gitweb. Однако ваша точка зрения о двух родителях имеет смысл - это объясняет, почему отображается только сообщение фиксации. - person stephenfin; 13.11.2013
comment
Затем вам нужно вытащить эту фиксацию слияния в локальное репо для проверки. После того, как вы вытащите это изменение, вы можете выполнить команды git, чтобы проверить diff. - person mrutyunjay; 13.11.2013