Это нормально всегда git pull --rebase master branch

Мы являемся командой, работающей с git, у нас есть центральный репозиторий (единственное происхождение), который мы используем для push и pull from (и capistrano использовать его для развертывания мастера ветвей)

мы совершаем коммиты и развертываем регулярно (10-20 развертываний в день), это означает, что у нас много коммитов и git blame становятся кошмаром

Я читал, что для более простой истории мы можем использовать git pull --rebase, чтобы избежать этого. Это хорошая идея делать это всегда на главной ветке?

если я хочу предложить установить его в config с помощью

git config branch.master.rebase true

Есть ли какие-либо проблемы с этим?

ОТВЕТЫ

Ответ 1

Нет проблем. На самом деле это предпочтительнее.

В 99% случаев лучше переустановить изменения. Если нет, разработчик всегда может отменить rebase и слить свои изменения вручную.

Альтернатива (слияние по тяге) вызывает тонны мелких побочных коммитов и слияний, которые не вносят никакого значения.

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

Ответ 2

Выполнение перетаскивания по умолчанию - это нормально (не обязательно "хорошая идея", не обязательно "плохая идея" ). Вам просто нужно иметь в виду, что это фактически повредит вашу работу. Если вы сделали серию коммитов, которые зависят от того, что было в репо до того, как Боб изменил его 1 ваш rebase (поверх изменений Боба) может заставить вас исправить все эти коммиты, когда было бы легче исправить только окончательную фиксацию слияния.

Я предпочитаю делать это вручную: запустите git fetch, а затем git rebase или git merge в зависимости от ситуации, которую я обнаруживаю, как только я сделал выборку.

Преимущество git pull --rebase (и/или установка branch.master.rebase true), хотя в том, что "pull with rebase" является экстра-умным и может обрабатывать некоторые случаи, когда удаленный пользователь также выполняет переустановки.

1 "Боб" здесь представляет любого, кто внес некоторые изменения (и избил вас до шага push), который заставляет ваши собственные изменения "иметь несварение" как бы.

Ответ 3

Это всегда прекрасное pull.rebase в моем expierence. Если вы не хотите иметь конфликты слияния, вы можете работать в локальном филиале, и если вы хотите работать с последним кодом, вы всегда будете иметь какие-либо неуправляемые изменения до того, как ваша текущая работа будет нажата.

Слияние в ветки в результате git pull почти всегда бессмысленно, если слияние было бы значимым, ветки должны были отличаться (и объединять явно).

См. также http://stevenharman.net/git-pull-with-automatic-rebase.

Ответ 4

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

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

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