Как просмотреть сотни коммитов и формализовать запрос (ы) слияния

В моей работе каждая строка кода должна быть пересмотрена, и этот обзор формализован в запросе слияния.

Теперь мы столкнулись с ситуацией: один разработчик разработал прототип нового продукта, который сейчас идет на производство. Есть несколько сотен коммитов, и много строк изменилось в одной ветке. Мне интересно, как лучше всего рассмотреть код, формализовать его с помощью запроса на объединение и сохранить относительно чистую историю.

Я подумал о двух путях:

  1. Самый простой способ - просмотреть весь существующий код, выполнить запрос слияния и объединить ветвь прототипа в master (или ветку разработки). Это решение потребует времени, пока оно не будет полностью завершено, и может быть подвергнуто психологическому налогообложению для рецензентов, но сохраняет историю git.
  2. Другим способом, который, как я думал, будет рассмотрение компонента по компоненту. В новой ветви мы создаем новую историю, мы совершаем по одному компоненту и выполняем несколько запросов на слияние. Это решение позволяет нам видеть прогрессию и формализовать, что каждый компонент проверен (а не только большой кусок работы), но мы будем писать новую историю git, которая может вызвать проблему слияния.
1 голос | спросил Jason Marechal 11 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowTue, 11 Sep 2018 11:10:57 +0300 2018, 11:10:57

1 ответ


3

Просто нормальный маршрут. Разработчик выдает запрос на извлечение; Вы знаете, где этот пул-запрос должен быть в конечном итоге объединен. Могут быть конфликты, в этом случае разработчик должен исправить эти конфликты и обновить запрос на удаление.

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

Затем вы просматриваете, что займет некоторое время, и объединитесь. Ваш отзыв может быть сделан так, как вам нравится. Такое большое изменение, вероятно, не может быть рассмотрено, глядя на различия. Один способ, который мне подходит: создайте две папки, одну для старой ветви, одну для ветви, которая должна быть объединена. Полностью вне git control Используйте хороший инструмент diff, чтобы фактически переместить изменения в старую ветку. Как «Новая ветвь добавила файл X», поэтому я добавляю пустой файл X к старой ветке. «Файл X содержит новую функцию f», поэтому я перемещаю эту функцию f в старую ветвь и т. Д. Очевидно, что вы не делаете это вслепую, когда добавляете функцию f, вот где вы ее проверяете.

ответил gnasher729 11 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowTue, 11 Sep 2018 12:14:44 +0300 2018, 12:14:44

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132