Несколько человек на работе клянутся git pull --rebase. Фактически, они не смогут git pull без него, даже когда несколько человек работают над общей веткой.

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

Мой вопрос:

  • Каков конкретный пример того, как ребейсинг «переписывает историю»?
  • Какие конкретные примеры плохих вещей могут произойти, если вы нарушите «Золотое правило ребейсинга»?

Возможная разница с предложенным обманом:

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

4
Two-Bit Alchemist 21 Апр 2016 в 21:48

2 ответа

Лучший ответ

Мы используем это в наших рабочих процессах.

Если вы используете его только на короткоживущих ветках, это относительно безопасно. Вы воспроизводите локальные коммиты (переписываете ту историю) поверх нажатых коммитов ваших коллег.

Если вы переустанавливаете всю ветку совместной работы, в ваших интересах тщательно координировать свои действия с коллегами. Иначе легко потерять работу. С pull -r это довольно сложно.

3
TrueWill 21 Апр 2016 в 18:52

Мы используем это в наших рабочих процессах.

Пока вы переустанавливаете только свои непринятые изменения, вы переписываете только свою собственную историю, и это нормально.

Как я вижу это:

  • Преимущество rebase - история намного понятнее, потому что она линейна. Чем больше разработчиков у вас работает над веткой, тем заметнее это будет.
  • Недостаток rebase - нет отслеживания разрешения конфликтов. Предположим, у вас все работает. Затем вы fetch и merge и возникают конфликты слияния. Вы разрешаете их неправильно и вносите изменения. Когда система CI обнаруживает ошибку, вы можете отследить ее до неправильного разрешения конфликта (или, возможно, неправильного тестирования после разрешения конфликта), а не до неправильного начального кодирования / тестирования. Если fetch, а затем rebase, разрешение конфликта потеряно, оно встроено в один или несколько ваших коммитов.

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

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

1
Mort 21 Апр 2016 в 20:04