Как использовать GitLab и GitHub вместе

Хостинг Source Control Source

GitHub был самым популярным сайтом для размещения проектов программного обеспечения с открытым исходным кодом с 2008 года. Он взял на себя инициативу, когда SourceForge не спешил внедрять недавно популярную систему контроля версий git . GitHub конкурирует с Bitbucket , благодаря корпоративной модели ценообразования и интеграции с другими инструментами Atlassian. Однако модель оплаты за конфиденциальность, а не численность персонала GitHub делает его доминирующей социальной платформой с открытым исходным кодом.

GitLab — новый конкурент, появившийся за последние пару лет и привлекающий значительное внимание сообщества. В отличие от вышеуказанных альтернатив, GitLab i Сам является открытым исходным кодом под лицензией MIT. Вы можете установить его локально на собственном оборудовании, что делает его привлекательным для компаний, которые не размещают свой код в облаке. Доход GitLab поступает в основном от продажи корпоративной версии с функциями безопасности и поддержкой высокой доступности.

Помимо раздачи или продажи пакетов для локальной установки, GitLab также предлагает SaaS-предложения, такие как GitHub и Bitbucket. В отличие от своих конкурентов, GitLab.com абсолютно бесплатен для публичных и частных репозиториев с неограниченным числом пользователей. Модель GitLab предполагает, что реальные деньги идут на предварительное программное обеспечение, и поэтому они используют SaaS для продвижения своего предварительного пакета.

Альтернатива GitHub?

GitLab заинтриговал меня за последние несколько месяцев. Помимо того, что они с открытым исходным кодом, они также активны в сообществе и в выпуске новых функций. Упомяните GitLab в Reddit или Hacker News, и генеральный директор обычно в течение часа ответит на любые вопросы.

Мне нравится выбор цветовых схем GitLab. Проанализировать запросы на выборку с более темной темой проще, чем с GitHub или черно-белым стилем Bitbucket. GitLab имеет интегрированную систему сборки CI, реестр контейнеров Docker, и всегда кажется, что на этом пути что-то новое.

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

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

Однако у хостинга проектов с открытым исходным кодом на GitHub есть свои преимущества. Многие разработчики публикуют репозитории в виде «портфолио» для целей резюме. Некоторые разработчики ищут участников, чтобы объединить их усилия. GitHub имеет гораздо большую пользовательскую базу, чем кто-либо другой, поэтому «сетевой эффект» сильно помогает в достижении обеих целей.

Лучшее обоих миров?

К счастью, можно сохранить преимущества сети GitHub при использовании GitLab в качестве основного хоста. С минимальными усилиями вы можете использовать GitLab в качестве основного хоста вашего репозитория, а также разместить зеркало на GitHub.

На странице «Новый проект» у GitLab уже есть опция для импорта существующего репозитория GitHub. Независимо от того, импортируете ли вы старый проект GitHub или создаете новый проект и отправляете его в GitLab и GitHub оба, вы можете воспользоваться двумя подходами:

Вариант 1. Создайте отдельные именованные пульты

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

Теперь вы можете взаимодействовать с GitLab или GitHub специально. Вы знаете это «происхождение» имя, которое 99% пользователей git вводят, не задумываясь об этом? Ну, это относится к вашему основному хосту, GitLab. Это новое удаленное имя «github» относится к GitHub (и вы можете использовать любое другое имя, которое вам нравится, оно только для удобства чтения).

Чтобы отправить изменения в любой репозиторий, используйте:

Вы бы выполнили изменения аналогичным образом:

Работая на основном хосте GitLab, вы просто периодически обновляете зеркало GitHub, нажимая на ветку «master». И наоборот, если кто-то из сообщества отправит запрос на извлечение на ваше зеркало GitHub, то рабочий процесс будет выглядеть следующим образом:

1. Просмотрите и объедините запрос на загрузку на GitHub
2. Потяните «мастер» в вашей локальной рабочей области
3. Нажмите «мастер» на GitLab

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

Вариант 2. Перегрузка источника с обоими удаленными

Не каждый проект ищет общественный вклад. Многие из проектов в моей учетной записи GitHub, в основном, представляют собой элементы «портфолио», предназначенные для возобновления, и я специально НЕ хочу пулл-запросов. Если ваш проект связан с одним разработчиком, вы можете пойти по более простому пути к зеркалу GitHub:

Вы не видите этот трюк каждый день, но в git отношения между удаленным именем и удаленным URL-адресом не обязательно взаимно-однозначные ! Git с радостью сопоставит удаленное имя с несколькими URL- адресами репозитория. Здесь мы перегружаем имя по умолчанию «origin» для ссылки на GitLab и GitHub. Итак, нормальный …

… подтолкнет (или вытянет) как ваш основной хост GitLab, так и ваше зеркало GitHub!

Это решение может быть немного СЛИШКОМ умным для больших групповых ситуаций, но для проектов, в которых вы являетесь единственным разработчиком, это, пожалуй, самый удобный способ.