Как переписать ветку разработки с историей главной ветки

Question

Задача

В нашем рабочем процессе есть ветвь разработки, которая время от времени наполняется функциями. Иногда эти функции никогда не будут объединены с мастером, потому что они не будут работать или функция была удалена.

Поэтому ветка разработки состоит из ненужных коммитов.

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

Довольно часто это просто не работает. Потому что некоторые разработчики болеют или находятся в отпуске и по возвращении они пропускают электронное письмо с описанием этого события. Они заканчиваются путаницей.

Вопрос

Как мы можем очистить ветку development , чтобы иметь только те коммиты, которые равны ветке master . На самом деле он должен содержать ту же историю коммитов, что и в тот момент, когда мы только что извлекли бы ее из главной ветки.

Answer 1

На самом деле он должен содержать ту же историю коммитов, что и при новой проверке в основной ветке.

Если вы действительно хотите, чтобы ветвь development была идентична ветке master, вы можете сбросить ее:

git checkout development
git reset --hard master

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

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

Answer 2

Вы можете переписать историю ветки development, чтобы произвольно указать на тот же коммит, который делает master, с этого момента у них будет точно идентичная история.

git branch -f development master

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