2015-06-01 1 views
0

Я новичок в переустановке. Я уже внес некоторые изменения в свою вилку, к ветке, используемой только мной. Цель состоит в том, чтобы в конечном итоге открыть запрос на перенос на github, чтобы включить изменения этой ветви в нашу основную ветку.Рекомендации по переустановке, раздаче и включению только моих изменений?

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

Я следующим образом побежал git rebase -i HEAD~8, где 8 был номером, который я выбрал, который, как я знал, охватывал все мои поручения. Из полученного списка коммитов я не касался того, что не имело ничего общего с моей веткой, и раздавило те, которые относятся к моей ветке.

Затем я сделал силовой удар в свою ветку и пошел открывать запрос на тяну. К моему удивлению, все 8 коммитов, которые я выбрал, были включены в запрос на растяжение.

Очевидно, у меня есть кое-что, чтобы узнать об этом. Почему все 8 коммитов заканчиваются в ожидании выталкивания, и как я могу улучшить в будущем, чтобы только моя ветвь зависела там? (И если мои коммиты сплетены с другими коммитами на хозяине, как я могу избежать включения других в список, когда я звоню rebase -i или хотя бы держать их в движении с PR?)

Я совершил ошибку в переустанавливая основную ветвь оригинала, а не хозяин моего вилка? Должен ли я потянуть и объединить происхождение/мастер в свою вилку/мастер, а затем пересобить против моей вилки/мастера?

+1

Я смущен, почему ваши изменения в ветвях чередуются с изменениями, которые не являются вашими ... или они ваши, но не относящиеся к вашей отрасли? Во всяком случае, во время сводного обзора rebase -i, если вы удаляете строки с коммитами, которые вы не хотите появляться в дереве с переустановкой, они не будут отображаться в вашей новой ветке. Однако, если вы не согласны с хозяином, вы получите инверсию этих изменений, если они действительно находятся в мастерстве. Я думаю, это звучит так, будто ты ошибаешься, хотя я не знаю, почему. Я бы выполнил «git fetch», за которым следует «git rebase origin/master», а затем сквош ваши изменения. – bcr

+0

Спасибо. Шаги, описанные выше, - это то, что я «думаю», что я должен делать во время переустановки, но, как вы отметили (и я упомянул в моем предостережении наверху), это не значит, что я должен это делать. «Вкрапленные» изменения, которые я видел в моем запросе на тягу, были из главной ветви. – larryq

+0

Итак, пытаясь понять это прямо: в момент, когда вы запускали 'git pull --rebase', вы тянете от мастера вашего вилка или ведущего мастера? Сразу после этого, если вы запустили 'git log', изменения из вашей локальной ветви перемежаются с изменениями, которые вы просто потянули? – bcr

ответ

1

Я побежал следующий мерзавец перебазироваться -i HEAD ~ 8, где 8 был номер я выбрал

Вы не должны делать это. Просто git rebase -i без лишних аргументов будет делать правильные вещи с достаточно свежими версиями git, если вы правильно настроили свою ветвь вверх. В худшем случае, git rebase origin/master будет правильно.

тогда я сделал усилие толкать

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

Если ваш первый выдвижная запрос не является достаточно хорошим, и вы должны переработать его, переписав некоторые коммиты, то вы можете обновить ваш PR с силой толчка.

Я не трогайте, что не имеет ничего общего с моей ветвью

Если удаленная история линейна (без слияния) и вы действительно не трогали (т.е. без удаления линии, ни линий переупорядочение, на самом деле никаких изменений) начало, то git не переписывает эти коммиты. Но если происходит слияние между HEAD и HEAD~8, то git rebase сгладит его по умолчанию, и если вы изменили что-то перед командой pick, тогда команда pick будет воспроизводить изменения, внесенные фиксацией поверх новой истории.Это приведет к ошибке , которая идентична старой для ваших глаз, но с новым идентификатором (sha1), поэтому она рассматривается как другая по git и github и отображается в запросе pull-request.

Смежные вопросы