Github перебазирует восходящий поток/мастер с источником/мастером

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

Что случилось

  1. Я разветвил MassTransit еще в июле 2012 года. Тогда его ветка master имела версию 2.1.1, последняя фиксация была 29 марта 2012 г..
  2. Следуя совету github, я начал кодировать некоторые изменения в тематической ветке.
  3. Спустя несколько коммитов, когда функция была завершена, я объединил свою тематическую ветку с локальным мастером моего клона, а затем отправил ее на github.
  4. Начиная с 29 марта 2012 г. MassTransit разрабатывался в ветке develop. Все эти изменения, составляющие версию 2.6.0, были недавно объединены с ее мастером.

Что я хотел бы сделать

Я хочу получить все изменения, которые были объединены в upstream/master. Предпочтительно в виде их соответствующих коммитов, а не одного массивного коммита из сотен файлов. Поскольку я занимался разработкой на бывшем upstream/master (от 29 марта 2012 г.), я думаю, мне нужно будет вставить некоторые коммиты между последними upstream /master изменение от 29 марта и мой первый коммит от 8 августа, а затем поверх этого добавить те, что произошли позже. Как это сделать?

(Я также хотел бы не уничтожать свои коммиты/форки в процессе ;-)

Что я пробовал

git checkout master
git remote add upstream git://github.com/phatboyg/MassTransit.git
git rebase upstream/master
git push

Однако это не позволило мне сделать git push, жалуясь, что моя локальная подсказка отставала от источника на 10 коммитов (возможно, коммитов, которые я сделал в своей тематической ветке, а затем объединил в origin/master?).

Рекомендации?

Кажется, меня укусили рекомендации. Например. возможно, было бы лучше создать отдельную ветку, например. local-master, и относитесь к этому как... ну, к моему собственному хозяину. Тогда master будет использоваться только для поддержания связи с upstream/master, и я буду время от времени перебазировать origin/master с помощью upstream/ master и объединиться с origin/local-master...

Как вы, ребята, управляете своими вилками?

Другие вопросы

Мне не удалось найти способ визуализировать историю веток, узнать, какая ветка была объединена с другой, когда и т. д. Github для Windows показывает только плоскую историю для текущей выбранной ветки (здесь грустное лицо). На веб-сайте есть несколько визуализаций для сети (вот одна для MassTransit), но это кажется гораздо менее информативным, чем, скажем, графики в TortoiseHg. Я упускаю что-то очевидное? Все остальные просто помнят, что с чем было объединено и когда?

Изменить (31 августа)

Я делюсь визуализацией бедняка, чтобы объяснить, что произошло. .

  1. Я создал ответвление, когда C1 был последним на upstream/master.
  2. Затем я разработал свой origin/feature-1.
  3. Когда функция была завершена, я объединил ее с моим origin/master.
  4. Когда upstream/mega-feature была завершена, она была объединена с upstream/master, фактически исторически скопировав C2 и C3 в upstream/master. (Или, возможно, upstream/master был перебазирован с upstream/mega-feature?)
  5. Теперь я хочу скопировать C2, C3 и C4 в мой origin/master.

git github github-for-windows git-rebase
person Dav    schedule 30.08.2012    source источник
comment
используйте слияние вместо перебазирования. Почему вы используете перебазирование?   -  person kan    schedule 30.08.2012
comment
Я думал, что использование слияния применит только все изменения «upstream/master» к моему репо и оставит его в незафиксированном состоянии. Таким образом, выдавая правильные результаты с точки зрения состояния моих исходных файлов, после фиксации я получил бы одну огромную фиксацию, изменяющую около 600 файлов, без дополнительной детализированной информации. AFAIK rebase предотвратил бы это и вместо этого вытащил бы отдельные коммиты. Верный?   -  person Dav    schedule 31.08.2012
comment
Я обновил свой вопрос, чтобы помочь объяснить, что произошло и что я хотел бы сделать.   -  person Dav    schedule 31.08.2012

Ответы (2)


arrow_upward
6
arrow_downward

Я предполагаю, что вы будете или уже настроили origin удаленный доступ к своей вилке, и то же самое снова для upstream (как описано).

Затем я бы сделал выборку upstream, чтобы все их ветки хранились локально. Затем вы можете сравнить репозитории и посмотреть, есть ли общий коммит на дату расхождения или рядом с ней.

Здесь полезна визуализация gitk --all. Не забывайте, что даже если вы делаете перебазирование, старая серия коммитов все еще существует, поэтому вы можете дать ей имя.

[EDIT] Многословное описание.

Очевидно, что фиксация слияния «мешает», поэтому ее нужно «массировать» прочь, чтобы можно было снова синхронизировать репозитории.

  1. создайте ветку temp в вашей текущей голове, чтобы ничего не потерялось.
  2. reset ваша основная ветвь возвращается к последнему общему коммиту между вами и восходящим потоком.
  3. reset ветвь вашей функции непосредственно перед слиянием.
  4. checkout коммит слияния, чтобы получить рабочее дерево, как вы ожидаете, затем
  5. переключитесь на свою ветку функций (ничего не проверяя!)
  6. commit это исправленное рабочее дерево в вашей feature ветке (т.е. без слияния).

Теперь у вас есть чистая линия на master, чистая, но старая линия на feature и любые изменения после слияния на temp. если Happy, вы сможете принудительно отправить это на свой origin.

  1. pull из апстрима - это (т.е. master и т.д.) все должно перематываться вперед.
  2. rebase эти разработки после слияния с temp по feature (при необходимости).
  3. rebase feature до последнего коммита, который вы хорошо знаете на мастере (должно быть относительно легко).
  4. rebase feature (снова) к последнему коммиту на мастере, исправляя по мере продвижения (комбинируйте с последним шагом, если это легко ;-).

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

person Philip Oakley    schedule 30.08.2012
comment
Да, источник был настроен для меня, когда я клонировал свой репозиторий в Github для Windows, мне нужно было только добавить восходящий поток (подтверждается выполнением git remote, который показывает как источник, так и восходящий поток). Что вы подразумеваете под общей фиксацией? Я знаю точную фиксацию, после которой мое репо разошлось. Что я могу сделать с этой информацией? - person Dav; 31.08.2012
comment
Это был случай сопоставления, когда три разные ветки расходились друг от друга, чтобы увидеть, есть ли какие-то конфликты (перекрытия) или есть ли у вас независимые линии разработки (за исключением коммитов слияния). Ваша ветка topic все еще отстает от слияния с мастером? - person Philip Oakley; 31.08.2012
comment
Я обновил свой вопрос, чтобы помочь объяснить, что произошло и что я хотел бы сделать, пожалуйста, посмотрите. - person Dav; 31.08.2012
comment
Извините за задержку. Я обновил свой ответ, добавив расширенное описание того, что может быть методом исправления. - person Philip Oakley; 03.09.2012
comment
Только что я попробовал что-то очень похожее на то, что вы предлагаете. Прежде всего, я сделал git reset HEAD~10, вернув слияние объекта с головой, затем git push --force. С этим force я почувствовал некоторые ранее неизвестные силы :-) Так что я перебазировал свою функциональную ветку, попутно исправив ошибки, и снова сделал git push --force своей функциональной ветки. Это было ключевым моментом, так как конфликты слияния при выполнении обычного git push приводили к ошибкам, исправление которых возвращало меня обратно в состояние до перебазирования. Спасибо за ваши идеи, они помогли мне на моем тернистом пути к лучшему пониманию git. - person Dav; 04.09.2012
comment
@Дав, без проблем. Мне знакомо это чувство ;-) Также приятно получать отзывы о том, что вы сделали на практике, чтобы помочь другим. Будем надеяться, что ваши предложения будут подхвачены вашим вышестоящим. - person Philip Oakley; 04.09.2012

arrow_upward
2
arrow_downward

Вот несколько идей.

Метод выбора вишни:

git checkout master
git cherry-pick C2..C4

Новый метод перебазирования ветки:

git checkout upstream/master
git branch new-master
git rebase master
# new-master should now look like what you want, once you confirm this
git branch -m master old-master
git branch -m new-master master

Метод Rebase --onto (позволяет выбрать нужный диапазон коммитов):

git checkout master
git rebase --onto master C2 C4 # puts you into a detached HEAD
git branch new-master
# rename branch as above if it is correct
person onionjake    schedule 31.08.2012
comment
Хороший упоминание о сборе вишни, попробуем это в будущем! - person Dav; 05.09.2012