Можно ли вечно использовать одну и ту же локальную ветку? - PullRequest
Новая
       73

Можно ли вечно использовать одну и ту же локальную ветку?

2 голосов
/ 04 февраля 2020

Мы недавно перешли на git из Team Foundation Version Control. Я обнаружил тенденцию в нашей команде разработчиков хотеть сделать локальную ветвь из локального мастера, назвать ее local-dev и затем использовать эту ветку навсегда. Мы используем процесс pull-запроса, поэтому они помещают sh свой local-dev на сервер и выполняют pull-запрос на master.

Когда pull-запрос завершается, они удаляют ветку server-dev, но сохраняют свою ветку local-dev. Они просто загружают последние данные в своего локального мастера, а затем объединяют локального мастера в local-dev. Затем повторите цикл.

Это нормально? В своей голове я вижу, что, поскольку их local-dev никогда не перебазируется, они непрерывно помещают всю историю, начиная с первого дня, на сервер каждый раз, когда они делают запрос на извлечение и вынуждают сервер обрабатывать это слияние. Что, кажется, работает хорошо.

Это бомба замедленного действия? Это вполне приемлемо, и я ни о чем не беспокоюсь? Что делает сервер для обработки этого слияния?

Ответы [ 3 ]

3 голосов
/ 04 февраля 2020

Git использует ревизионную прогулку для согласования общего набора коммитов с обеих сторон. Так что если во время pu sh клиентская сторона знает, что такое ветвь master сервера, то она сможет исключить отправку всего, что оно содержит, включая старую версию ветки local-dev.

Используемый рабочий процесс не обязательно неэффективен для толчков, но повторяющиеся перекрестные слияния между master и ветвью local-dev делают git log --topo-order очень медленным. Таким образом, хотя это не может быть проблемой для неопытных пользователей Git, это сделает опытных пользователей немного несчастными, поскольку вызывает некоторую медлительность в продвинутых операциях. Он также создает неопрятную историю, к которой некоторые люди относятся очень сильно.

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

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

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

0 голосов
/ 04 февраля 2020

Краткий ответ: НЕТ .

Предлагаемый метод.

  • Новая ветвь должна быть создана как новая ветвь. Разработчик должен работать над этой веткой
  • Запрос на извлечение должен выполняться либо с веткой разработки, либо с основной веткой. Я отбросил ветку разработки и создал запрос на ветку master. И разрешение на слияние с мастером ограничено, поэтому риск смягчается. Если бы не было никакой опции, я бы сохранил ветку разработки и создал запрос на извлечение с веткой разработки.
  • После утверждения и перед выпуском создайте ветку релиза из master, создайте запрос извлечения из ветви функций в ветку релиза, утвердите, объединение.
  • Выпуск ветки выпуска
  • Создание запроса на извлечение с основной веткой и веткой разработки (если есть)
  • Когда менеджер по продукту или производитель удовлетворены выпуском, создайте вытяните запрос от релиза к мастеру и продолжайте свою жизнь 
                     Release branch
                /--------- <- Release ------------ 
master branch  /        /merge with release  \  \  merge feature with master
-----------------------/-----------------------  \
               \ Feat / ure branch                \
                \---------------                   \
                      \  for review purpose only    \
development branch     \   (parallel to master)      \ merge feature with dev
------------------------------------------------------------

извините, выгляните грязно

0 голосов
/ 04 февраля 2020

Если они перебирают origin / master каждый раз, когда выбирают несколько функций, то это не так уж и вредно, так как полная история их собственной локальной-dev ветви делится с master.

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

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

Личная нота всегда удручает, когда члены команды застряли на своем пути и не хотят попробуйте (или даже протестируйте) новые рабочие процессы. Звучит как токси c окружение.

...