Появилась тут ситуация, что нужно несколько remotes (удаленных репозиториев)
Как такое делается в git, было бы классно ссылку по теме?
Суть — есть библиотека на GitHub, которая используется в проекте. В ней есть косяки, также в нее нужно добавить некоторые фичи.
Библиотека не моя (форк). Используется через npm.
Сейчас сборка проекта настроена брать библиотеки вместо npmjs c
devops artifacts (т.е. через прокси по сути)
Туда публикуется измененная версия оригинальной библиотеки (кастомная сборка), которая заменяет оригинальную, и подсовывается приложению.
Хочется иметь возможность вносить изменения в библиотеку, и обновляться с оригинала.
Также хочется периодически отправлять PR в исходную библиотеку.
Итого получается "конфигурация" из 3-х удаленных репозиториев:
— основной репозиторий библиотеки на github
— форк этого репозитория на github (из которого можно делать PR в основной)
— приватный репозиторий проекта на devops, из которого делается сборка "кастомной" версии.
Я так понимаю, для этого добавляется 3 remotes:
$ git remote -v
> origin https://github.com/YOUR_USERNAME/NAME.git (fetch)
> origin https://github.com/YOUR_USERNAME/NAME.git (push)
> upstream https://github.com/ORIGINAL_OWNER/NAME.git (fetch)
> upstream https://github.com/ORIGINAL_OWNER/NAME.git (push)
> build https://user@dev.azure.com/org/project/_NAME(fetch)
> build https://user@dev.azure.com/org/project/_NAME (push)
>
Я пока не очень понял, как эта конструкция работает с ветками?
То есть, как оно узнает куда пушить ветку? Это специально задается на push/pull, типа так?
> git pull origin master
> git push build master
Здравствуйте, bnk, Вы писали:
bnk>Появилась тут ситуация, что нужно несколько remotes (удаленных репозиториев)
bnk>Как такое делается в git, было бы классно ссылку по теме?
Ссылок не видно, но вообще банально. Только умолчания перестают работать.
Вот если залезешь в ~git/.config, увидишь там что-то вроде
[branch "master"]
remote = origin
merge = refs/heads/master
Поэтому, если ты сидя на master скажешь
git pull, оно полезет по умолчанию — на origin. А если скажешь
git pull repo2 master:master, то оно пойдёт пуллить repo2.
(Там ещё вопрос в режимах pull и push — есть одноветочный, есть все ветки на все, но локально по такой команде меняет состояние только для текущей ветки, остальные запоминает.)
bnk>Я пока не очень понял, как эта конструкция работает с ветками?
bnk>То есть, как оно узнает куда пушить ветку? Это специально задается на push/pull, типа так?
bnk>>> git pull origin master
>> git push build master
bnk>
Да, так прямее всего.
Здравствуйте, netch80, Вы писали:
N>Ссылок не видно, но вообще банально. Только умолчания перестают работать.
N>Вот если залезешь в ~git/.config, увидишь там что-то вроде
N>N>[branch "master"]
N> remote = origin
N> merge = refs/heads/master
N>
N>Поэтому, если ты сидя на master скажешь git pull, оно полезет по умолчанию — на origin. А если скажешь git pull repo2 master:master, то оно пойдёт пуллить repo2.
N>(Там ещё вопрос в режимах pull и push — есть одноветочный, есть все ветки на все, но локально по такой команде меняет состояние только для текущей ветки, остальные запоминает.)
bnk>>Я пока не очень понял, как эта конструкция работает с ветками?
bnk>>То есть, как оно узнает куда пушить ветку? Это специально задается на push/pull, типа так?
bnk>>>>> git pull origin master
>>> git push build master
bnk>>
N>Да, так прямее всего.
Понятно, пасиб! Чем дальше в лес тем толще партизаны
Поскольку всегда работал по умолчанию, не подозревал что там уже все есть.
VS Code кстати (с
Git Graph) начинает забавно выглядеть когда подобное включаешь (когда несколько remotes). Но вроде все отображается и функционирует как надо
