# #git #gitlab
Вопрос:
Вот последовательность действий:
- Создайте новую ветвь, выйдя из master
- делаю свои обновления ..
- Необходимо перенести эти изменения в отрасль разработки
- Я попытался встать на ветку разработки, а затем объединить свою новую ветку, но я сталкиваюсь со слишком большим количеством конфликтов, которые привели к различиям между разработкой и мастером, мне нужно только продвигать свои изменения, не устраняя все различия между разработкой и мастером.
- Я попытался проверить свою ветку разработки и снова внести изменения (скопировать и вставить), затем зафиксировать, это работает, и пусть мои ветки работают, но я ищу другой подход для сохранения дубликатов работы, что-то вроде слияния master мои обновления для разработки без разрешения каких-либо других конфликтов.
Мне нужно сохранить свою ветку и быть готовым к слиянию с мастером после проверки 2-м глазом членов моей команды, поэтому мне не нужны никакие другие изменения из ветки разработки, чтобы быть в моей ветке.
Комментарии:
1. Не уверен, что понимаю, с чего вы начинаете делать изменения
masterв первую очередь. Просто начните с ветки разработки. Хотя, возможно, вам захочется взглянутьgit rebase --onto.2. Зачем вам переходить от мастера и переходить к разработке?
3. И если вы должны делать такие вещи, что плохого в разрешении конфликтов? Просто разрешите их. Это нормально.
Ответ №1:
Вы можете упростить процесс, используя меньше ветвей. По одному на выпуск или только одна ветвь-хорошие подходы.
Несколько подходов:
Подход 1. Только освобождаемый код передается на освоение. В промежутках между выпусками команда работает над одной ветвью для следующего выпуска. Когда он готов, его толкают к освоению. Затем создается новая ветвь для следующего выпуска.
Подход 2: Весь код передается в магистраль. Теги используются для маркировки выпусков. https://trunkbaseddevelopment.com/
Ответ №2:
Если вы хотите, чтобы разработка стала (предыдущая версия разработки плюс ваши изменения), то я согласен с приведенным выше комментарием, в котором говорится, что вы должны начать свою ветку с ветки разработки.
ОДНАКО вы сказали, что хотите объединить свою ветвь функций для освоения без изменений, существующих в разработке. В этом случае вам не нужно объединяться, чтобы развиваться. Просто попросите свою команду просмотреть вашу ветвь функций, а затем объединиться непосредственно с мастером.
ЗА исключением случаев, когда вам также понадобятся эти изменения в разработке, вам нужно будет либо объединить master в development после объединения изменений в master, ЛИБО вы можете перейти от разработки, объединить в разработку и в конечном итоге объединить разработку в master.
Основная проблема здесь заключается в том, что мы не можем дать хороший ответ на ваш вопрос, если мы не знаем, какова ваша политика/стратегия ветвления.
К сожалению, похоже, что вы, возможно, не четко определили политику ветвления, в которой указано, когда, где и как вы хотите, чтобы функции создавались и объединялись.