Хранение кода в SCM / Хабр

Смотри, ты устроился работать в большую компанию, где много команд, каждая разрабатывает свой продукт, часть из них создаёт микросервисы вокруг ядра, часть создаёт свои отдельные полноценные продукты. И, допустим, вся разработка до сих пор не использует централизованное хранение кода, работает без CI/CD и без наработок DevOps. Твоей первой задачей поставили организовать подход к хранению исходного кода в рамках всей компании. По секрету скажу, большие компании любят, когда используется единый подход, индивидуализм для бизнес-конвейеров всегда означает сложность управления сроками разработки, поставки и т.д. Задача, которая кажется простой на первый взгляд, всегда обрастает сложностями в нюансах.

Ты настроен на волну NotOps и в этой статье я постараюсь ответить на вопросы:

• Что лучше монорепоз или отдельный репозиторий на отдельный продукт?

• Какие ролевые модели существуют?

• Какой flow использовать?

Начнём с организации хранения кода на глобальном уровне. С одной стороны, нас интересует ответ на вопрос «как хранить код?», с другой — как делать это безопасно. Организацию репозиториев под проекты глобально можно разделить на два варианта: один большой репозиторий на всё или один проект в компании — один репозиторий.

Первый вариант, так называемый монорепозиторий — когда весь исходный код всех проектов компании (или хотя бы всех проектов, которые связаны друг с другом) хранят в одном репозитории. Как это происходит? Есть репозиторий, внутри него каждая директория — отдельный проект, эти отдельные проекты могут или должны быть связаны друг с другом. Таким образом, каждый коммит в репозитории содержит набор исходного кода, который тесно взаимосвязан между собой и, фактически, при необходимости сделать релиз каждого проекта, нужно будет просто сделать сборку всего в рамках одного коммита и все эти проекты должны гарантированно работать. Чем гарантируется работа? Непрерывной интеграцией, а если точнее, то сборкой этого кода в каком-нибудь Jenkins с запуском тестов. В идеальной картине мира, один срез (каждый коммит) содержит в себе совместимые друг с другом версии продуктов. Естественно, как бы методологам не хотелось жить в мире идеальных разработчиков, где каждый задумывается о том, что делает и какие последствия это может принести для связанного сервиса, в жизни всё идёт слегка не по такому сценарию. На деле же, в лучшем случае, разработчик просто объявит остальным о том, что какой-то публичный интерфейс изменился, добавился новый, удалился старый, а уже будут они его использовать или нет — дело их. Следовательно, часть проектов начинают ставить в зависимость не то, что лежит в этом же коммите, рядом с их кодом, а какую-то конкретную версию, которую они точно проверяли. 

Кстати, по поводу применения изменений, погрузимся сразу здесь в жизненный цикл таких репозиториев. Чаще всего, монорепы живут в мире trunk based development. Не буду нагружать всей спецификой, передам только суть: разработчики не делают долгоиграющих веток. Вся разработка или коммитит напрямую в основную ветку постоянно или делает короткие feature бранчи, которые живут не дольше пары дней, а после заносятся в основную ветку через PR, с прогоном всей сборки/тестирования. Первый случай будет работать до тех пор, пока коммиты не так активно появляются в ветках, лично мне кажется, что даже 10 в день от каждого участника команды из 10 человек это уже много, что неизбежно приведёт к постоянным конфликтам слияний и начнёт замедлять разработку. Но второй способ лишь оттягивает эту неизбежность, так как конфликты никуда не денутся, просто наша основная ветка станет более «стабильной». И вот чтобы разрешить проблему очередности применения PR приходится придумывать какие-то собственные «решатели» конфликтов, которые ещё и будут формировать очередь из вливаемых PR. Понятное дело, пока вся компания это 10 человек, вместе с продуктом, разработчиками, тестировщиками и сопровождением и, фактически, у вас просто один проект на компанию, ваш монореп будет работать замечательно, восхитительно и быстро. Но я бы, если честно, такое монорепом назвал с натяжкой. Почему? Посмотрим на всем известных мастодонтов этой идеологии: MS, Google, Twitter, Yandex. Они монорепой называют не репозиторий, в котором лежит сразу бэк и фронт от одного проекта, не репозиторий с кодом и тестами, даже не репозиторий с исходниками и описанной инфраструктурой, для них монореп это именно солянка из проектов(каждый из которых может содержать свой фронт+бэк+тесты+инфраструктуру). Хоть один из них использует любой из инструментов версионирования без своих личных доработок и автоматизаций? Нет, конечно. Причём, существует мнение, что git не очень подходит для таких репозиториев, поэтому MS, например, сделали VFSForGit. Угадаете для чего он нужен? На самом деле, такие большие репозитории никто не хочет полностью клонировать на свою рабочую станцию, тем более, никто не хочет индексировать его постоянно. Поэтому нужно или обеспечить частичную индексацию только нужного кусочка репозитория или дать доступ до какой-то виртуальной дисковой системы, где лежит весь код, а разработчик работает с нужной ему частью. Вот как раз вторым путём и пошёл Microsoft в своей доработке. Первый путь, это, например, использование svn вместо git. Вообще работа git, svn, hg и прочих scm это тема для отдельного большого исследования, если хотите услышать от меня об этом — пишите в комментариях, приготовлю материал.

Второй вариант хранения — каждый проект в своём репозитории. Тут, конечно, с одной стороны можно дробить до бесконечности (проект — репозиторий, бэк — репозиторий, класс — репозиторий), но, естественно, нужно идти путём здравого смысла и не уходить в крайности. Насколько сильно можно дробить код для каждого отдельного репозитория — вопрос к компании-работодателю и к зоне ответственности DevOps. Лично моё мнение, в идеальном мире DevOps в одном репозитории должно хранится всё, что связано с проектом. У нас же команды, скорее всего, по Agile, а значит одна команда отвечает за один продукт. Всё, что связано с продуктом лежит отдельно от остального, но вся команда отвечает за успешность этого продукта в целом. Причём, когда я говорю всё я подразумеваю, что в репозитории лежит сам код для сборки фронта и бека, код автотестов(если они есть), код для сборки на этапе CI и код для деплоя на этапе CD. Иными словами, посмотрев в один репозиторий ты сможешь полноценно оценить состояние проекта. Конечно, эта модель будет работать только в том случае, если компания  не только разрабатывает продукт, она же его тестирует и сопровождает. Первые два этапа обычно всё же идут вместе, а вот сопровождение может производиться отдельными людьми в виду специфики бизнеса, например, вы просто вендор, который готовит продукт для других компаний. Но даже в таком случае можно выстроить процесс так, что весь проект живёт внутри одного хранилища. Например, первоначальную версию деплоя сделали ваши разработчики, отдали его заказчикам, те использовали инструментарий, нашли тонкие места, где деплой не подходил в виду специфики рабочего окружения, указали доработки, которые им были необходимы, а разработчики, на основе обратной связи, довели деплой до условного «правильного» состояния. Иными словами, мы до сих пор сохраняем тот самый подход DevOps, то есть направленное взаимодействие двух составляющих и их тесную интеграцию. Но это всё, опять же, будет работать только в случае зрелой команды разработки и зрелой команды сопровождения, ну или хотя бы стремящихся к этой зрелости команд. 

С точки зрения организации версионирования, на самом деле, нет сильного отличия от мира монорепозиториев. Множество проектов живёт в модели GitHub flow. Очень грубо говоря, у нас есть некоторый стабильный branch и если нам нужно реализовать новую feature, делаем новую ветку от текущего состояния main, создаём эту самую feature, а потом, после успешного прохождения CI, вносим все изменения в main через Pull Request (Merge Request). Релиз, в данном случае, происходит сразу после внедрения новой фичи в main, что не всегда удобно, поэтому мне кажется лучшей альтернативой релизом считать тег на каком-то конкретном коммите ветки main, с последующей сборкой этой самой ревизии в виде дистрибутива, то есть у нас сразу несколько фич или фиксов попадает в один релиз, что с одной стороны замедляет time to market, но с другой даёт чуть большее пространство для сборки весомых релизов. Следовательно, всё это очень грубо похоже на trunk based development, есть основная ветка, все изменения в неё попадают достаточно быстро, релизы происходят только с неё. 

Помимо GitHub flow, есть изначально созданный Git flow, который достаточно сложно организован: есть отдельный main, который в себе содержит только релизные коммиты, на которые вешаются теги, есть отдельная ветка для каждого релиза, которая формируется из коммитов веток с хотфиксами, фичами и активной разработкой. Следовательно, вообразим себе, что мы разработчик, нам, в зависимости от типа задачи, над которой мы работаем, приходится создавать отдельную ветку или коммитить в уже существующую, их приходится время от времени мёрджить между собой в релизной ветке, когда релизная ветка будет наполнена весомым набором функционала (или подойдёт срок выпуска нового релиза), она должна будет влиться в main одним коммитом (желательно использовать стратегию squash, то есть все коммиты слить в единый большой коммит), на этот коммит будет выставлен тег и по этому тегу будет произведена сборка релизного дистрибутива.  

Где-то рядом можем ещё вспомнить Gitlab flow, который, как мне кажется, является чем-то средним между предыдущими двумя подходами. Для деплоя у нас должны быть отдельные ветки со staging, pre-prod и prod, для разработки у нас есть development и набор production веток, а релизы сводятся к тому, что разработчики вносят все изменения в свою main development ветку, после этого, как только будет принято решение, что код готов к релизу — создаётся отдельная релизная ветка на основе текущего состояния main и она уже используется для deployment flow. В релизной ветке с этого момента больше не ведётся активная разработка, в худшем случае, в неё при помощи cherry-pick можно занести конкретные изменения из коммитов разработчиков, всё остальное, что происходит с релизной веткой — она двигается по deploy и в неё вносятся изменения от ops части команды: настройка CD pipeline, изменения ansible playbook и тому подобное.

А теперь испортим всё, о чём я тут наговорил, ролевыми моделями доступа к этим самым репозиториям. Понимаю, очень хочется жить в мире сферических коней, когда все имеют доступ ко всему, вокруг сплошные самоорганизованные специалисты, которые понимают, что они делают. Реальность, конечно же, далека от этой позиции. Поэтому на многих контрибьюторов накладывают искусственные ограничения, например, запрещают вносить изменения напрямую в main, разрешают только через PR, причём PR обязательно должен быть собран нашей системой CI, об успешности сборки должно быть объявлено внутри системы хранения кода, а сам изменённый код должна посмотреть команда и одобрить его. Но помимо таких внутрикомандных ограничений существуют ещё кросс-командные ограничения. Если ты работаешь в маленькой компании, то для тебя сейчас это всё будет дико, но в больших компаниях действительно приходится задумываться о защите кода одной команды от другой, в таких компаниях намного сложнее создать один монорепозиторий на всю компанию. В зависимости от усиления степени параноидальности, которая часто коррелирует с количеством этих самых команд и количеством штатных единиц внутри команд, запрет может быть не только на запись в чужой репозиторий, но и на чтение из чужого репозитория и даже на запись одной частью команды в репозиторий своей же команды. Но погоди, пока не начинай кричать об этих задолбавших корпоратах с их бесконечной бюрократией, давай попробую объяснить. С запретом пушить в релизную или main ветку, думаю, всё понятно, тут просто работает принцип «не навреди», особенно хорошо он работает в том случае, если есть в команде джуны и сеньорам не очень хочется получить нерабочий или некомпетентный код в релизе напрямую, наоборот, хочется всё же проследить за качеством кода. На самом деле, даже в случае этих ограничений, «плохой» код в базу попадает, потому что все мы люди, можем и не отследить все изменения, поэтому усиливается автоматизация проверок, но это тоже тема отдельного материала, сейчас мы в эти дебри с тобой не пойдём. 

Теперь с запретом на запись в репозитории чужих команд, тут тоже более менее понятно, в больших компаниях требуется, чтобы команда занималась своим кодом и улучшала его, а не тратила время на улучшение кода чужой команды. В крайнем случае, если команда сделала свой проект настолько идеальным, что у неё есть время на доработки чужого, то ей или добавляют новых фич больше, или говорят, что их проект становится легаси, нужно делать новый, или команда делает fork чужого проекта и вносит изменения в чужой проект через него. Чаще всего большой работодатель стремится, чтобы команда работала над своим продуктом, а работа над другим продуктом должна производиться другой командой, тем самым, стараясь не сбавлять конвейерной мощности выпуска релизов всех продуктов, которые есть. 

Но читать-то почему чужой код нельзя? На самом деле, это тоже логично, особенно, если мы говорим про разработку чего-то более защищённого чем просто калькулятор. Например, в той же банковской структуре есть понимание стандарта безопасной разработки PA-DSS, по которому ты обязан делать свой код защищённым, продумывать все внешние интерфейсы и внутренние проверки таким образом, чтобы невозможно было внедрить чужеродную инъекцию, помимо этого есть ещё PCI-DSS стандарт, который требует обеспечение безопасности серверов и жёстких ролевых ограничений внутри самого продукта, грубо говоря, у каждого есть своя роль и, допустим, администратор системы может лишь администрировать систему, а вот внести изменения в балансе какого-то банковского счёта не имеет никаких прав. Логично предположить, что такие проекты должны быть максимально защищены от посторонних глаз, поэтому даже чтение исходного кода это некоторая вероятность заметить его изъяны, а они, естественно, есть всегда.

Но ведь не у всех компаний все проекты такие, почему ещё может быть запрещено чтение? Всё просто, большие компании — большие механизмы. Чем больше компания, тем труднее относиться к каждому сотруднику личностно и тем проще ей относится к нему, как к единице производящей работу. Следовательно, сотрудники относятся к компании точно так же. Место, где за свою работу ты получаешь денежное вознаграждение. Нет личного ощущения важности и нужности, Ты просто очередной винтик в огромной махине. А когда не относишься к своему делу лично, для некоторых людей это маркер того, что у большой махины можно что-то позаимствовать и передать это третьим лицам или же использовать в своих целях. Получается, что компании просто защищают свою интеллектуальную собственность, как от инъекций и попыток взлома, так и от появления конкурирующего игрока на рынке, который основан на их же собственной кодовой базе.  

Ну и третий слой паранойи, когда компания запрещает части команды чтение репозитория своей же команды. На самом деле, об эту бюрократию разбивается мой идеальный мир «один репоз — один проект». Потому что в таких случаях для каждого этапа или для каждой части команды, если хотите, создаётся отдельный репозиторий. Это тоже всё может дробиться по-разному, но как пример возьмём такую модель. У разработчиков и бека и фронта свой репозиторий, в котором они создают сам продукт, у тестировщиков свой репозиторий с автотестами, но они ещё могут читать исходный код в репозитории разработки, а у сопровождения свой репозиторий, в котором они хранят код деплоя, плейбуки, пайплайны и вот это всё, при этом они могут читать исходный код, тесты и редактировать свой репозиторий. Но в их репозиторий у остальных частей команды доступа может не быть, более того, сопровождение может вообще хранить свой код в отдельной системе, грубо говоря, у этапа CI свой gitlab, а у сопровождения какой-то свой. И у всех частей команды, кроме сопровождения, отсутствует физический доступ (сервера не пингуются) до системы хранения кода с пайплайнами. Такие модели существуют в том случае, если зоны ответственности строго разделены между участниками команды, плюс, чтобы защитить от утечек и разрешить возможность разработчикам, например, жить в менее защищённом мире с доступом во внешнюю сеть, а вот сопровождению наоборот, запретить выход во внешнюю сеть в принципе. Эта паранойя может усилиться в том случае, если сопровождение разделяется на несколько подвидов: часть отвечает за инфраструктуру как железо, часть за инфраструктуру как ОС и её настройки, часть за деплой продукта на инфраструктуру и сопровождение его работы. Тогда появляются дополнительные репозитории, дополнительные разграничения прав и дополнительные этапы согласований тех или иных изменений.

Резюмируем: хранение кода можно организовать как в монорепозиторий для всей компании, так и в несколько репозиториев. Оба подхода, как бы сильно не хотелось адептам этих двух лагерей, сводятся примерно к одному и тому же, проекты разрабатываются внутри своих каких-то сущностей, общее взаимодействие через проекты это, первоначально, взаимодействие команд между друг другом. Грамотно выстроенный и, что не менее важно, грамотно внедрённый процесс внедрения новых фишек в общий функционал важнее, чем способ хранения самого кода. При этом, сам процесс может как выстроить прозрачную систему взаимодействия всех звеньев команды, так и сжать все команды в набор бюрократических процедур, когда, с одной стороны, у нас построен DevOps, но с другой стороны, он сильно завязан на ролевой модели.

Естественно, я тут пробежался только по самым верхам, здесь ещё можно копать в сторону технических возможностей сделать из полирепозиториев видимость монорепозиториев при помощи всяких git subtree, можно было бы поговорить о том, что для монореп использовать git — в целом не самая хорошая затея, когда есть svn и hg. Поговорить о большом количестве инструментов, которые помогают справляться с проблемами технического характера, но лично мне кажется, что как раз техническая сторона вопроса — вполне решаема и в любом случае проще исправляема, чем сторона процесса. Всё всегда идёт от людей и решать, что и как использовать, должны тоже люди для своего же удобства, а инструментарий будет найден под любой выбранный способ. Но, это лишь мнение очередного человека из интернета и, как человеку, мне свойственно ошибаться.

Руководство по выбору репозитория исходного кода

Руководство по выбору репозитория кода для вашей команды

Выбираем средство для хостинга репозитория

В настоящее время существует множество решений для хостинга репозиториев ПО. У каждой системы репозиториев кода есть свои достоинства и недостатки. Кроме того, каждое решение для хостинга репозиториев поддерживает разные системы управления версиями, которые могут лежать в его основе. Это руководство призвано познакомить вас с требованиями, от которых зависит, какое средство управления репозиториями кода оптимально подходит вашей команде.

Разница между сервисами для хостинга репозиториев и системой управления версиями

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

Узнайте, как выбрать наиболее подходящую систему управления версиями для своей команды.

Сервисы для хостинга репозиториев — это сторонние веб-приложения, которые служат оболочкой для системы управления версиями и улучшают ее. Чтобы в полной мере использовать сервис для хостинга репозиториев, в его основе должна быть система управления версиями.

Какой репозиторий исходного кода выбрать?

Сервис для хостинга репозиториев — это организационное средство управления, которое обеспечивает наглядное представление процесса разработки ПО, который традиционно был непрозрачен. Хороший сервис для хостинга репозиториев отличают инструменты для измерения, отслеживания и обсуждения эффективности и правильности разработки ПО, а также для управления этими показателями. Сервис должен интегрироваться с другими средствами управления, такими как средства управления заданиями, управления взаимоотношениями с клиентами и управления заявками в службу поддержки. Только так можно создать связную сеть коммуникации в организации. Ваша компания может рассматривать разработку ПО как актив или как обязательство, однако в любом случае важно иметь полное представление об этом источнике риска.

Сервис для хостинга репозиториев — это организационное средство управления, которое обеспечивает наглядное представление процесса разработки ПО, который традиционно был непрозрачен. Хороший сервис для хостинга репозиториев отличают инструменты для измерения, отслеживания и обсуждения эффективности и правильности разработки ПО, а также для управления этими показателями. Сервис должен интегрироваться с другими средствами управления, такими как средства управления заданиями, управления взаимоотношениями с клиентами и управления заявками в службу поддержки. Только так можно создать связную сеть коммуникации в организации. Ваша компания может рассматривать разработку ПО как актив или как обязательство, однако в любом случае важно иметь полное представление об этом источнике риска.

Факторы, которые необходимо учитывать при выборе репозитория

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

Поддерживаемые системы управления версиями

Совместим ли сервис для хостинга репозиториев с системой управления версиями, которая используется в проекте? Это очень важный момент. Если в проекте используется Git, а сервис для хостинга не поддерживает эту систему, использовать сервис будет крайне затруднительно.

Размер команды и управление доступом

Во внимание необходимо принять состав команды, участвующей в проекте, и сам процесс работы. Всю работу выполняет один человек — или это командный проект? Команда работает дистанционно — или все участники команды работают в одном офисе? Какой уровень доступа к сервису для хостинга репозиториев нужен участникам команды?

График релизов

Ожидаются частые небольшие обновления или более крупные релизы, выходящие реже? У многих сервисов для хостинга репозиториев предусмотрены надстраиваемые инструменты для непрерывной интеграции и непрерывной поставки. Кроме того, вместе с сервисом для хостинга репозиториев могут предлагаться инструменты для отслеживания задач и управления релизами.

Размер проекта и хранилище данных

Будет ли в проекте вестись работа над двоичными файлами данных крупного размера, такими как трехмерная графика или аудиофайлы? Некоторые программные решения для репозиториев созданы специально для упрощенной работы с большими файлами. Какое регулярное количество коммитов ожидается в проекте? Давно ли создан проект и есть ли у него большая история, для загрузки которой может потребоваться какое-то время?

Интеграция с внешними инструментами и решениями сторонних разработчиков

Важнейшей возможностью сервиса для хостинга репозиториев является его интеграция со сторонними инструментами и сервисами. Такие связи позволяют по-настоящему раскрыть потенциал рабочих процессов пользователя репозитория. Наиболее распространенными вариантами являются интеграция со средствами обработки заявок и управления заданиями, управления поддержкой клиентов и автоматизации контроля качества. Если ваша команда уже использует то или иное средство, убедитесь, что репозиторий может с ним взаимодействовать.

Сравнение решений для репозиториев кода

В таблице ниже перечислены эти факторы и сравниваются различные сервисы для хостинга репозиториев.

Возможности и требования

Bitbucket

GitHub

GitLab

Проверка кода

Большая часть времени, которое ваши команды тратят на использование сервиса для хостинга репозиториев, может быть отведено обсуждению проверки кода. Вспомогательные средства для проверки кода являются стандартной важной возможностью разных сервисов для хостинга. Важно подобрать такой процесс проверки, который соответствовал бы стилю работы ваших команд.

Bitbucket

GitHub

GitLab

Оптимальная интеграция с Jira

Выпускайте релизы на 14 % чаще, используя Jira Software и Bitbucket. Эти инструменты идеально интегрированы на всех этапах, от момента создания ветки до момента развертывания. Создавайте ветки Bitbucket из Jira Software и изменяйте статус задач, не покидая Bitbucket.

Bitbucket

GitHub

GitLab

Вики

Ключевую роль в эффективности команды может играть хранение проектной документации в легкодоступном месте рядом с исходным кодом проекта. Сервисы для хостинга репозиториев позволяют размещать сопроводительную документацию вместе с исходным кодом.

Bitbucket

GitHub

GitLab

Бесплатные закрытые репозитории

Разработка программного обеспечения с открытым исходным кодом стоит на принципах бесплатности и доступности исходного кода. По этой причине некоторые сервисы для хостинга репозиториев предоставляют возможность конфиденциального доступа в качестве премиум-услуги. Если конфиденциальность играет важную роль для достижения ваших коммерческих целей, это следует учитывать при выборе сервиса для хостинга репозитория.

Bitbucket

GitHub

GitLab

Сертификация Soc 2 Type II

Bitbucket — первое из распространенных Git-решений, которое гарантирует, что код не будет раскрыт посторонним лицам, что коду обеспечена полная сохранность и что облачная среда проверена независимыми аудиторами на соответствие стандарту SOC 2 Type II.

Bitbucket

GitHub

GitLab

Специальный поиск по коду

Анализируйте поисковые результаты быстрее благодаря семантическому поиску, который располагает определения в начале списка (выше повторных использований и имен переменных).

Bitbucket

GitHub

GitLab

Встроенные возможности CI/CD

Bitbucket Pipelines — это функциональная возможность Bitbucket, которая обеспечивает единое рабочее пространство для сборки, тестирования и развертывания кода с использованием интегрированного конвейера непрерывной интеграции и непрерывной доставки (CI/CD). Используйте все преимущества неограниченного масштабирования и конфигурации как кода, не тратя силы на управление инфраструктурой сборки.

Bitbucket

GitHub

GitLab

команды

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

Bitbucket

GitHub

GitLab

Размещение на собственном оборудовании

С помощью Bitbucket Server ваша команда может надежно и безопасно размещать конфиденциальные проекты организации и связанный с ними код в VPN или другой защищенной внутренней сети.

Bitbucket

Bitbucket Server

GitHub

Только для корпоративных клиентов

GitLab

Bitbucket Server

Только для корпоративных клиентов

Возможности и требования

Возможности и требования

Bitbucket

GitHub

GitLab

Bitbucket

GitHub

GitLab

Проверка кода

Большая часть времени, которое ваши команды тратят на использование сервиса для хостинга репозиториев, может быть отведено обсуждению проверки кода. Вспомогательные средства для проверки кода являются стандартной важной возможностью разных сервисов для хостинга. Важно подобрать такой процесс проверки, который соответствовал бы стилю работы ваших команд.

Bitbucket

GitHub

GitLab

Оптимальная интеграция с Jira

Выпускайте релизы на 14% чаще, используя Jira Software и Bitbucket. Эти инструменты идеально интегрированы на всех этапах, от момента создания ветки до момента развертывания Создавайте ветки Bitbucket, не выходя из Jira Software, или передавайте задачи, продолжая работать в Bitbucket.

Bitbucket

GitHub

GitLab

Вики

Ключевую роль в эффективности команды может играть хранение проектной документации в легкодоступном месте рядом с исходным кодом проекта. Сервисы для хостинга репозиториев позволяют размещать сопроводительную документацию вместе с исходным кодом.

Bitbucket

GitHub

GitLab

Бесплатные закрытые репозитории

Разработка программного обеспечения с открытым исходным кодом стоит на принципах бесплатности и доступности исходного кода. По этой причине некоторые сервисы для хостинга репозиториев предоставляют возможность конфиденциального доступа в качестве премиум-услуги. Если конфиденциальность играет важную роль для достижения ваших коммерческих целей, это следует учитывать при выборе сервиса для хостинга репозитория.

Bitbucket

GitHub

GitLab

Поддержка Mercurial

В Bitbucket Cloud предусмотрена поддержка Mercurial. Mercurial — это бесплатная распределенная система управления кодом, аналогичная Git. Выбирайте и используйте распределенную систему управления версиями, которая вам больше подходит.

Bitbucket

GitHub

GitLab

Сертификация Soc 2 Type II

Bitbucket — первое из распространенных решений для Git, которое гарантирует, что код не будет раскрыт посторонним лицам, что коду обеспечена полная сохранность и что облачная среда проверена независимыми аудиторами на соответствие стандарту SOC 2 Type II.

Bitbucket

GitHub

GitLab

Специальный поиск по коду

Анализируйте поисковые результаты быстрее благодаря семантическому поиску, который располагает определения в начале списка (выше повторных использований и имен переменных).

Bitbucket

GitHub

GitLab

Встроенные возможности CI/CD

Bitbucket Pipelines — это возможность Bitbucket, которая обеспечивает единое рабочее пространство для сборки, тестирования и развертывания кода с использованием встроенного конвейера непрерывной интеграции и непрерывной поставки (CI/CD). Используйте все преимущества неограниченного масштабирования и конфигурации как кода, не тратя силы на управление инфраструктурой сборки.

Bitbucket

GitHub

GitLab

команды

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

Bitbucket

GitHub

GitLab

Размещение на собственном оборудовании

С помощью Bitbucket Server ваша команда может надежно и безопасно размещать конфиденциальные проекты организации и связанный с ними код в VPN или другой защищенной внутренней сети.

Bitbucket Server

Только для корпоративных клиентов

Выбор репозитория кода, подходящего для организации

Сфера сервисов для хостинга репозиториев отличается высокой конкуренцией, и в ней можно найти множество предложений. Одного лучшего варианта не существует. Лучшим вариантом в каждой ситуации становится предложение, которое удовлетворяет основным требованиям текущего проекта.

Подходящий сервис для хостинга репозиториев идеально вписывается в культуру организации и оправдывает ожидания рабочего процесса. Если организация стремится следовать принципам agile, важно, чтобы и репозиторий был соответствующим. В репозитории кода нужно учитывать периодичность, с которой организация выпускает релизы: следует ли организация схеме непрерывной интеграции с высоким темпом релизов или статичному плану с менее частыми релизами. Репозиторий должен соответствовать этим рабочим процессам. Заранее подумайте об этих факторах, чтобы выбор средства для хостинга репозиториев стал простой задачей.

Репозиторий кода Bitbucket

Преимущества Bitbucket Cloud в качестве репозитория кода

Решение Bitbucket создано для профессиональных команд

Bitbucket Cloud предоставляет вашей команде все, что нужно для создания, отслеживания и развертывания ПО наилучшим образом, от оптимальной интеграции с Jira до улучшенной проверки кода.

Оптимальная интеграция с Jira

Выполните интеграцию с Jira или Trello, чтобы ваши клиенты были в курсе дел. Получайте доступ к веткам, статусу сборки, коммитам и прочим статусам прямо из задач Jira или карточек Trello.

Непрерывная доставка в облаке

Выполняйте сборку, тестирование и развертывание с помощью встроенного конвейера непрерывной интеграции и непрерывной поставки (CI/CD). Используйте все преимущества неограниченного масштабирования и конфигурации как кода, не тратя силы на управление инфраструктурой сборки. Работайте с кодом и развертываниями из одного места, чтобы иметь возможность отслеживать и предварительно просматривать развертывания.

Одна платформа, один инструмент

Bitbucket Connect позволяет любому разработчику реализовать глубокую интеграцию с Bitbucket Cloud непосредственно из интерфейса пользователя продукта. Больше не требуется переключать контекст между инструментами и задачами. Прямо в Bitbucket есть все, что требуется для компиляции и выпуска.

Повышенная безопасность

Применяйте в работе списки разрешенных IP-адресов и принудительную проверку слияний. Обязательное использование двухфакторной аутентификации (2FA) или универсального второго фактора (U2F) обеспечивает безопасность кода, требуя при входе второе подтверждение в дополнение к паролю. Продукт Bitbucket сертифицирован по стандарту SOC 2 Type II — это гарантирует безопасность кода и бесперебойный доступ к нему.

Выберите Bitbucket

Все, что нужно вашей команде для разработки отличного ПО, почти даром. Выберите Bitbucket Cloud прямо сегодня.

Начните работу бесплатно

Выбор репозитория исходного кода: руководство

Руководство по выбору репозитория кода для вашей команды

Выбор инструмента репозитория

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

Разница между услугами размещения репозитория и системой контроля версий

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

Узнайте, как выбрать лучшую систему контроля версий для своей команды.

Услуги хостинга репозиториев — это сторонние веб-приложения, которые обертывают и улучшают систему контроля версий. Вы не можете в полной мере использовать службу хостинга репозитория без использования базовой системы контроля версий.

Какой репозиторий исходного кода выбрать?

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

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

Элементы, которые следует учитывать при выборе репозитория

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

Поддерживаемые системы контроля версий

Совместима ли служба размещения репозитория с системой контроля версий, используемой в проекте? Это критический элемент, который следует учитывать. Если ваш проект использует Git, а служба репозитория не предлагает поддержку Git, будет очень сложно использовать эту службу хостинга репозитория.

Размер команды и контроль доступа

Учитывайте структуру команды проекта и динамику работы. Это работа одного человека или командный проект? Это удаленная команда? Находится ли вся команда в одном и том же месте? Какой уровень доступа требуется членам команды к службе хостинга репозитория?

График выпуска

Будут ли выпускаться частые небольшие обновления или более крупные периодические выпуски меньшего размера? Многие службы хостинга репозиториев предлагают дополнительные инструменты CI/CD. Кроме того, служба репозитория может предлагать инструменты отслеживания проблем и управления выпусками.

Размер проекта и хранение данных

Будет ли проект работать с большими файлами двоичных данных, такими как графика 3D-моделирования или аудиофайлы? Существуют специальные программы для репозиториев, которые специализируются на упрощении работы с большими файлами. Каков текущий объем коммитов, которые будут происходить в проекте? Это устоявшийся проект с долгой историей, загрузка которого может занять некоторое время?

Внешние инструменты и сторонние интеграции

Ключевой особенностью службы размещения репозитория является интеграция внешних инструментов и служб. Эти интеграции действительно позволяют опытным пользователям работать со службой репозитория. Некоторые примеры распространенных внешних интеграций: продажа билетов и управление задачами. Инструменты управления поддержкой клиентов. Автоматизированные инструменты обеспечения качества. Если ваша команда уже использует определенный инструмент, убедитесь, что репозиторий кода хорошо с ним интегрируется.

Comparison code repository solutions

The table below aggregates these considerations and compares across various repository hosting services:

Feature & requirements

Bitbucket

Github

Gitlab

Code review

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

Bitbucket

Github

Gitlab

Лучшая в своем классе интеграция с Jira Создавайте ветки Bitbucket из Jira Software или переносите проблемы, даже не выходя из Bitbucket.

Битбакет

Гитхаб

Гитлаб

Wiki

Хранение проектной документации в легкодоступном месте рядом с исходным кодом проекта может быть чрезвычайно полезным для эффективности команды. В дополнение к размещению исходного кода службы репозитория размещают сопроводительную документацию.

Bitbucket

Github

Gitlab

Бесплатные частные репозитории

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

Bitbucket

Github

Gitlab

Сертификация Soc 2 Type II , а наше Облако будет проходить сторонний аудит SOC 2 Type II.

Bitbucket

Github

Gitlab

Поиск с поддержкой кода

Bitbucket

Github

Gitlab

Встроенный CI/CD

Bitbucket Pipelines — это функция Bitbucket с интегрированной сборкой и развертыванием CD, позволяющая протестировать и развернуть одно средство. Воспользуйтесь конфигурацией в виде кода и неограниченным масштабированием без управления инфраструктурой сборки.

Bitbucket

Github

Gitlab

Команды

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

Bitbucket

Github

Gitlab

Self-Hosting

Bitbucket Server позволяет вашей команде безопасно и конфиденциально размещать конфиденциальный сетевой код или внутренний VPN-проект внутри вашей организации.

Bitbucket

Bitbucket Server

Github

Enterprise only

Gitlab

Bitbucket Server

Enterprise only

Features & requirements

Features & requirements

Bitbucket

Github

Gitlab

Bitbucket

Github

Gitlab

Проверка кода

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

Bitbucket

Github

Gitlab

Лучшая в своем классе интеграция с Jira

Выпускайте на 14 % чаще с Jira Software и Bitbucket, которые легко интегрируются от филиала к развертыванию. Создавайте ветки Bitbucket из Jira Software или переносите проблемы, даже не выходя из Bitbucket.

Bitbucket

Github

Gitlab

Wiki

Хранение проектной документации рядом с исходным кодом проекта может быть чрезвычайно полезным для эффективности команды. В дополнение к размещению исходного кода службы репозитория размещают сопроводительную документацию.

Bitbucket

Github

Gitlab

Бесплатные частные репозитории

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

Битбакет

Гитхаб

Gitlab

Поддержка Mercurial

Bitbucket Cloud поддерживает Mercurial. Mercurial — это бесплатная распределенная система управления исходным кодом, такая как Git. Имейте свободу выбора и используйте распределённую систему контроля версий, которая работает на вас.

Bitbucket

Github

Gitlab

Сертификация Soc 2 Type II , а наше Облако будет проходить сторонний аудит SOC 2 Type II.

Bitbucket

Github

Gitlab

Поиск с учетом кода

Bitbucket

Github

Gitlab

Встроенный CI/CD

Bitbucket Pipelines — это интегрированная функция Bitbucket для тестирования и развертывания с одним компакт-диском для сборки и развертывания. Воспользуйтесь конфигурацией в виде кода и неограниченным масштабированием без управления инфраструктурой сборки.

Bitbucket

Github

Gitlab

Teams

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

Bitbucket

Github

Gitlab

Self-Hosting

Bitbucket Server позволяет вашей команде безопасно и конфиденциально размещать конфиденциальный сетевой код или внутренний VPN-проект внутри вашей организации.

Bitbucket Server

Только для предприятий

Выбор репозитория кода, подходящего для вашей организации

Индустрия услуг хостинга репозиториев конкурентоспособна и предлагает множество предложений. Тем не менее, нет единого «лучшего» варианта. Поиск «лучшего» варианта означает поиск предложения, которое дополняет насущные требования проекта.

Дополнительная услуга размещения репозитория — это услуга, которая хорошо сочетается с организационной культурой и ожиданиями рабочего процесса. Если организация стремится следовать гибким практикам, важно, чтобы инструмент репозитория соответствовал этому. Инструмент репозитория кода должен соответствовать «ритму релизов» организации. Если в организации есть график непрерывной интеграции быстрых выпусков или, возможно, менее частый график статических выпусков. Инструмент репозитория должен учитывать эти рабочие процессы. Заранее определяя эти точки рассмотрения, выбор инструмента для размещения репозитория становится простым упражнением.

Репозиторий кода Bitbucket

Зачем выбирать Bitbucket Cloud в качестве репозитория кода

Bitbucket создан для профессиональных команд

От лучшей в своем классе интеграции с Jira до лучшей проверки кода — Bitbucket Cloud предоставляет вашей команде все необходимое для создания , отслеживать и развертывать свое программное обеспечение лучше.

Лучшая в своем классе интеграция с Jira

Интегрируйте с JIRA или Trello, чтобы держать заинтересованные стороны в курсе событий. Доступ к веткам, статус сборки, коммиты и статус задач JIRA или карточек Trello.

Непрерывная доставка в облаке

Сборка, тестирование и развертывание с интегрированной CI/CD. Воспользуйтесь конфигурацией в виде кода и неограниченным масштабированием без управления инфраструктурой сборки. Объединяйте код и развертывания в одном месте, чтобы отслеживать и предварительно просматривать развертывания.

Одна платформа, один инструмент

Bitbucket Connect позволяет любому разработчику создать глубокую интеграцию с Bitbucket Cloud прямо в пользовательском интерфейсе продукта. Больше не нужно переключаться между инструментами и задачами. Имейте все необходимое для создания и поставки прямо в Bitbucket.

Повышенная безопасность

Используйте список разрешенных IP-адресов, применяйте проверки слияния, применяйте двухфакторную аутентификацию (2FA) или используйте универсальную двухфакторную аутентификацию (U2F) для защиты кода с помощью второго подтверждения в дополнение к вашему паролю. Сертификаты Bitbucket SOC 2 Type II гарантируют безопасность вашего кода и постоянный доступ к нему.

Выберите Bitbucket

Все функции, необходимые вашей команде для создания отличного программного обеспечения, по минимальной цене. Выберите облако Bitbucket сегодня.

Начните бесплатно

Что такое репозиторий кода? Лучший хостинг репозиториев кода в 2021 году (обновлено для 2022 года)

Репозиторий кода — это архив кода, над которым ведется работа. Помимо самого кода, вы можете хранить в своем репозитории такие вещи, как документация, заметки, веб-страницы и другие элементы. Репозиторий кода необходим для любого успешного проекта разработки программного обеспечения.

Обновлено 13 сентября 2022 г.: GitHub теперь предлагает неограниченное количество частных репозиториев на уровне бесплатного пользования и добавил GitHub Actions, который представляет собой набор инструментов CI/CD и средств автоматизации рабочих процессов. Мы обновили наш обзор, чтобы отразить это.

Если мы используем дом в качестве аналогии, мы можем разбить вещи дальше. Сам дом будет аналогичен вашему программному продукту в целом, а архитектура и материалы дома будут аналогичны коду. Куда идет твой дом? На твоей земле. В нашей аналогии ваше хранилище похоже на землю, на которой стоит ваш дом.

Репозиторий (или сокращенно репо) может быть общедоступным или частным. Когда дело доходит до совместной работы, о сообществе разработчиков можно сказать кое-что особенное. Вы видите уровни сотрудничества между кодерами, выходящие за рамки многих других отраслей. Очень часто вы найдете публичные репозитории, где люди выкладывают свой код для использования кем угодно. Иногда люди публикуют свои репозитории, потому что внедрение вашего кода в их продукт является достижением других. В других случаях открытые репозитории помогают стимулировать инновации, поскольку инновации могут происходить быстрее, когда над одним проектом работает много людей.

Зачем нужна служба хостинга репозитория кода

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

Вот тут вы можете сказать: «Но я клиент, а не разработчик, мне не нужно сотрудничать с разработчиками!» Вспомните аналогию с домом. Если вы, клиент, не заботитесь о доступе к репозиторию, это все равно, что сказать, что строительная компания может построить ВАШ дом на своем заднем дворе. Как вы собираетесь перевести дом с их земли на свою? Это сложно, и если строительная компания никогда не сообщит вам свой адрес, они могут просто привидеться, и вы никогда не увидите дом.

Но если вы построите дом в облаке (хорошо… аналогия начинает ломаться), вы сможете получить к нему доступ откуда угодно, а передать право собственности так же просто, как нажать кнопку. Поэтому вам нужно выбрать лучшего облачного провайдера для размещения вашего репозитория кода. Чтобы расширить аналогию с домом, подумайте об этом как о строительстве своего дома на футуристическом парящем участке земли, который можно транспортировать куда угодно одним нажатием кнопки. Он не на вашем заднем дворе и не на заднем дворе вашей строительной компании — он в облаке.

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

GitHub

GitHub — один из самых популярных репозиториев кода. Aloa использует GitHub для многих наших клиентских проектов. Это отличный репозиторий для документации и обычно используется для совместной работы. Если вы работаете в команде с другими разработчиками, GitHub — отличная отправная точка.

GitHub предлагает список популярных функций:

• История совершения. и CI/CD через GitHub Actions

Причина, по которой Aloa использует GitHub для своих клиентских проектов, заключается в их бесплатном групповом плане с неограниченным количеством частных репозиториев и неограниченным количеством соавторов. Частные репозитории важны для работы с клиентами, потому что часто клиенты не хотят, чтобы их код проекта был доступен для общественности. Раньше вы могли пригласить только 3 соавторов в частные репозитории, что делало его плохим выбором для аутсорсинга. Теперь, в 2022 году, каждый может начать работу со своим собственным частным репозиторием, не платя ни копейки и не беспокоясь об ограничениях совместной работы.

GitHub также недавно добавил GitHub Actions, комплексный набор инструментов для автоматизации рабочих процессов и CI/CD. Предыдущие критики GitHub сетовали на отсутствие встроенных инструментов CI/CD, но теперь GitHub решил эту проблему.

GitLab

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

GitLab имеет немного более удобный интерфейс, чем GitHub. GitLab предлагает надежные конвейеры CI/CD и автоматизацию рабочих процессов, что ранее было их самым большим конкурентным преимуществом перед GitHub. Мы рекомендуем GitLab для высокотехнических команд, которые не планируют активно сотрудничать за пределами своей организации, но в целом GitHub выигрывает благодаря справедливой цене и аналогичному набору функций..

Bitbucket

Как и GitLab и GitHub, Bitbucket также предлагает бесплатный уровень для частных репозиториев. Aloa также использует Bitbucket для нескольких наших клиентов. Еще одним преимуществом Bitbucket является наличие REST API для создания сторонних приложений. Вы также можете искать код динамичным и эффективным способом.

• Как и GitHub, Bitbucket предлагает множество схожих функций:
• История коммитов
• Pull Requests
• Отслеживание проблем

В последние годы GitHub и GitLab внесли улучшения в свой пользовательский интерфейс, которые, к сожалению, отодвинули Bitbucket на задний план. В прошлом Bitbucket подвергался резкой критике за медленный пользовательский интерфейс и ориентацию функций на менеджеров, а не на разработчиков. Однако, если ваша команда уже использует Jira или другие продукты Atlassian, Bitbucket может быть лучшим вариантом.

Резюме — GitHub, GitLab и Bitbucket

Мы надеемся, что это краткое сравнение было полезно как для понимания репозиториев кода, так и для выбора лучшего сервиса хостинга репо для вас. В других местах в Интернете есть более подробные сравнения функций, но мы хотели поделиться своей точкой зрения, сравнивая GitHub, GitLab и Bitbucket для работы с внешними или офшорными командами.

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

This entry was posted in Популярное