Когда я должен использовать git pull --rebase?
Создатели Java могли бы определить, что оператор == непосредственно воздействует на операнды разных типов, и в этом случае Integer I; int i; сравнение I==i; может задать вопрос: «Имеет ли I ссылку на Integer, значение которого i? »- вопрос, на который можно было бы ответить без труда, даже когда I имеет значение null. К сожалению, Java напрямую не проверяет, равны ли операнды разных типов; вместо этого он проверяет, позволяет ли языку тип любого операнда быть преобразованным в тип другого, и - если он это делает - сравнивает преобразованный операнд с непереработанным. Такое поведение означает, что для переменных x, y и z с некоторыми комбинациями типов возможно иметь x==y и y==z, но x!=z [т.е. x = 16777216f y = 16777216 z = 16777217]. Это также означает, что сравнение I==i переводится как «Преобразовать I в int, и если это не вызывает исключение, сравните его с i.»
4 ответа
Вам следует использовать git pull --rebase , когда
- ваши изменения не заслуживают отдельной ветки
Действительно - почему бы и нет? Это более ясно и не требует логической группировки ваших коммитов.
Хорошо, я полагаю, это требует некоторого пояснения. В Git, как вы, наверное, знаете, вас поощряют ветвление и слияние. Ваша локальная ветка, в которую вы извлекаете изменения, и удаленная ветка, на самом деле, являются разными ветвями, и git pull предназначен для их объединения. Это разумно, поскольку вы нажимаете не очень часто и обычно накапливаете ряд изменений, прежде чем они станут завершенной функцией.
Однако иногда - по какой-то причине - вы думаете, что на самом деле было бы лучше, если бы эти два - удаленный и локальный - были одной ветвью. Как в SVN. Именно здесь вступает в игру git pull --rebase . Вы больше не объединяетесь - вы фактически фиксируете поверх удаленной ветки . Вот о чем это на самом деле.
Опасно это или нет - это вопрос о том, рассматриваете ли вы локальную и удаленную ветвь как одно целое. Иногда это разумно (когда ваши изменения небольшие или если вы находитесь в начале надежной разработки, когда важные изменения вносятся небольшими коммитами). Иногда это не так (когда вы обычно создавали другую ветку, но вам было лень это сделать). Но это другой вопрос.
Я думаю, это зависит от личных предпочтений.
Вы хотите скрыть свои глупые ошибки, прежде чем вносить изменения? Если да, то git pull --rebase идеально подходит. Это позволяет вам позже свести ваши коммиты к нескольким (или одному) коммитам. Если в вашей (не отправленной) истории есть слияния, не так просто выполнить git rebase позже.
Лично я не против публикации всех своих глупых ошибок, поэтому я предпочитаю объединять, а не переустанавливать.
Я думаю, вам следует использовать git pull --rebase при совместной работе с другими участниками той же ветки. Вы в своей работе → фиксация → работа → цикл фиксации, и когда вы решаете продвинуть свою работу, ваш толчок отклоняется, потому что в одной и той же ветке была параллельная работа. На этом этапе я всегда выполняю pull --rebase . Я не использую сквош (для сглаживания коммитов), но я перебазирую, чтобы избежать лишних коммитов слияния.
По мере того, как ваши знания Git расширяются, вы обнаруживаете, что гораздо больше смотрите на историю, чем с любыми другими системами контроля версий, которые я использовал. Если у вас есть тонна небольших коммитов слияния, легко потерять фокус на более широкой картине, происходящей в вашей истории.
На самом деле это единственный раз, когда я выполняю перебазирование (*), а остальная часть моего рабочего процесса основана на слиянии. Но пока это делают ваши самые частые коммиттеры, история в конце концов выглядит намного лучше.
(*)
Когда я преподавал курс Git, меня за это арестовал студент, так как я также выступал за перебазирование функциональных веток в определенных обстоятельствах. И он прочитал этот ответ;) Такой ребейзинг также возможен, но он всегда должен выполняться в соответствии с заранее согласованной / согласованной системой и, как таковой, не должен применяться «всегда». И в то время я обычно тоже не выполняю pull --rebase , вот в чем вопрос;)
Я не думаю, что когда-либо есть причина не использовать pull --rebase - Я добавил код в Git специально, чтобы разрешить git pull команда, чтобы всегда выполнять перебазирование против исходящих коммитов.
Когда просматриваешь историю, просто никогда не интересно узнать, когда парень / девушка, работающая над функцией, остановилась, чтобы синхронизироваться. Это может быть полезно парню / девушке, пока он / она это делает, но для этого и нужен reflog . Это просто добавляет шума для всех остальных.