Недавно у меня была дискуссия с людьми, абсолютно не согласными со стратегией ребаз в ветвях функций GIT. Кажется, это приемлемый шаблон для использования rebase только для локальных, частных ветвей, но никогда не используйте его, когда над одной и той же функцией и ветвью работают несколько человек, согласно так называемому «Золотому правилу перебазирования» (как объяснено здесь: https : //www.atlassian.com/git/tutorials/merging-vs-rebasing/conceptual-overview )
Я просто удивлен, что есть консенсус по этому вопросу. Я работал 3 года с полной стратегией перебазирования, около 20 разработчиков работали вместе, и угадайте, что это сработало.
Процесс в основном:
- Вы создаете свою ветвь функций, давайте назовем ее «myfeature» и переместим ее в origin / myfeature
- Другие люди могут проверить это и работать над этим
- Иногда вы можете отменить его у мастера: из «myfeature», git rebase origin / master ; и тогда, да, вы должны подтолкнуть его.
- Что происходит, когда другие люди хотят подтолкнуть свои коммиты? Они просто перебазируют его: git rebase origin / myfeature . Таким образом, они теперь находятся в режиме ускоренной перемотки вперед и могут нажимать на них, не форсируя.
Единственный принцип уважения является то , что отрасль функции принадлежит кому - то . Владелец - единственный, кто может толкать насильно.
Итак, я признаю: как только появляется сила толчка, есть риск делать ошибки. Это правда. Но есть также много способов восстановления после ошибок, и действительно, за 3 года разработки я не видел много ошибок, требующих принудительного вмешательства, и когда это случалось, мы всегда находили способ исправить это правильно.
Итак, почему это «золотое правило ребазинга» так широко принято? Есть что-то еще, что я пропустил с этим? Я понимаю, что требуется минимум организации (каждая стратегия требует определенной организации), но это работает.
Ответы:
Проблема с принудительным нажатием не связана с вашей веткой объектов и мастером, а с тем, чтобы передать ваш мастер другому хозяину - эта синхронизация будет перезаписывать их мастер вашими изменениями, игнорируя все, что у них на кончике.
Учитывая эту опасность, есть причина, по которой вы не должны использовать его вообще, если что-то не испортилось, и вам абсолютно необходимо использовать его для ремонта. Систему SCM никогда не нужно подвергать принудительному вмешательству, если это происходит потому, что что-то пошло не так (и мой первый подход в таких случаях - восстановить резервные копии и повторить операции, чтобы сохранить историю нетронутой).
Так что, возможно, вопрос в том, почему вы вообще отказываетесь? Для «чистой» истории при возвращении функций к мастеру? Если это так, вы выбрасываете всю хорошую историю о ветвлении по чисто стилевым причинам. ИМХО слияние с ускоренной перемоткой также не является наилучшей практикой, вам следует сохранить всю историю, чтобы вы могли видеть, что вы на самом деле сделали, а не очищенную версию впоследствии.
источник
Перебазировка не обязательна, как вы говорите, она в основном косметическая. Иногда это намного проще, чем слияние. Таким образом, оно может иметь некоторое «фактическое» значение, но только «иногда»
Неправильное использование ребаз может быть дорогостоящим. Маловероятно потерять данные, если вы знаете достаточно, чтобы не паниковать и не искать процедуры восстановления, но «эй, никто не торопится, я должен исправить ...» - это не здорово. Кроме того, никто не тратит время на восстановление исследований и тестирование, когда они могли добавлять функции или исправлять ошибки (или дома с семьей).
С этим компромиссом результаты «очень мало людей делают ребаз и вынужденный толчок» не очень удивляют.
Некоторые рабочие процессы могут снизить риск, например, уменьшить его до «нуля, если вы помните, какие ветви вам разрешено форсировать, а какие нет». В действительности они могут быть достаточно безопасными, чтобы оправдать риск, но люди часто делают выбор, основываясь на большем фольклоре. Опять же, на самом деле, выгоды довольно малы, поэтому насколько крошечным должен быть риск?
источник
Чтобы добавить другой голос:
Да, если вы работаете так, как вы описываете, нет проблем с использованием
rebaseи принудительным нажатием. Критический момент: у вас есть соглашение в вашей команде.Предупреждения
rebaseи друзья относятся к случаю, когда нет особого соглашения. Обычно git защищает вас автоматически, например, не позволяя толкать без ускоренной перемотки вперед. Использованиеrebaseи принудительное нажатие отменяет эту безопасность. Это нормально, если у вас есть что-то еще на месте.В моей команде мы также иногда перезагружаем функциональные ветки, если история стала грязной. Мы либо удаляем старую ветку и создаем новую с новым именем, либо мы просто неофициально координируем (что возможно, потому что мы небольшая команда, и никто больше не работает в нашем хранилище).
Обратите внимание, что сам проект git также делает нечто подобное: у них есть ветка интеграции, которая регулярно воссоздается и называется «pu» («предлагаемые обновления»). Документально подтверждено, что эта ветка регулярно воссоздается, и что вы не должны основывать на ней новую работу.
источник
Причина, по которой пользователи Git стремятся избежать общей изменчивой истории, заключается в том, что нет автоматического предотвращения или исправления этих проблем. Вы должны знать, что вы делаете, и вы должны исправить все вручную, если вы запутались. Разрешение только одному человеку делать форс-пуш не является интуитивным и противоречит распределенному дизайну Git. Что произойдет, если этот человек отправится в отпуск? Кто-то еще временно владеет филиалом? Откуда ты знаешь, что они не будут ходить по всему, чем занимался первоначальный владелец? А в мире открытого исходного кода, что произойдет, если владелец филиала постепенно отдаляется от сообщества, не покидая его официально? Вы можете потерять много времени в ожидании передачи права собственности на филиал кому-то другому.
Но реальная проблема заключается в следующем: если вы все испортите и не сразу поймете это, старые коммиты со временем исчезнут после того , как пройдет достаточно времени. В этот момент проблема может быть неустранимой (или, по крайней мере, потенциально очень трудной для восстановления, в зависимости от того, как выглядит ваша история резервного копирования - вы делаете резервные копии старых копий вашего Git-репозитория, т.е. не только клонов?).
Сравните это с работой Mercurial по развитию Changeset (которая, я должен заметить, еще не закончена и не стабильна). Каждый может вносить любые изменения в историю, которые ему нравятся, при условии, что наборы изменений не помечены как открытые. Эти поправки и перебазировки могут быть продвинуты безнаказанно, без необходимости для владельца филиала. Данные никогда не удаляются; весь локальный репозиторий только для добавления. Наборы изменений, которые больше не нужны, помечаются как устаревшие, но хранятся неопределенно долго. Наконец, когда вы запутываете свою историю (которая рассматривается как обычная часть вашего повседневного рабочего процесса), есть изящная команда, чтобы очистить ее для вас автоматически. Это тот тип UX, который люди ожидают перед тем, как приступить к изменению общей истории.
источник