Когда безопасно перебазировать выдвинутую функциональную ветку

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

Так каковы последствия?

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

Я перечислил некоторые вещи, которые мог придумать. Пожалуйста, поправьте меня и добавьте еще, если знаете.

  1. Кто-то разветвился / перебазировал мою ветку: они получают незапрошенное перебазирование своей ветки при следующем запуске
  2. Кто-то объединил мою ветку со своей: они неожиданно получили измененную фиксацию слияния и, следовательно, возможные конфликты при следующем запуске.
  3. Кто-то выбрал коммит: ???
  4. Был открытый запрос на слияние / вытягивание: теперь указывает на перебазированную ветку ???
  5. Материал, связанный с коммитами в Issues, MR / PR, Platform-Markdown: указывать на обновленные файлы / коммиты?
Стоит ли изучать PHP в 2023-2024 годах?
Стоит ли изучать PHP в 2023-2024 годах?
Привет всем, сегодня я хочу высказать свои соображения по поводу вопроса, который я уже много раз получал в своем сообществе: "Стоит ли изучать PHP в...
Поведение ключевого слова "this" в стрелочной функции в сравнении с нормальной функцией
Поведение ключевого слова "this" в стрелочной функции в сравнении с нормальной функцией
В JavaScript одним из самых запутанных понятий является поведение ключевого слова "this" в стрелочной и обычной функциях.
Приемы CSS-макетирования - floats и Flexbox
Приемы CSS-макетирования - floats и Flexbox
Здравствуйте, друзья-студенты! Готовы совершенствовать свои навыки веб-дизайна? Сегодня в нашем путешествии мы рассмотрим приемы CSS-верстки - в...
Тестирование функциональных ngrx-эффектов в Angular 16 с помощью Jest
В системе управления состояниями ngrx, совместимой с Angular 16, появились функциональные эффекты. Это здорово и делает код определенно легче для...
Концепция локализации и ее применение в приложениях React ⚡️
Концепция локализации и ее применение в приложениях React ⚡️
Локализация - это процесс адаптации приложения к различным языкам и культурным требованиям. Это позволяет пользователям получить опыт, соответствующий...
Пользовательский скаляр GraphQL
Пользовательский скаляр GraphQL
Листовые узлы системы типов GraphQL называются скалярами. Достигнув скалярного типа, невозможно спуститься дальше по иерархии типов. Скалярный тип...
1
0
290
1

Ответы 1

Последствия для людей, которые основывают свою работу на вашей ветке до перебазирования. Подумайте, что произойдет, если вы сделали 3 ревизии в своей функциональной ветке, а разработчик B затем запустил ветку из вашей ветки и выполнил 3 коммита ... затем вы перебазируете ... затем, в конечном итоге, ваша ветка будет объединена, скажем, с master. Приятно ...... что другой разработчик заканчивает после 3 ревизий и просит слиться. Как будет выглядеть история, если эту ветвь объединить напрямую? У него будут дубликаты для ваших 3 коммитов (исходные ревизии и те, которые появились после вашего перебазирования) ... не лучшее, что нужно иметь, верно? В этом случае другой разработчик должен был выполнить перебазирование поверх вашей перебазированной ветки или мастера после того, как они были объединены. Другой сложный сценарий - это когда вы переустанавливаете общую ветку и никому об этом не говорите. Предположим, вы исправляете последние 3 версии мастера и нажимаете принудительно, чтобы заменить общий мастер .... если у вас есть разработчики, которые уже работают с исходным мастером, когда они попытались отправить изменения в эту ветку, они не будут разрешено, потому что ветки разошлись, и они не объединили новый мастер (и им лучше этого не делать, потому что вы снова получите дублирующиеся ревизии ... они также должны быть перебазированы).

Лично мне? Я думаю, что все должно быть перебазировано, когда это имеет смысл ... усложнение для людей, работающих над одним и тем же проектом, не должно быть серьезной проблемой, поскольку решение таких проблем включает только выполнение одной операции перебазирования: git rebase --onto new-rebased-branch old-rebased-branch my-branch. Таким образом, не похоже, что очень сложно перемещать вещи после того, как ветка была перебазирована. Уловка состоит в том, чтобы заставить других разработчиков знать, что история переписывается, чтобы они могли перебазировать свою ветку.

eftshift0 19.10.2018 15:20

Другие вопросы по теме