Несмотря на все усилия, мы попали в затруднительное положение с функциональной веткой в нашем репозитории Git. Конечным результатом является то, что git diff develop..feature-branch показывает совершенно неожиданную разницу.
Например, один файл, который был добавлен при разработке, отображается как удаленный в файле diff. Многие другие файлы показывают аналогичные проблемы, некоторые отсутствуют, некоторые добавлены, много неожиданных изменений. Некоторые файлы, которые должны были быть в develop, даже не отображаются в diff. Впервые мы заметили проблему в Atlassian Stash, когда отправились проверять код с помощью запроса на слияние. Ожидающее слияние полностью и совершенно неверно и не может быть разрешено с помощью стандартного разрешения конфликтов во время слияния.
Мы попытались расшифровать, что вызвало это, и считаем, что проблема связана с тем, что разработчик выполнил несколько сбросов коммитов в ветке функций, которые уже были отправлены в источник. Это должно было «отменить» некоторые изменения, предложенные во время проверки кода запроса на вытягивание. В частности, мы считаем, что это хронология событий.
- Ветка Feature создана из разработки
- Работа, выполненная на функциональной ветке
- Запрос на вытягивание, созданный в Atlassian Stash (PR выглядит нормально, но предлагаются некоторые незначительные правки)
- Разработчик использует сброс, чтобы отменить некоторые изменения, и отправляет их в исходное состояние.
- Тем временем замечены небольшие конфликты между ветками разработки и фичей.
- Обновления для разработчиков включают ветку от разработки для разрешения конфликтов и отправки к источнику.
- Запрос на включение (diff) показывает неожиданный diff, резко отличающийся от предыдущего. Файлы, которые должны быть зафиксированы, отсутствуют, и наоборот
- Я пытаюсь отменить (вернуть, а не сбросить) «плохое» слияние и повторить попытку. Однако PR/diff показывает те же неправильные изменения для ожидающего слияния.
- Затем я узнаю, что разработчик использовал сброс где-то до первого слияния из разработки.
Итак, у меня три вопроса.
Как нам нужно «восстановить» исправленную ветку функций, чтобы мы могли правильно объединить наши изменения в разработку? Моя идея состоит в том, чтобы создать новую «хорошую» ветку функций из фиксации в нашей ветке функций, которая, как известно, происходит до сброса. Затем я могу выбрать нужные коммиты из «плохой» ветки функций в «хорошую», чтобы воссоздать их. Наконец, я могу объединить «хорошую» ветвь функции с разработкой и удалить «плохую».
Если бы я объединил «плохую» ветвь функций с разработкой, помимо неправильного состояния файлов, не было бы других «повреждений», просочившихся в ветку разработки. То есть, будет ли загрязненная «плохая» ветка функций еще больше загрязнять ветку разработки и все, что ниже по течению от нее? Я не планирую этого делать, конечно, но я хочу понять последствия.
Будут ли сбросы, как я их описал, вызывать проблемы, которые я вижу, или это, возможно, связано с чем-то другим?
