Как Вы объединяете изменения на неосновных ответвлениях из разветвленного репозитория GitHub?

Сценарий 1: Удаление веток, которые больше не существуют

Для удаления веток, которые больше не существуют, я выполнил инструкции в ответе на вопрос StackOverflow Как удалить ветку в Git'е как локально, так и в Github'е? с помощью следующих команд:

$ git push origin :0.9-doc-rewrite
$ git push origin :path-and-#24

Сценарий 2: Слияние изменений в существующей немастерской ветке

Для получения восходящего/0. В 9 ветках я сделал следующее:

$ git checkout --track origin/0.9
$ git fetch upstream
$ git merge upstream/0.9
$ git push

Сценарий 3: Отслеживание новых немастерных ветвей

Не уверен, что это лучший способ обработки, но вот что я сделал:

$ git branch flexible-task-declarations upstream/flexible-task-declarations
Branch flexible-task-declarations set up to track remote branch flexible-task-declarations from upstream.
$ git checkout flexible-task-declarations
$ git push origin flexible-task-declarations

Чтобы подтвердить, что все ветки находятся на одном коммите:

$ git branch -av

Это покажет все ветки - локальные и удалённые - и покажет самое последнее сообщение коммита и SHA1 хэш.

Веб-исследования, которые могут пролить свет на лучший метод работы со сценарием 3

• Github Guide: Keeping a git fork in sync with the forked repo - Предоставляет ярлык для octo merge одновременно из исходного и восходящего репо, но не описывает начальный шаг получения ветки, которая находится в восходящей, но не исходной установке локально
• Use and keep your fork current with the master Git repository from xmpp4r developer FAQ

A key difference between a Git fork, по сравнению с простым Git-клоном или SVN-кассой, это то, что ваша вилка никогда не будет держать себя в курсе с мастер-репо, если вы не сделаете этого. К счастью, есть простой инструмент, который поможет вам в этом. Ваша вилка отделена и равна мастеру в терминах Git'а, так что если вы хотите отслеживать изменения в мастере, вы можете создать отслеживающую ветку в вашем вилочном репо и сливать эти изменения в мастер-ветку вилки всякий раз, когда вы захотите что-то зафиксировать. Я настоятельно рекомендую GitHub - инструмент, который вы можете установить, чтобы легко отслеживать изменения в любом другом репозитории, связанном с вашим. См. текст README внизу этой страницы для установки и использования: http://github.com/defunkt/github-gem/tree/master

• Collaborative Github Workflow из eqqon (хорошая статья о Github Workflow):

Ignore the Github Fork Queue It's evil! Очередь вил - это инструмент для мейнтейнеров, которые любят выбирать отдельные коммиты из участников, но не хотят сливаться во всей своей ветке. Если вы поиграете с очередью вил, вы испортите свою вилку (это можно исправить, прочтите "Что-то пошло не так"). Многие новички на github чувствуют, что они должны что-то делать с очередью вил, потому что там много, возможно, противоречивых изменений, и они не знают, какой способ поддерживать свою вилку в актуальном состоянии. Читайте "Держать вилку в актуальном состоянии" и узнайте об этом!

Django's Github Workflow

В проекте Django есть инструкции по работе с GithubCollaborate on Github, которые используют то, что кажется стандартным способом работы с вилкой и вытягиванием изменений вверх по потоку.

Различная начальная конфигурация вилки

Долгое гостевое сообщение Nguyen под названием Настройка Git-репозиториев для проектов с открытым исходным кодом на GitHub в блоге Майкла Хартла описывает интересный метод настройки репозитория Github, который вы отбросили. Цели этого метода, согласно статье:

• Держите репозитории синхронизированными так, чтобы каждый из них содержал полный "официальный" репозиторий
• Позвольте разработчикам получать официальные обновления
• Поощряйте работу над ветвями, отличными от master