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

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

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

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

Добавить 1:

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

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

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

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

master получает несколько коммитов, а пользователь A делает несколько коммитов:

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

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

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'

Ответы

Ответ 1

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

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

Ответ 2

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

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

Дополнение:

Если rebase breaks unittest, у вас не будет возможности git bisect ошибочной версии.

Подробнее:

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

Ответ 3

http://git-scm.com/book/ch3-6.html

В разделе под названием "Опасности перезагрузки"

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