Вы неправильно поняли, как работает Git.Или как работает хостинг контента.
Прежде всего, ваш репо не находится ни на GitHub, ни на GitLab.Ваш репозиторий находится на вашем жестком диске, там, где вы его клонировали или создали.Это хранилище.Местный.Здесь вы выполняете работу *)
На GitHub и GitLab вы можете настроить удаленную копию вашего хранилища.Затем, после того как вы поработали с вашим локальным репо, вы можете дать команду своему локальному репо отправить эти новые фрагменты работы в эту удаленную копию.Или в другую удаленную копию.Или до 50 удаленных копий, хранящихся в разных местах.
Вторым фактом является то, что GitHub и GitLab являются отдельными .Фактически, есть один GitHub, но нет единого GitLab.Есть много GitLabs, вы даже можете купить сервер и разместить свой собственный GitLab.Это только подчеркивает, что они все отдельные.Все, что вы отправляете на GitHub, НЕ будет волшебным образом отображаться на GitLab1, ни на GitLab2, ни (..)
В-третьих, все они раздельные, но все они позволяют вам размещать копии вашего git-репо.Поскольку вы можете указать локальному репо отправлять вещи на несколько пультов , вы можете синхронизировать их все.
Однако, вставляя все URL-адреса на все серверы каждый раз, когда вы хотите выполнитьpush будет громоздким, поэтому ваше местное git-репо можно научить узнавать удаленные места и запоминать их для вас.Это называется remotes, и вы, вероятно, уже видели его в форме:
git push origin master
\ \
\ branch to be pushed
name of the remote
origin - это типичное имя для одного удаленного сервера, с которым вы работаете.Но если вы хотите иметь много, вы, вероятно, захотите установить несколько значимых имен, таких как:
git remote add remote-github (url-to-repo-on-github)
git remote add remote-gitlab1 (url-to-repo-on-gitlab1)
git remote add remote-gitlab2 (url-to-repo-on-gitlab2)
...
Это устанавливает 3+ пультов с разными именами.Теперь вы можете:
git push remote-github master
git push remote-gitlab1 master
и так далее.Это сработает - в основном, внесите изменения в код, зафиксируйте их, отправьте их на 3+ сервера, и вы получите «те же самые вещи на GitHub и GitLab».Имейте в виду, что если вы не одиноки и если вы позволите кому-то поработать над вашим кодом на GitHub / GitLab по отдельности, всем придется нажимать на все удаленные устройства одновременно и в одном и том же порядке, иначе он может быстро расходиться.
Ручное нажатие на 2+ пульта дистанционного управления также может быть несколько громоздким, даже если они запоминаются по именам.Вот почему последние версии Git позволяют устанавливать несколько push-URL под одним именем удаленного .
. Кроме того, репозитории Git и некоторые хостинги Git поддерживают «триггеры» или «ловушки».Эти вещи позволяют вам установить скрипт, который будет выполняться каждый раз, когда что-то происходит.Что-то вроде коммита или толчка.Используя это, вы можете указать своему хостингу, например, при каждом полученном push-запросе выполнить push-запрос к другому удаленному репо.Но я не буду это освещать, здесь и сейчас, я думаю, что у вас уже достаточно ключевых слов для поиска!
*), за исключением некоторых полуавтоматических вещей, таких как PR / MRs / Reviews / Issues / etc - ноэто зависит от вашего рабочего процесса и поддержки его на хостинг-сайте.Очевидно, что поскольку сайты являются отдельными и поддержка функций может отличаться, PR / MRs / Reviews /../ и т. Д., Выполняемые на одном сайте, не будут волшебным образом переходить на другие сайты.Если конкретная функция реализована с помощью веток, вы можете синхронизировать ее с помощью некоторых хуков и сценариев.В противном случае вам нужно будет найти подходящий плагин для сайта.Или, ну, напиши это сам.IIRC, по крайней мере, у GitLab есть API для этого.