2013-10-25 4 views
1

Обновление: Это оказалось ошибкой в ​​версии SmartGit, которую я использую (версия 3.0.11) - приложение, похожее на gitk. Список «Pushable Commits» изменяется после выполнения «git pull», и некоторые локальные коммиты, которые еще не нажаты, случайно удалены из этого списка пользовательского интерфейса. Это вызвало путаницу, описанную в этом сообщении, где она оказалась единственной фиксацией, которая не была нажата, была «Merge commit».git pull with clean local repo вызывает слияние commit

Я нажал изменения на удаленный (на GitHub). Двое других разработчиков подтолкнули меня за несколько коммитов. У меня не было никаких локальных изменений или коммитов, и я сделал «git pull».

Сразу после того, как он сменил изменения, он заставил меня выполнить слияние (позволяя мне ввести необязательное сообщение). Я использую Git в течение ~ 2 лет, и мне еще предстоит столкнуться с такой ситуацией, когда смена изменений в чистом локальном репо привела бы к слиянию. Два раза это происходило за последнюю неделю, я не был уверен, что делать, поэтому я сразу же отменил это слияние без каких-либо проблем (!?).

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

На изображении ниже показана история.

Merge commit

Моего оригинальный коммит толкнул в нижней точке на фиолетовой линии. Два других девчонка пошли за мной, и, потянув их изменения, он создал верхний «Merge Branch» в моем локальном репо (на той же фиолетовой линии).

+0

Попробуйте проверить фиксацию слияния и его родительский объект в инструменте типа 'gitk'. Вы должны увидеть две родительские коммиты с разными хэшами. –

+0

RE ваше изображение: И удаленная ветка, которую вы вытащили, указана на выделенный? – poke

+0

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

ответ

0

Посмотрев на свое изображение еще дольше, я понял кое-что очевидное. Назовем коммиты A-E снизу вверх, чтобы упростить задачу.

Итак, вот что: перед тем, как потянуть, ваша местная ветвь указывала на A, который был фиксацией, которую вы имели на месте.

При просмотре фиксации D вы можете видеть, что красная линия не заканчивается A, но где-то раньше (скриншот не показывает это).Так что фиксация не была основана на A и поэтому вы не могли бы перемотки вперед при потянув. Вместо этого вам нужно было создать фиксацию слияния.

Теперь вы упомянули, что раньше вы нажимали A, так что это немного странно. Если вы действительно подтолкнули его, и D был опубликован уже, ваш толчок не удался, и вам сначала пришлось бы объединить его. Если D не был опубликован уже, ваш толчок прошел бы, но тогда автору D пришлось бы объединить его, прежде чем его можно было нажать.

Поскольку вы ничего из этого не произошло, и вам пришлось создать слияние позже, когда вы потянули, единственная причина, по которой вы на самом деле никогда не толкали ваш фиксатор A.

Обратите внимание, что фиксация автоматически не нажимает фиксацию. Как я уже сказал в комментариях, если вы не нажмете/не потянете, все, что вы делаете, полностью локально. И только когда вы нажимаете или тянете, фиксации фактически переносятся на или с пульта.

(Другой вариант был бы, что DEV толкая Dсделал получить конфликт, но решил принудительно толчок вместо этого, удаляя вашу фиксацию из удаленного хранилища. Если вы используете GitHub, это должно быть видно из этого пользователя журнал активности.)

+0

Я определенно нажал A, когда он появился на github. Тем не менее, A и B имеют один и тот же родитель, даже если B был нажат после A (dev, который нажал B, использует rebasing). В этот момент «A», возможно, был по существу удален. Когда я осмотрел местную историю дэва, который толкнул B, его местная история вообще не показывает A. – nogridbag

+0

Ну, даже если вы используете rebasing, вы не можете перетаскивать rebased commits, если они перезаписывают уже пробитую историю без использования силы. В противном случае вы получите сообщение об ошибке (и вы действительно не должны этого делать). То, что у д-ра B не было «A», говорит вам, что он не вытащил первым (потому что он получил бы «A»), но он также не смог бы толкать тогда. - Это публичный проект на GitHub? – poke

+0

Извините, нет, это частное репо. – nogridbag

0

Главное, чтобы помнить, что git pull представляет собой комбинацию из двух команд. git fetch и git commit Кроме того, ваша локальная ветвь-мастер не является той же ветвью, что и удаленный мастер.

Кто-то нажал изменения в удаленной ветке после того, как вы нажали свои изменения. Поэтому, когда вы вытащили из пульта. Git обновил HEAD удаленной ветви, а затем объединил ее с вашей локальной ветвью. Слияние вызывает фиксацию, поэтому в итоге вы получите слияние.

Если вы сбросили свою ветку на фиксацию, которую вы первоначально нажали, а затем сделали git pull --reabse, вы обнаружите, что фиксации, которые добавили бы остальные разработчики, соответствовали бы вашей ветке, и у вас не было бы слияния.

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

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