Использование git rebase в публичных ветках функций

Question

Вы можете видеть в Интернете всех, кто советует не использовать git rebase в публичной ветке, но я не вижу, в чем проблема, если вы всегда перебазируете ветку функций.

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

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

Добавить 1:

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

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

Исходное состояние:

master         ==========A
origin/feature           +=====AB
feature user A           +=====AB
feature user B           +=====AB

мастер получает несколько коммитов, а пользователь А выполняет несколько коммитов:

master         ==========A=====C
origin/feature           +=====AB
feature user A           +=====AB====D
feature user B           +=====AB

Пользователь A делает git pull --rebase (он всегда делает это), чтобы обновить свою ветку, ничего нового не приходит, затем он перебазируется в master и нажимает:

master         ==========A=====C
origin/feature                 +=====ACB'=====ACB'D
feature user A                 +=====ACB'=====ACB'D
feature user B           +=====AB

(обратите внимание, что B '- это новые коммиты, которые все еще представляют изменения B)

Затем пользователь B делает несколько коммитов:

master         ==========A=====C
origin/feature                 +=====ACB'=====ACB'D
feature user A                 +=====ACB'=====ACB'D
feature user B           +=====AB======E

Пользователь B, наконец, выполняет git pull --rebase, как всегда, нет необходимости перезагружать мастер, поэтому он просто нажимает:

master         ==========A=====C
origin/feature                 +=====ACB'=====ACB'D======E'
feature user A                 +=====ACB'=====ACB'D
feature user B                 +=====ACB'=====ACB'D======E'

Answer 1

Если вы перебазируете, вы переписываете историю. И точно так же, как в реальном мире, если вы хотите переписать историю, вам нужен заговор: все должны быть «вовлечены» в заговор (по крайней мере, все, кто знает об истории, т.е. все, кто когда-либо вырывался из ветви) .

До тех пор, пока круг людей, выходящих из ветви, находится под жестким контролем, довольно легко начать заговор, однако, как только вы публикуете эту историю, она становится лотом труднее , Однако это не невозможно: ветка pu в репозитории Junio ​​C Hamano Git, например, перезаписывается после каждого выпуска, и это широко публикуемый репозиторий. Это работает так, что тот факт, что ветка будет часто перебазироваться, и время, когда это произойдет, широко документированы на сайте Git, вики Git и списке рассылки Git, и каждая перебазировка объявляется заранее в списке рассылки, поэтому что люди могут подготовиться к этому.

Answer 2

Когда вы перебазируете против публичной ветки, это совершенно нормально.

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

Дополнительно:

Когда перебазирование прерывает юнит-тест, у вас не будет возможности git bisect ошибочная ревизия.

Более подробно:

• вы подготовили некоторый код для добавления в ветку.
• вы отладили его, чтобы он прошел все юнит-тесты
• вы получили новые изменения в (удаленной) ветке
• теперь вы перебираете свой код против перебазированной удаленной ветки
• и здесь юнит-тесты ломаются
• вы используете git bisect, и он указывает на удаленную перезагрузку.
• ваши действия?

Answer 3

http://git -scm.com / книга / ch3-6.html

В разделе «Опасности перебазирования»

... вас будут презирать друзья и семья.