GitHub, GitLab, Bitbucket: где живет код
Git локальный, а команде нужен общий
Git устроен так, что центрального сервера ему не требуется: у каждого, кто склонировал проект, лежит полная копия со всей историей. Но команде все равно нужна одна копия, которую все договорились считать главной, общая точка, куда каждый отправляет свои изменения и откуда забирает чужие. Такую копию называют удаленным репозиторием, а платформы вроде GitHub, GitLab и Bitbucket его хранят и обвешивают полезными инструментами вокруг.
Как код попадает на платформу
Между вашим локальным репозиторием и удаленным есть три команды.
`git clone` копирует удаленный репозиторий к вам на машину целиком, со всей историей, так вы получаете проект в первый раз. `git push` отправляет ваши новые коммиты на удаленный репозиторий. `git pull` забирает оттуда коммиты, которые добавили другие. Получается простой ритм: забрал свежее (pull), поработал локально привычными add и commit, отправил результат (push).
Push отправляет коммиты на удаленный репозиторий, pull забирает чужие
Главное здесь в том, что коммиты, ветки, история остаются тем же Git. Платформа не заменяет его, а дает репозиторию общий адрес в сети и хранит его копию.
Что платформы добавляют поверх Git
Если бы дело было только в хранении, хватило бы любого сервера. Ценность платформ в инструментах совместной работы, которые надстроены над Git:
- Ревью кода перед слиянием – чужие изменения сначала смотрят и обсуждают, и только потом вливают в основную ветку.
- Задачи (issues) – трекер, где заводят баги и задачи и привязывают их к коммитам.
- Управление доступом – кто может только читать, кто отправлять коммиты, кто вливать в
main. - CI/CD – автоматический запуск сборки, тестов и деплоя по событиям в репозитории.
- Веб-интерфейс – смотреть код, историю и диффы через браузер, не открывая терминал.
Pull request, проверка кода перед слиянием
Из этого набора стоит отдельно разобрать ревью, потому что на нем держится командная работа. Слияние веток с прошлого шага в команде почти никогда не делают молча, командой git merge у себя на машине. Вместо этого открывают запрос на слияние: на GitHub его называют pull request, на GitLab – merge request, но суть одна.
Pull request: ветка, ревью, правки или merge в main
Вы отправляете свою ветку на платформу и открываете запрос: «прошу влить вот это в main». Коллеги видят дифф, те самые строки с плюсами и минусами, обсуждают, просят поправить. Когда изменения одобрены, ветку вливают через кнопку на платформе. Так в основную ветку не попадает код, который никто не посмотрел, а у каждого изменения остается история обсуждения (по крайней мере в идеальном мире).
Три платформы
Платформ много, но на слуху три, и Git под ними один и тот же. Различаются они акцентами.
| Платформа | Чем известна |
|---|---|
| GitHub | Крупнейшая, дом почти всего open source. Основана в 2008, с 2018 принадлежит Microsoft. Свой CI/CD – GitHub Actions |
| GitLab | Единая платформа с сильным встроенным CI/CD. Можно развернуть на своих серверах, что важно для компаний и для DevOps |
| Bitbucket | От компании Atlassian, тесно связана с ее же трекером Jira. Часто встречается там, где команда уже сидит на продуктах Atlassian |
Общего у них больше, чем различий: все хранят Git-репозитории, у всех есть запросы на слияние, задачи и CI/CD. Выбор обычно диктует не сама платформа, а то, что уже используют в компании.
Git это не GitHub
Git – это программа контроля версий, она работает у вас локально и ни от какой платформы не зависит. GitHub (как и GitLab, и Bitbucket) – это сервис, который хранит Git-репозитории в сети и добавляет вокруг них совместную работу. Можно годами пользоваться Git без единого аккаунта на GitHub. Верно и обратное: репозиторий легко перенести с одной платформы на другую, потому что под капотом везде один и тот же Git. Платформа служит местом хранения и сервисом, а Git остается инструментом.
Причем здесь DevOps
Для девопса удаленный репозиторий не просто хранилище, а центр, вокруг которого крутится доставка. Именно отправка коммита на платформу запускает пайплайн CI/CD: push в репозиторий, и автоматически пошли сборка, тесты, деплой.
Здесь же живет код инфраструктуры: конфиги, скрипты автоматизации, описания серверов. Запрос на слияние становится воротами, через которые любое изменение проходит ревью, прежде чем уехать в продакшен, а история репозитория служит журналом для разбора инцидентов. Отдельно важна возможность GitLab разворачиваться на собственных серверах: компаниям, которым нельзя отдавать код наружу, это позволяет держать всю разработку и доставку внутри своего контура.