В локальной директории своего репозитория нужно добавить как дополнительный ремоут основной репозиторий, куда ты отправляешь задания на проверку
$ git remote add upstream <тут https ссылка на основной репозиторий>пример ссылки на основной репозиторий:
https://github.com/organization-name/project.git
Так, в проекте будет 2 ремоута:
- origin - указывающий на https://github.com/your-name/project
- upstream - указывающий на https://github.com/organization-name/project
Теперь, нужно получить изменения из основного репозитория (upstream), где были приняты задания
$ git checkout master
$ git pull upstream masterИзменения получены, теперь наша задача сделать так, будто работа в ветке фичи (назовем ее, предположим feature-N) была сделана после появления новых коммитов в master
Для этого:
$ git checkout feature-N
$ git rebase masterЕсли окажется, что новые изменения в master относятся к тем-же строчкам кода, что и изменения в ветке feature-N - возникнет конфликт.
В этом случае в консоли будет:
CONFLICT (content): Merge conflict in <имя файла>
Failed to merge in the changes.
…
When you have resolved this problem, run "git rebase --continue".Если конфликта не возникло - перейти к последнему шагу "Готово"
Чтобы разрешить конфликт:
-
Открой файл с конфликтом в тектовом редакторе В файле появятся знаки
>>>>>>,======и<<<<<, между ними будут два конфликтующих участка кода. -
Из двух участков кода, нужно выбрать только один, актуальный, и удалить строки в которых были множественные
>,=,<т.е. привести изменения в файле к такому виду -
Сохраняем файл, говорим что конфликт решен
$ git add <имя файла>- Заканчиваем rebase
$ git rebase --continueЕсли конфликты возникли во множестве файлов, увидеть их все можно с помощью
git status
Но, история изменений в ветке feature-N изменилась, а чтобы изменить историю в этой ветке на github, нужно сделать форсированный пуш
не забывай:
origin- твой репозиторий,upstream- основной, где выполняются проверки
$ git push origin +feature-N