Как вы справляетесь с ситуациями, не требующими быстрой пересылки, в рабочем процессе git rebase?

Question

Я читал о git rebase и преимуществах использования рабочего процесса rebase вместо рабочего процесса слияния.(На самом деле я не сталкивался с приведенными ниже ситуациями, так как я новичок в git)

Я читал, что один из стандартных рабочих процессов для проектов с несколькими участниками заключается в том, чтобы участник регулярно регулярно rebase писал ихветка с мастер веткой "основной (центральный / правда / канонический) репозиторий".Перебазирование перед выполнением запроса на извлечение приводит к быстрому продвижению слияний.

Хотя эта часть имеет смысл для меня, я вижу много ситуаций, когда слияния не будут быстрыми вперед.Я хочу знать, что происходит в этих ситуациях.Перетаскивает ли хозяин проекта (владелец канонической ветви) ветвь темы в локальную ветвь, rebase и merge (чтобы убедиться, что она остается ускоренной перемоткой вперед), или менеджер проекта просто не выполняет перемотку вперед?merge?

Как только участник перезагружает и помещает свою ветку темы в общедоступный репозиторий, нажатие второй rebase становится невозможным.Что произойдет, если те, кто просматривает вклад, захотят увидеть часть кода, улучшенную / настроенную перед слиянием?Основная ветка, вероятно, изменилась бы к тому времени, когда участник вносит исправления, и участник не может rebase, поскольку это будет означать переписывание истории общедоступного репозитория.

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

Подводя итог моему вопросу: Что происходит в ситуациях, когда ветвь, которую необходимо подтянуть, не основана на master и не может быть перебазирован участником?Проводит ли менеджер проекта самосовершенствование перед слиянием или просто выполняет слияние без ускоренной перемотки?

Answer 1

GitHub решил эту проблему, позволив участникам:

• иметь свое собственное репо на стороне сервера (" fork "), где они могут git push --forceв глубине души)
• для предложения патчей ( запросов на получение ) для основного репо (не для веток, только для фиксации, которые будут применены или нет), и таким образом, чтобы сопровождающий моглегко увидеть, можно ли применить эти патчи в ускоренном режиме или нет.

В случае, если разветвление невозможно, вы упоминаете:

Один разучастник перебазирует и помещает свою ветку тем в общедоступный репозиторий, продвинуть вторую перебазирование невозможно.

Нажатие должно быть возможным, возможно, сначала удалив опубликованную ветвь, а затем заново создайте ее, нажав ее снова.
Пока указанная ветвь была перебазирована поверх канонической ветки,новую ветвь можно будет объединять с ускоренной перемоткой.

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

Answer 2

Я думаю, для всех было бы проще, если бы участник получил новый master и поместил свои исправления в новую ветку.Это позволило бы менеджеру быстро выполнить слияние FF и завершить его.Если менеджеры похожи на меня, это будет ближе всего к фактическому источнику:)

Answer 3

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