Как обновить разветвленный репозиторий GitHub?

3610

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

Несколько дней спустя другой участник внес другое изменение. Так что моя вилка не содержит этого изменения.

Как я могу получить это изменение в моей вилке? Нужно ли мне удалять и заново создавать мой форк, когда у меня появятся дальнейшие изменения? Или есть кнопка обновления?

Леа Хейс
источник
120
Это также можно сделать из пользовательского интерфейса github. Я хотел бы отдать должное [этому другому постеру] [1]. [1]: stackoverflow.com/a/21131381/728141
Майк Шролл,
2
Еще одна хорошая запись в блоге об этом - Keeping A GitHub Fork Обновлено
Arup Rakshit
3
Это можно найти в справочных статьях Github: help.github.com/articles/syncing-a-fork
Pranav
2
Это дубликат stackoverflow.com/questions/3903817/… ?
Дэвид Кэри
Вот видео-демонстрация, которая делает это с использованием двух учетных записей github youtube.com/watch?v=kpE0gTX4ycE
lifebalance

Ответы:

3986

В локальном клоне вашего разветвленного репозитория вы можете добавить исходный репозиторий GitHub в качестве «удаленного». («Remotes» подобны псевдонимам для URL репозиториев - originнапример, один.) Затем вы можете получить все ветви из этого репозитория upstream и перебазировать свою работу, чтобы продолжить работу над версией upstream. С точки зрения команд, которые могут выглядеть так:

# Add the remote, call it "upstream":

git remote add upstream https://github.com/whoever/whatever.git

# Fetch all the branches of that remote into remote-tracking branches,
# such as upstream/master:

git fetch upstream

# Make sure that you're on your master branch:

git checkout master

# Rewrite your master branch so that any commits of yours that
# aren't already in upstream/master are replayed on top of that
# other branch:

git rebase upstream/master

Если вы не хотите переписывать историю вашей основной ветки (например, потому что другие люди, возможно, клонировали ее), тогда вы должны заменить последнюю команду на git merge upstream/master. Тем не менее, для того, чтобы сделать дальнейшие пул-запросы, которые были бы максимально чистыми, вероятно, лучше сделать ребаз.


Если вы переместили свою ветку на вашу ветку, upstream/masterвам может потребоваться принудительное добавление, чтобы перенести ее в свой собственный разветвленный репозиторий на GitHub. Вы бы сделали это с:

git push -f origin master

Вам нужно использовать только -fв первый раз после того, как вы перебазировали.

Марк Лонгэйр
источник
94
Поскольку ваш форк существует только на github, а у github нет инструментов для выполнения слияний через веб-интерфейс, то правильный ответ - локальное слияние вверх по потоку и отправка изменений обратно на ваш форк.
Тим Китинг
29
Вот замечательный учебник, который я нашел по работе с github: gun.io/blog/how-to-github-fork-branch-and-pull-request
Тим Китинг
50
Небольшое замечание: вместо того, чтобы перебазировать свою основную ветку, чтобы убедиться, что вы начинаете с чистого состояния, вам, вероятно, следует работать с отдельной веткой и сделать из нее запрос на извлечение. Это держит вашего мастера в чистоте для любых будущих слияний и избавляет вас от необходимости переписывать историю, из-за -fкоторой портятся все, кто мог клонировать вашу версию.
Матеуш Ковальчик
11
Вместо команды rebase я использовал следующее: git merge --no-ff upstream/masterТаким образом, ваши коммиты больше не находятся на вершине.
Steckdoserich
52
Еще один сбой Git. Если предполагается, что этот инструмент поддерживает распределенное сотрудничество, то почему так сложно выполнить базовый рабочий процесс? 4 миллиона человек и 2200 голосов означают, что инструмент не удался. «Вы можете добавить исходный репозиторий GitHub в качестве« удаленного » - Почему это даже нужно делать? Почему это не делается во время разветвления? Что такого
jww
740

Начиная с мая 2014 года, можно обновлять форк напрямую с GitHub. Это все еще работает с сентября 2017 года, НО это приведет к грязной истории коммитов.

  1. Откройте вилку на GitHub.
  2. Нажмите на Pull Requests.
  3. Нажмите на New Pull Request. По умолчанию GitHub сравнивает оригинал с вашим форком, и не должно быть ничего для сравнения, если вы не внесли никаких изменений.
  4. Нажмите, switching the baseесли увидите эту ссылку. В противном случае вручную установите base forkраскрывающийся список для вашей вилки, а head forkдля восходящего. Теперь GitHub будет сравнивать ваш форк с оригиналом, и вы должны увидеть все последние изменения. введите описание изображения здесь
  5. Create pull requestи назначьте предсказуемое имя для вашего запроса (например, Update from original).
  6. Прокрутите вниз Merge pull request, но пока ничего не нажимаете.

Теперь у вас есть три варианта, но каждый из них приведет к менее чистой истории фиксации.

  1. По умолчанию будет создан уродливый коммит слияния.
  2. Если щелкнуть раскрывающийся список и выбрать «Сквош и объединить», все промежуточные коммиты будут сведены в один. Это чаще всего то, что вы не хотите.
  3. Если вы нажмете Rebase and merge, все коммиты будут сделаны «с вами», оригинальные PR свяжутся с вашим PR, и появится GitHub This branch is X commits ahead, Y commits behind <original fork>.

Так что да, вы можете поддерживать репо в обновленном состоянии с помощью веб-интерфейса GitHub, но это приведет к потере истории ваших коммитов. Вместо этого придерживайтесь командной строки - это легко.

Lobzik
источник
19
Это работало отлично один раз. Во второй раз этот процесс работал не так: ссылка «Переключение базы» не отображалась. И когда я нажал «Нажмите, чтобы создать запрос на извлечение», он создал PR в репозитории SOURCE. НЕ то, что я хотел ..
Джавадба
29
Все еще работает (Marchi 2015), хотя ссылки «Переключение базы» больше нет. Вы должны изменить раскрывающийся список «База», чтобы оба указывали на вилку, а затем вы получите приглашение «Сравнить через репозитории», которое приведет вас туда, куда вы хотите.
Mluisbrown
8
Апрель 2015 года. Работы. Спасибо. Я получил "Переключение на базу". Однако на шаге 6 было «Создать запрос на извлечение» -> введите комментарий -> «Создать запрос на извлечение». В конечном итоге 1 коммит впереди оригинала.
Cartland
5
@cartland (или другие) - да, там написано "Эта ветка на 1 коммит впереди ..." Об этом стоит беспокоиться? Можно ли избавиться от этого сообщения?
RenniePet,
11
не было бы лучше, просто с помощью кнопки обновления или синхронизации!
трансформатор
457

Вот официальный документ GitHub по синхронизации форка :

Синхронизация вилки

Настройка

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

Совет: синхронизация вашего форка только обновляет вашу локальную копию репозитория; он не обновляет ваш репозиторий на GitHub.

$ git remote -v
# List the current remotes
origin  https://github.com/user/repo.git (fetch)
origin  https://github.com/user/repo.git (push)

$ git remote add upstream https://github.com/otheruser/repo.git
# Set a new remote

$ git remote -v
# Verify new remote
origin    https://github.com/user/repo.git (fetch)
origin    https://github.com/user/repo.git (push)
upstream  https://github.com/otheruser/repo.git (fetch)
upstream  https://github.com/otheruser/repo.git (push)

Синхронизации

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

Fetching

Извлечение из удаленного хранилища приведет к его ветвям и их соответствующим коммитам. Они хранятся в вашем локальном хранилище в специальных ветках.

$ git fetch upstream
# Grab the upstream remote's branches
remote: Counting objects: 75, done.
remote: Compressing objects: 100% (53/53), done.
remote: Total 62 (delta 27), reused 44 (delta 9)
Unpacking objects: 100% (62/62), done.
From https://github.com/otheruser/repo
 * [new branch]      master     -> upstream/master

Теперь у нас есть главная ветка upstream, хранящаяся в локальной ветке upstream / master.

$ git branch -va
# List all local and remote-tracking branches
* master                  a422352 My local commit
  remotes/origin/HEAD     -> origin/master
  remotes/origin/master   a422352 My local commit
  remotes/upstream/master 5fdff0f Some upstream commit

сращивание

Теперь, когда мы получили вышестоящий репозиторий, мы хотим объединить его изменения с нашей локальной веткой. Это позволит синхронизировать эту ветку с восходящим потоком, не теряя наших локальных изменений.

$ git checkout master
# Check out our local master branch
Switched to branch 'master'

$ git merge upstream/master
# Merge upstream's master into our own
Updating a422352..5fdff0f
Fast-forward
 README                    |    9 -------
 README.md                 |    7 ++++++
 2 files changed, 7 insertions(+), 9 deletions(-)
 delete mode 100644 README
 create mode 100644 README.md

Если в вашем локальном филиале не было уникальных коммитов, вместо этого git выполнит «ускоренную перемотку вперед»:

$ git merge upstream/master
Updating 34e91da..16c56ad
Fast-forward
 README.md                 |    5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

Совет: если вы хотите обновить свой репозиторий на GitHub, следуйте инструкциям здесь

jumpnett
источник
1
Это обновляет мой локальный форк, но мой форк на Github.com по-прежнему говорит «43 коммитов позади». Мне пришлось использовать технику Лобзика, чтобы создать для меня запрос на извлечение, чтобы объединить основные изменения с моим форком Github.com.
Майкл Макгиннис,
11
@MichaelMcGinnis После локального слияния вам придется отправить свои изменения в github. git push origin master
Jumpnett
1
Может быть, уместно продвинуться вперед --follow-tags: stackoverflow.com/a/26438076/667847
Кенни
1
Я должен сделать это для всех ветвей отдельно git merge upstream/master, а затем проверить, чтобы разработать ветку и сделатьgit merge upstream/develop
Shobi
stackoverflow.com/a/14074925/470749 был полезен для меня, потому что я получал, Permission denied (publickey). fatal: Could not read from remote repository.когда пытался выбрать из учетной записи Github Facebook вверх по течению.
Райан
98

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

  1. Измените каталог на ваш локальный репозиторий.

    • Переключитесь на главную ветку, если вы не git checkout master
  2. Добавьте родителя в качестве удаленного хранилища, git remote add upstream <repo-location>

  3. вопрос git fetch upstream
  4. вопрос git rebase upstream/master

    • На этом этапе вы проверяете, что фиксирует то, что будет объединено, набрав git status
  5. вопрос git push origin master

Для получения дополнительной информации об этих командах обратитесь к шагу 3 .

Сахар Рабиновиз
источник
13
@MT: Где вы вводите эти команды, хотя? Суть вопроса, насколько я понимаю, заключается в том, как ресинхронизировать ваш личный форк GitHub с основным проектом, и сделать все это из GitHub . Другими словами, как вы можете обновить свой удаленный форк без локального репозитория?
Джон Y
4
@JohnY Использование GitHub всегда создает дополнительный коммит. Вы должны сделать все это в оболочке локального репо, чтобы избежать этого дополнительного коммита.
Джонатан Кросс
49

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

Из локального клона вашей вилки создайте свой удаленный пульт. Вам нужно сделать это только один раз:

git remote add upstream https://github.com/whoever/whatever.git

Тогда всякий раз, когда вы хотите догнать ветку основной ветки репозитория, вам необходимо:

git checkout master
git pull upstream master

Предполагая, что вы никогда ничего не совершали на хозяина, вам уже покончено. Теперь вы можете подтолкнуть вашего локального мастера к исходной удаленной вилке GitHub. Вы также можете переназначить свою ветку разработки на своем современном локальном мастере.

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

Slion
источник
48

Предисловие: ваш форк - это «источник», а репозиторий, из которого вы разветвлены, - «восходящий».

Давайте предположим, что вы уже клонировали свой форк на свой компьютер с помощью команды, подобной этой:

git clone git@github.com:your_name/project_name.git
cd project_name

Если это дано, вам нужно продолжить в следующем порядке:

  1. Добавьте «upstream» в ваш клонированный репозиторий («origin»):

    git remote add upstream git@github.com:original_author/project_name.git
    
  2. Получить коммиты (и ветки) из "вверх по течению":

    git fetch upstream
    
  3. Переключитесь на ветку «master» вашего форка («origin»):

    git checkout master
    
  4. Храните изменения вашей "главной" ветки:

    git stash
    
  5. Объедините изменения из "master" ветви "upstream" в вашу "master" ветку вашего "origin":

    git merge upstream/master
    
  6. Разрешите конфликты слияния, если они есть, и зафиксируйте слияние

    git commit -am "Merged from upstream"
    
  7. Нажмите изменения в вашей вилке

    git push
    
  8. Верните свои скрытые изменения (если есть)

    git stash pop
    
  9. Вы сделали! Поздравляем!

GitHub также предоставляет инструкции по этой теме: Синхронизация форка

Бенни Нойгебауэр
источник
1
Помогло частично: это git remote add upstream git@github.com:original_author/project_name.gitпросто псевдоним для git remote add upstream https://github.com/original_author/project_name.git?
Вольф
2
Волк , думаю, ты уже знаешь это, но для потомков ... Это формат для ssh. help.github.com/articles/configuring-a-remote-for-a-fork
Брэд Эллис
2
Большое спасибо. git stashи git stash popчасть очень полезна
जयते जयते
Это сработало. После git merge upstream / master автоматическое слияние завершилось неудачно из-за разархивированных путей, по которым мне пришлось выполнить git add -A, затем git commit -m "message", тогда это было актуально.
highcenbug
45

С ноября 2013 года в GitHub был открыт неофициальный запрос на добавление очень простого и интуитивно понятного метода синхронизации локального разветвления с восходящим:

https://github.com/isaacs/github/issues/121

Примечание. Поскольку запрос функции является неофициальным, рекомендуется также связаться support@github.comс вами, чтобы добавить поддержку для реализации подобной функции. Вышеуказанный неофициальный запрос может быть использован как свидетельство заинтересованности в этом.

isedwards
источник
23

На момент получения этого ответа GitHub не имеет ( или я больше не скажу? ) Этой функции в веб-интерфейсе. Вы можете, однако, попросить support@github.comдобавить свой голос за это.

Тем временем, пользователь GitHub bardiharborow создал инструмент для этого: https://upriver.github.io/

Источник находится здесь: https://github.com/upriver/upriver.github.io

Лусеро
источник
2
Хотя я нахожу инструмент хорошей идеей, реальность такова, что она сломана. Он загрузил только 20 репозиториев из моей учетной записи, и даже нижний колонтитул перенаправляет на сайт, который не существует. Если это будет исправлено, я буду большим защитником.
сорин
2
На сегодняшний день я успешно использовал upriver для синхронизации форка с обратным репозиторием, поэтому он работает для моих целей, и я буду продолжать его использовать.
NauticalMile
1
@sorin Ограничение в 20 репо / веток (точнее, сейчас 30) исходит из настроек подкачки GitHub по умолчанию. Для этого необходимо внести некоторые изменения в код.
Андреас
19

Если вы используете GitHub для Windows или Mac, то теперь у них есть возможность одним щелчком мыши обновить вилки:

  1. Выберите хранилище в пользовательском интерфейсе.
  2. Нажмите кнопку «Обновить от пользователя / филиала» вверху.
Шиталь шах
источник
2
Шаг за шагом: github.com/desktop/desktop/issues/1785#issuecomment-483011281
Аламаканамбра
11

На самом деле, можно создать ветку в вашем форке из любого коммита восходящего потока в браузере:

  • Open https://github.com/<repo>/commits/<hash>, где repo - ваш форк, а hash - полный хеш коммитов, который вы можете найти в вышестоящем веб-интерфейсе. Например, я могу открыть https://github.com/max630/linux/commits/0aa0313f9d576affd7747cc3f179feb097d28990 , который указывает на linux masterвремя написания.
  • Нажмите на кнопку «Дерево: ....».
  • Введите название новой ветки и нажмите Enter

Введите описание изображения здесь

Затем вы можете извлечь эту ветку в свой локальный клон, и вам не нужно будет отправлять все эти данные обратно в GitHub, когда вы вносите изменения поверх этого коммита. Или используйте веб-интерфейс, чтобы что-то изменить в этой ветке.

Как это работает (это предположение, я не знаю, как именно GitHub это делает): вилки совместно используют хранилище объектов и используют пространства имен для разделения ссылок пользователей. Таким образом, вы можете получить доступ ко всем коммитам через ваш форк, даже если они не существовали на момент разветвления.

max630
источник
2
Это замечательно! Это позволяет избежать абсолютно бессмысленной загрузки этих коммитов в github.
Rotsor
9

Выполните следующие шаги. Я попробовал их, и это помогло мне.

Оформить заказ в вашем филиале

Синтаксис: git branch yourDevelopmentBranch
Пример: мастер git checkout

Потяните ветку репозитория исходного кода для получения последней версии кода.

Синтаксис: git pull https://github.com/tastejs/awesome-app-ideas master
Пример: git pull https://github.com/ORIGINAL_OWNER/ORIGINAL_REPO.git BRANCH_NAME

Venkat.R
источник
1
Если вы используете GitHub, вы также можете отправить свои изменения в ветку GitHub. git push HttpsForYourForkOfTheRepo BRANCH_NAME
user3731622
9

Я обновляю свои разветвленные репо этой строкой:

git pull https://github.com/forkuser/forkedrepo.git branch

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

R.Bravo
источник
2
Есть ли ограничения на это? то есть применимо ли это только к случаям, когда вы не добавляли коммиты, слияния, запросы на извлечение или с момента последнего обновления объединяли запросы на добавление.
LightCC
1
это работает как обычное извлечение из удаленной ветки. Если вы сделали X коммитов в своем локальном репо, и теперь вы Y коммитов за исходным репо, это принесет Y коммитов в ваш локальный филиал и, возможно, даст вам некоторые конфликты для разрешения.
Р.Браво
1
@LightCC Это ничем не отличается от извлечения ранее добавленного пульта, за исключением того факта, что вы не добавили пульт . Поэтому недостатком является то, что вам придется вводить полный URL-адрес хранилища каждый раз, когда вы захотите pull.
23
1
Это идеальное решение, если вам не нужно много раз выходить из исходного репо, или проект разветвлен относительно просто.
AxeEffect
7

В качестве дополнения к этому ответу я искал способ обновить все удаленные ветки моего клонированного репо ( источника ) из вышестоящих веток за один раз. Вот как я это сделал.

Это предполагает , что вы уже настроили на входе пульта дистанционного управления , указывая на репозиторий (где происхождение было раздвоенным от) и синхронизировали его с git fetch upstream.

Затем запустите:

for branch in $(git ls-remote --heads upstream|sed 's#^.*refs/heads/##'); do git push origin refs/remotes/upstream/$branch:refs/heads/$branch; done

Первая часть этой команды перечисляет все заголовки в удаленном репо восходящего направления и удаляет SHA-1, за которым refs/heads/следует префикс имени ветви.

Затем для каждой из этих ветвей она отправляет локальную копию восходящей удаленной ветви отслеживания ( refs/remotes/upstream/<branch>на локальной стороне) непосредственно в удаленную ветку на источнике ( refs/heads/<branch>на удаленной стороне).

Любая из этих команд синхронизации веток может завершиться с ошибкой по одной из двух причин: либо ветка upstream была переписана, либо вы передали коммиты в этой ветке на ваш форк. В первом случае, когда вы ничего не добавили в ветку на своей вилке, можно принудительно нажать (добавьте ключ -f ; т.е. git push -fв приведенной выше команде). В другом случае это нормально, так как ваша ветвь ветвления разошлась, и вы не можете ожидать, что команда sync будет работать до тех пор, пока ваши коммиты не будут объединены с апстримом .

Томас Гайот-Сионнест
источник
6

Приложение "Pull" - это решение для автоматической настройки и забывания. Он будет синхронизировать ветку по умолчанию вашего форка с репозиторием upstream.

Зайдите на URL, нажмите зеленую кнопку «Установить» и выберите репозитории, в которые вы хотите включить автоматическую синхронизацию.

Ветвь обновляется один раз в час непосредственно на GitHub, на вашем локальном компьютере вам нужно извлечь основную ветку, чтобы убедиться, что ваша локальная копия синхронизирована.

krlmlr
источник
2
Обратите внимание, что при базовой настройке вы можете потерять изменения, внесенные в ваш разветвленный репозиторий. Чтобы сохранить изменения, настройте файл конфигурации и укажите mergemethod. Подробнее об этом здесь
Saurabh P
1
Я заметил, что базовая настройка отправляет запросы извлечения и объединяет их (в отличие от того, что указано в документации). Это немного раздражает, но решает проблему потери данных?
krlmlr
4

Android Studio теперь научилась работать с вилочными репозиториями GitHub (вам даже не нужно добавлять «восходящий» удаленный репозиторий по команде консоли).

Откройте меню VCSGit

И обратите внимание на два последних пункта всплывающего меню:

  • Перебазировать мою вилку GitHub

  • Создать запрос на извлечение

Попробовать их. Я использую первый для синхронизации моего локального хранилища. В любом случае ветки из родительского удаленного репозитория («upstream») будут доступны в Android Studio после того, как вы нажмете «Rebase my GitHub fork», и вы сможете легко с ними работать.

(Я использую Android Studio 3.0 с подключаемыми модулями Git и GitHub.)

Введите описание изображения здесь

alexshr
источник
4

Когда вы клонировали свой разветвленный репозиторий, перейдите в путь к каталогу, где находится ваш клон, и в несколько строк в вашем Git Bash Terminal.

$ cd project-name

$ git remote add upstream https://github.com/user-name/project-name.git
 # Adding the upstream -> the main repo with which you wanna sync

$ git remote -v # you will see the upstream here 

$ git checkout master # see if you are already on master branch

$ git fetch upstream

И вот вам хорошо идти. Все обновленные изменения в основном репозитории будут помещены в ваш репозиторий fork.

Команда «fetch» ​​необходима для того, чтобы быть в курсе последних событий проекта: только при выполнении «git fetch» ​​вы будете информированы об изменениях, которые ваши коллеги отправили на удаленный сервер.

Вы все еще можете посетить здесь для дальнейших запросов

Пратик Чанда
источник
4

Если вы установите свой апстрим. Посоветуйтесь git remote -v, тогда этого будет достаточно.

git fetch upstream
git checkout master
git merge --no-edit upstream/master
git push
прости
источник
2

Это зависит от размера вашего хранилища и от того, как вы его разветвили.

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

Попробуйте прочитать это . В нем описывается, как обращаться с большими репозиториями Git и как добавлять в них последние изменения.

s0nicYouth
источник
2

Я хотел бы добавить к @ krlmlr - х ответа .

Первоначально раздвоенное хранилище имеет один филиал по имени: master. Если вы работаете над новой функцией или исправлением, вы обычно создаете новую ветку featureи вносите изменения.

Если вы хотите, чтобы разветвленный репозиторий синхронизировался с родительским репозиторием, вы можете настроить файл конфигурации ( pull.yml) для приложения Pull ( в ветви функций ), например:

version: "1"
rules:
  - base: feature
    upstream: master
    mergeMethod: merge
  - base: master
    upstream: parent_repo:master
    mergeMethod: hardreset

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

Здесь два mergemethodsвступают в игру, один из hardresetкоторых помогает принудительно синхронизировать изменения в masterветви разветвленного репо с родительским репо, а другой - метод merge. Этот метод используется для объединения изменений, выполненных вами в featureветви, и изменений, выполненных из-за принудительной синхронизации в masterветви. В случае конфликта слияния приложение pull позволит вам выбрать следующий порядок действий при запросе на слияние.

Вы можете прочитать об основных и расширенных конфигурациях и различных mergemethods здесь .

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

Saurabh P Bhandari
источник
1

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

1. Создайте ветки из master-вилки и внесите в них изменения .

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

2. Создайте запланированное задание, чтобы мастер разветвления автоматически обновлялся .

Это можно сделать с помощью cron . Вот пример кода, если вы делаете это в Linux.

$ crontab -e

Поместите этот код crontab fileдля выполнения задания в почасовом режиме.

0 * * * * sh ~/cron.sh

затем создайте cron.shфайл сценария и взаимодействие git с ssh-agent и / или ожидайте, как показано ниже

#!/bin/sh
WORKDIR=/path/to/your/dir   
REPOSITORY=<name of your repo>
MASTER="git@github.com:<username>/$REPOSITORY.git"   
UPSTREAM=git@github.com:<upstream>/<name of the repo>.git  

cd $WORKDIR && rm -rf $REPOSITORY
eval `ssh-agent` && expect ~/.ssh/agent && ssh-add -l
git clone $MASTER && cd $REPOSITORY && git checkout master
git remote add upstream $UPSTREAM && git fetch --prune upstream
if [ `git rev-list HEAD...upstream/master --count` -eq 0 ]
then
    echo "all the same, do nothing"
else
    echo "update exist, do rebase!"
    git reset --hard upstream/master
    git push origin master --force
fi
cd $WORKDIR && rm -rf $REPOSITORY
eval `ssh-agent -k`

Проверьте ваш разветвленный репозиторий. Время от времени он всегда будет показывать это уведомление:

Эта ветка даже с <upstream>: master .

введите описание изображения здесь

Chetabahana
источник
0

Используйте эти команды (в случае удачи)

git remote -v
git pull
git fetch upstream
git checkout master
git merge upstream/master --no-ff
git add .
git commit -m"Sync with upstream repository."
git push -v
До Нху Вы
источник