Какой ритуал выполнить что-бы в gitflic сделать репозиторий публичным?
Решил вот попробовать. А чего бы и нет то. В настройках смотрел, галочка «сделать публичным» в «опасной зоне» неактивна. Чево им нада?
Создал репозиторий, первый ком блином RSA не поддерживается и мой публичный ключ сохранился, а ничего не клонируется, со второго раза заметил БОЛЬШИЕ КРАСНЫЕ БУКВЫ RSA ключи не могём. Ну ладно сгенерировал ещё один ssh ключик уже специально для джитфлика ssh-keygen -t ED25519 склонировал, запушил инит.
Гляжу приватный, ну ок иду в настройки, а там всё… Не даёт галку поставить что публичный хочу, всё серенькое.
Ладно думаю хз, а потом гляжу на странице профиля написано README профиля не найден. Поделитесь информацией о себе, создав README для вашего профиля
Тыкаю, делая по инструкции и там явно написано что есть условия
Вы создали репозиторий с именем, совпадающим с вашим именем пользователя Gitflic. Репозиторий публичный. Репозиторий содержит файл с именем README.md в корне. Файл README.md содержит любой контент Ага, саска бибку. Повторюсь, может там ритуал какой надо натыкать. Ну странно.
Перемещено hobbit из general
LINUX-ORG-RU ★★★★★
15.06.22 01:43:19 MSK
А… Понятно. Никакой новые публичные репы временно запрещены. Ну ладн.
LINUX-ORG-RU ★★★★★
( 15.06.22 01:53:09 MSK ) автор топика
Ответ на: комментарий от LINUX-ORG-RU 15.06.22 01:53:09 MSK
А когда они только запустились, наоборот были только публичные репы. А сейчас, хочешь публичную репу, неси челобитную в поддержку.
RussianWarShip
( 15.06.22 06:35:14 MSK )
Кстати, git.org.ru снова доступен. Когда я его тыкал, там всё было проще, чем на гитфлике.
Я ни к чему не призываю, просто инфа к размышлению.
hobbit ★★★★★
( 15.06.22 10:46:00 MSK )
Ответ на: комментарий от LINUX-ORG-RU 15.06.22 01:53:09 MSK
хм, у меня кнопки активны, пойду попробую жамкнуть
а дальше плашка с отсылом к администрации 🙂 но уже прогресс, кнопка жамкается
Morin ★★★★
( 15.06.22 10:47:23 MSK )
Последнее исправление: Morin 15.06.22 10:49:21 MSK (всего исправлений: 1)
Учитывая скудость комьюнити этих новомодных git.org.ru и gitflic даже по сравнению с gitlab.com(с гитхабом даже сравнивать не буду — и так всё ясно), в упор не вижу чем они лучше собственно-поднятой gitea или gitlab. Импортозамещение ради импортозамещения?
Pinkbyte ★★★★★
( 15.06.22 12:09:41 MSK )
Ответ на: комментарий от Pinkbyte 15.06.22 12:09:41 MSK
У Гитхаба коммьюнити тоже не сразу появилось. Чем больше будет людей давать обратную связь, тем будет лучше и сам сервис.
LongLiveUbuntu ★★★★★
( 15.06.22 12:16:16 MSK )
Ответ на: комментарий от Pinkbyte 15.06.22 12:09:41 MSK
чем они лучше собственно-поднятой gitea или gitlab
Тем, что собственно поднятую надо админить?
hobbit ★★★★★
( 15.06.22 13:24:49 MSK )
Ответ на: комментарий от hobbit 15.06.22 13:24:49 MSK
В мире победившего docker-а сделать docker pull и перезапустить контейнер при выходе новой версии — это конечно капец достижение.
Единственный верный аргумент зачем стоит пользоваться ЭТИМ сейчас вместо github — только боязнь того что github/gitlab/любой_другой_зарубежный_сервис прикроет лавочку для России.
Тут понимаю, тут вопросов нет.
Pinkbyte ★★★★★
( 15.06.22 13:36:34 MSK )
Ответ на: комментарий от Morin 15.06.22 10:47:23 MSK
У тебя да. Для новых реп нет. Иди для новых реп в новых аккаунтах, не знаю точно.
LINUX-ORG-RU ★★★★★
( 15.06.22 13:42:39 MSK ) автор топика
Ответ на: комментарий от Pinkbyte 15.06.22 13:36:34 MSK
На мой взгляд такими сервисами вообще не следует пользоваться, для своего рабочего процесса надо хостить систему контроля версий самостоятельно. Но, если хочется сделать себе зеркало (именно зеркало для скачивания и просмотра кода, а не рабочий инструмент) на каком-нить общественном хостинге, почему бы и эти не попробовать. Единственно имеется опасение, что долго они не проживут.
firkax ★★★★★
( 15.06.22 14:03:30 MSK )
Последнее исправление: firkax 15.06.22 14:04:20 MSK (всего исправлений: 1)
Ответ на: комментарий от firkax 15.06.22 14:03:30 MSK
На мой взгляд такими сервисами вообще не следует пользоваться, для своего рабочего процесса надо хостить систему контроля версий самостоятельно.
Я вот примерно по таким соображениям почти 20 лет назад стал самостоятельно хостить почту. Но кроме красоты, престижа и надёжности (последнее с большими оговорками, если сравнивать с яндексом), это ещё и куча геморроя. Подцепишь зловреда — будешь долго вычищать себя из блеклистов. Сертификаты, спам, ограничения на аттачи… Сейчас я этими ящиками пользуюсь, скорее, из соображений «бросить жалко». Это только с почтой, VCS, КМК, сложнее.
А, ну и если я вдруг помру, на популярном сервисе мой проект будет висеть ещё долго, есть шанс что кто-то подхватит. А на личном канет в небытие, как только кончится оплата. Да, если ты юн, об этом можно не задумываться, но я вот думаю, что могу инсульт схватить запросто в любой момент.
hobbit ★★★★★
( 17.06.22 11:31:33 MSK )
Ответ на: комментарий от hobbit 17.06.22 11:31:33 MSK
Подцепишь зловреда — будешь долго вычищать себя из блеклистов.
По-моему это меньшая из проблем. Большая — это думать, только ли переустанавливать систему (на одном устройтве или на всех?) или опасаться что зловред залез и в прошивку на железе куда-нить.
Это только с почтой, VCS, КМК, сложнее.
Наоборот. Для VCS не нужно ничего изображать для антиспамных систем с их изменчивыми пожеланиями, надо только установить сервис и найти где-нить статический белый айпи и доменное имя. Vcs-клиенты никакими чёрными списками не страдают, браузерам (для веб-украшательств) нужен только сертификат, он делается легко.
на популярном сервисе мой проект будет висеть ещё долго
Не обязательно сразу такие фатальные сценарии придумывать, тебе может просто надоесть этим заниматься с тем же итогом для личного хоста. Зеркал можно хоть 10 сделать на разных сайтах. Но оригинал, который привязан к рабочему процессу, должен быть у себя.
GitFlic. Российский GitHub. Рассмотрение сервиса и его нюансы
Начнем с простого, что мне пришло письмо на почту такого вот содержания:
Сразу обратим внимание, что пригласили на тесты, но также обговорили момент о платном контенте. Ну ладно, всем надо как-то зарабатывать. Теперь перейдем на их сайт и посмотрим.
По сути, основное, что надо для работы в команде отсутствует, но прикольно, что они сразу подключат интеграцию с телегой. Особо крутой фичей считать не будем, так как есть тьма готовых решений для подобных систем.
Многие скажут, что это же тест версия, поэтому тут нет много функционала. Да, соглашусь, но работа с ветками так очевидна и проста, что для этого не требуется супер технологий и знаний, а вот работа с трекерами и обсуждением кода — принципиальна.
Пойдем читать пользовательское соглашение. Сразу встречаем пункт о платных фичах:
Пользователь обязан самостоятельно отслеживать в Личном кабинете информацию о состоянии Подписки (оплаченный Период подписки, стоимость Подписки, перечень доступных привилегий), а также отслеживать внесение изменений и дополнений в Личном кабинете.
Но, на сайте ни слова не указано о том, что это за фичи. Очень интересный подход. Скорее всего, просто посмотрят чем чаще пользуются и сделают платным 😀
Интересный момент по возрастным ограничениям. Вообще не понятен. То есть, хостить код можно только 18+. Серьезно? А в чем смысл ограничений таких? Уменьшить аудиторию или еще чего?
Пользователь может использовать сервис если достиг 18 лет
Ну, раз сервис позиционируется российским (отечественным), то не хватает только кнопки «Войти через ГОСУСЛУГИ» 😀
По просмотру соглашения все. Особо много тут не написано, что тоже странно, но хоть как-то более-менее ясно о чем речь. Теперь, давайте создадим аккаунт и попробуем что-нибудь.
Создание аккаунта
Форма регистрации уж сильно похоже на GitHub до их переделки. Кстати, верстка вся на Bootstrap: Bootstrap v4.6.0, когда уже во всю вышел нормальная 5 версия без jQuery.
Блин, очень было забавно с иконки медведя. Просто, российский хостинг кода. Россия. Медведи. Но заметьте, что Username на английском в форме. А смысл, если все остальное на русском?
Ммм, ошибки на экран.
Обсуждаем интерфейс
Вот тут внимание. Я чуть со стула не упал. Знаете же в GitHub можно отметить проект звездой и следить за ним. Ну так вот, без комментариев:
Зазвездить. Вы серьезно? Что вы там употребляете, что у вас такие вот выражения.
Интерфейс достаточно простой и понятный, но он настолько несовременный и некрасивый, что сервисом просто не хочется пользоваться (субъективное мнение).
Ради интереса, зайдем на любой из проектов.
Выглядит все просто, хотя просматривается тема «интерфейс за 5 минут». Но тут я кое что заметил. Заметили? Наверху тЭги, а справа тЕг.
Если немного покопаться в коде, то можно увидеть такие вот комментарии, которые наталкивают на мысль, что сервис пишет команда не очень опытных разработчиков. А также, есть предположение, что часть кода явно скачана. Либо реально скачали и не убрали комментарии, либо у них разные люди все писали. Тогда, где соглашение по коду.
Ладно, думаю надо завершать на этом. А то сил моих смотреть это больше нет.
Заключение
Хоть это и тесты, но они уже публичные. Ребята в компании особо не парятся на проверке за своими программистами логических ошибок. Интерфейсные решения соответствуют очень давнему 2008-2010 годам. Версионность инструментов оставляет желать лучшего. Проект очень сырой, хотя, я думаю, что в дальнейшем он не будет пользоваться большим спросом из-за того, что они не предоставляют уникальных фич по сравнению с конкурентами. Хотя с другой стороны, если будут жесткие санкции, а именно облачный хостинг кода будет необходим, то вполне возможно.
Приветствуем в GITFLIC
Итак, вы решили начать использовать git ,но не знаете с чего начать? Данную документацию можно использовать в качестве настолько пособия и обращаться по возникающим вопросам. Для начала вам следует создать свой проект . Когда вы создали свой новый репозиторий, необходимо подготовить локальное рабочее пространство. Используйте консоль на вашем ПК для работы.
Для большего удобства, пользователям Windows, рекомендуем установить отдельную консоль для работы с git. В поисковике запросом “Git для Windows” выбрать предпочитаемый и установить его.
Когда откроете консоль, выполните следующие команды для создания локальной директории для вашего будущего репозитория:
Создание локальной директории
cd ~/ mkdir repos cd ~/repos После выполнения предыдущих команд следует указать свои данные, выполнив следующие команды:
Глобальные настройки Git
git config --global user.name "gitflic-user" git config --global user.email "mail@gitflic.ru" Далее необходимо выбрать один из вариантов, который подходит вашей ситуации и выполнить команды по порядку
Создание нового репозитория
git clone http://gitflic.ru/project/user/proekt.git //Здесь ссылка на ваш проект cd proekt touch README.md git add README.md git commit -m "add README" git push -u origin master Использовать существующую директорию
cd existing_folder git init git remote add origin http://gitflic.ru/project/user/proekt.git //Здесь ссылка на ваш проект git add . git commit -m "Initial commit" git push -u origin master Запушить существующий репозиторий
cd existing_folder git remote rename origin old-origin git remote add origin http://gitflic.ru/project/user/proekt.git //Здесь ссылка на ваш проект git push -u origin --all git push -u origin --tags После выполения команд мы видим как локальная/удаленная дериктория наполнились файлами. Теперь, как мы разобрались с настройкой репозитория, самое время разобраться как пользоваться ветками в системе git
Для создания ветки и мгновенного переключения на новую ветку используется следующая команда, где omega, параметр -b указывает на ветку:
Как создать ветку в git
git checkout -b omega Также можно выполнить то же самое действие в 2 команды, отдельно создать ветку, отдельно в нее переключиться:
git branch omega git checkout omega Распространенные опции для git branch
Вывод списка всех веток в репозитории.
git branch или git branch --list Удаление ветки с названием omega. Это «безопасная» операция, так как git не позволит удалить ветку, в которой есть неслитые изменения. Данная команда удаляет только локальную ветку.
git branch -d omega Принудительное удаление указанной ветки, даже несмотря на то, что в ней есть неслитые изменения. Эту команда следует использовать, если вы хотите полностью удалить все коммиты, которые относятся к определенному направлению разработки.
git branch -D git push origin :refs/heads/
Вывод списка всех веток удаленного проекта.
git branch -a Для визуализации файлов под управлением git существует расширение TortoiseGit. Оно имеет логичный интерфейс и отображает иконки к файлам, находящимся под управлением gitдля отображения их статуса в git.
Генерация публичного SSH ключа
Для работы с git многие серверы используют аутентификацию по ssh-ключу. Далее расскажем как создать свой ssh-ключ для работы с git. Процесс создания ssh-ключа аналогичен на всех ОС. Первым делом убедимся, что у вас отсутствует ssh-ключ на локальном компьютере, для этого выполните следующие команды:
cd ~/.ssh ls Ищите файл с именем id_dsa или id_rsa и одноименный файл с расширением .pub. Файл с расширением .pub — это ваш публичный ключ, а второй файл — ваш приватный ключ. Если указанные файлы у вас отсутствуют (или отсутствует директория .ssh), вы можете создать их используя команду:
cd ~/ ssh-keygen -o Generating public/private rsa key pair. Enter file in which to save the key (/home/gitflic_user/.ssh/id_rsa): Created directory '/home/gitflic_user/.ssh'. Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /home/gitflic_user/.ssh/id_rsa. Your public key has been saved in /home/gitflic_user/.ssh/id_rsa.pub. The key fingerprint is: d0:82:24:8e:d7:f1:bb:xx:yy:zz:96:93:49:da:9b:e3 gitflic_user@gitflic.ru После создания вашего публичного ssh-ключа его необходимо прописать в настройках к git. Первым делом необходимо получить ssh-ключ из файла. Вы можете открыть ваш публичный ssh-ключ в текстовом редакторе и полностью скопировать содержимое, либо выполнить следующую команду в консоли:
cat ~/.ssh/id_rsa.pub Когда скопируете ssh-ключ, пропишите его в настройках, укажите название для ключа, например my-ssh, оставьте поле со сроком годности пустым, тогда ваш ssh-ключ будет всегда активен. Нажмите сохранить и убедитесь что сохранение прошло успешно.
Чтобы убедиться, что ключ сохранен верно, вы можете при помощи следующей команды получить хэш ключа и сравнить его с тем, что отображается в настройках профиля.
ssh-keygen -t ed25519 -C "your_email@example.com" Возможные проблемы с работой по ssh.
В некоторых ситуациях возникать ошибка no mutual signature algoryth при использвании id_rsa.pub. Чтобы решить эту проблему, необходимо сгенерировать новый ssh-ключ по алгритму ED25519.
Распространенные команды при работе с git
git clone
Как правило при помощи команды git clone создается копия репозитория от указанного. Это делается в новой директории или в другом месте. Исходный репозиторий может находиться в локальной файловой системе или на удаленном устройстве, к которому можно получить доступ с помощью поддерживаемых протоколов.
Пример клонирования проекта в дерикторию folder по ssh-ключу:
git clone git@f.dev.gitflic.ru:user/how-to.git ./folder/ Аргумент -branch позволяет выбрать ветку для клонирования. В противном случае клонируется ветка, на которую указывает HEAD в удаленном репозитории (обычно главная ветка). Кроме того, для этих целей в команде можно задать тег вместо ветки:
git clone -branch new_feature git://remoterepository.git git clone –bare Как и git init –bare, аргумент -bare при назначении команде git clone приводит к созданию копии удаленного репозитория без рабочего каталога. Это означает, что репозиторий будет содержать историю проекта, к которой можно выполнять запросы push и pull, но которую нельзя редактировать напрямую. Кроме того, в репозитории, клонированном с опцией -bare, не будут настроены удаленные ветки. Как и git init –bare, эта команда создает удаленный репозиторий, который разработчики не смогут редактировать напрямую.
git clone –mirror Вместе с аргументом –mirror команде неявно назначается и аргумент –bare. Поэтому можно сказать, что опция –mirror наследует поведение –bare, создавая чистый репозиторий без изменяемых рабочих файлов. Кроме того, –mirror клонирует ссылки удаленного репозитория и сохраняет конфигурацию отслеживания удаленных веток. Затем вы можете выполнить команду git remote update на созданном зеркале, в результате чего будут перезаписаны все ссылки из исходного репозитория. Так вы получите идентичные функциональные возможности для работы.
git add
Команда git add добавляет изменения рабочей директории в промежуточную область. Он сообщает git, что вы хотите включить обновления определенного файла в следующий коммит. Однако git add на самом деле не влияет на репозиторий каким—либо существенным образом — изменения фактически не записываются до тех пор, пока вы не выполните git commit.
Добавление всех изменений в следующий коммит выполняется следующей командой:
git add . Чтобы добавить в следующий коммит только один измененный файл, то это делается командой, где — полное имя файла:
git add
В сочетании с этими командами вам также понадобится git status для просмотра состояния рабочего каталога и промежуточной области:
git status git commit
Коммит проиндексированного состояния кода производится по следующей команде:
git commit Стоит отметить, что эта команда откроет текстовый редактор, введите комментарий к коммиту. После ввода сохраните файл и закройте текстовый редактор, чтобы выполнить коммит. Выполнение коммита со всеми изменениями в рабочей директории. Эта команда включает только изменения отслеживаемых файлов (которые были добавлены командой git add):
git commit -a Данная команда создаст коммит с указанным комментарием. По умолчанию команда git commit открывает локальный текстовый редактор для ввода комментария к коммиту. При передаче параметра -m используется добавленный комментарий, минуя текстовый редактор:
git commit -m "commit message" Также есть параметр, который позволяет команде commit изменять последний коммит. Вместо создания нового, все изменения добавляются в последний. Кроме того, после выполнения команды откроется текстовый редактор и предложит изменить ранее указанный комментарий к комиту:
git commit --amend git pull
Команда git pull запускает команду git fetch для загрузки содержимого из указанного удаленного репозитория. Затем выполняется команда git merge, осуществляющая слияние ссылок и указателей удаленного содержимого в новый локальный коммит:
git pull
Выше указанная команда берет указанную удаленную копию текущей ветви и объединяет ее с локальной копией. Это то же самое, что и git fetch ＜remote＞, за которым следует git merge origin/＜current-branch＞.
Существует команда, подобная команде по умолчанию, только она не создает новый коммит со слитым содержимым:
git pull --no-commit
git push
Публикация указанной ветки в удаленном репозитории вместе со всеми необходимыми коммитами и внутренними объектами. Эта команда создает локальную ветку в репозитории назначения. Чтобы предотвратить перезапись коммитов, git не позволит опубликовать данные, если в репозитории назначения нельзя выполнить ускоренное слияние:
git push
Если для параметра указать значение origin и оставить пустым параметр branch, то изменения будут отправленны в ветку, которая выбрана в данный момент.
Параметр -u аналогично –set-upstream указывает удаленную ветку “по умолчанию”, все последующие команды git pull/push будут автоматически общаться между текущей локальной и выбранной удаленной ветками. Данная команда указывается единожды, до тех пор, пока не понадобится указать другую удаленную ветку “по умолчанию”.
git push -u origin master Существует процедура для очистки локальной и удаленной веток, которую целесообразно выполнять для поддержания порядка и не допущения накопления изменений, которые не будут загружены в основную ветку проекта:
git branch -D alpha git push origin :alpha Первая команда очистит локальную ветку alpha. Если в команде git push перед именем ветки поставить двоеточие, будет стерта удаленная ветка.
git merge
Для слияние веток используется команда git merge. Обычно, в веб интерфейсе есть механизм для создания и управления мерж-реквестами, однако, это можно сделать и через консоль.
git revert
Эта команда отменяет внесенные в коммит изменения и добавляет новый коммит с обращенным содержимым. В результате история в git не теряется, что важно для обеспечения целостной истории версий и надежной совместной работы. К примеру вы хотите вернуть ваш рабочий процесс к коммиту 1f08a70, команда возврата будет выглядеть следующим образом:
git revert 1f08a70 git reset
Универсальная команда для отмены изменений. Другими словами, если вопрос какой командой создается новый коммит, применяющий изменения, обратные для указанного аргументом коммита? Следует внимательно ознакомиться с этой командой. У команды git reset имеется несколько опций, разберем следующие:
Параметр –soft сбрасывает указатель HEAD до указанного коммита:
git reset --soft 1f08a70 Параметр –mixed сброс указателя HEAD до выбранного коммита в истории и отмена изменений в индексе:
git reset --mixed 1f08a70 Параметр –hard сбрасывает указатель HEAD до выбранного коммита в истории, отмяет изменения в индексе и отменяет изменения в рабочем каталоге. Не используйте данный параметр, если не уверены в своих действиях:
git reset --hard 1f08a70 git log
Эта команда позволяет просмотреть и фильтровать историю проекта, а даже искать конкретные изменения. Для сравнения с git status можно просматривать рабочую директорию и раздел проиндексированных в ней файлов, в то время как git log показывает только историю коммитов проекта. Этот же журнал коммитов можно найти на странице проекта в gitflic.ru. Каждая запись будет состоять из 4-х частей: хеш коммита, автор коммита, дата и комментарий к коммиту. Пример ответа:
commit 9936edb7ba9af7bf2443xxx11129e66834b9c2fa (HEAD -> master, origin/master) Author: gitflic_user Date: Thu Jun 3 11:01:00 2020 +0300 git init
Данная команда часто выполняется в автоматическом режиме, при клонировании проекта, однако, ей необходимо воспользоваться, когда вы заливаете ваш локальный репозиторий в сервис хранения кода. В момент выполнения команды создается папка .git со служебными файлами и назначается ветка master для вашего проекта.
git init Initialized empty Git repository in /Users/user/path/project/.git/ GitFlic: Российский аналог GitHub вышел из беты. Посмотрим, что там
Всем привет, дорогие друзья. Это новый формат для меня, формат обзора. Поэтому не судите строго, написать этот обзор оказалось не так то просто, как я это видел в начале. Сразу скажу, он не оплачен создателями GitFlic, мне просто интересно написать об этом. Итак, в России создали аналог американского GitHub. Проект называется GitFlic, он уже вышел из беты, а это значит, что обычным пользователям можно уже регистрироваться. Но прежде чем это сделать, нам нужно понять, что это за проект, сколько людей там работает и как долго, чтобы у нас не было неоправданных ожиданий. Собственно какие у меня и были вначале.
Немного истории
На фоне изменений политики GitHub и возможных санкций стал вопрос о том, что нужно хранилище для проектов на территории России. И писали, что правительство России хочет выделить 2,1 миллиарда рублей на создание аналога. И могло бы показаться, что это проект оплачен именно правительством, но немного полистав интернет, я нашел интервью, в котором много ответов на интересующие нас вопросы. Из него можно вынести следующее:
-
Этот проект не государственный, а частный. И никак не связан с упомянутыми 2,1 миллиарда рублей. Это даже хорошо, продукт будет конкурировать и стараться предложить что-то новое и востребованное, он не будет местом для “распила” бюджета и создатели будут стараться предложить что-то свое.
- Java 11;
- PostgresQL 11.x;
- RabbitMQ;
- Redis;
- Spring framework 5;
- Spring boot 2;
- Spring data;
- Spring core;
- Spring messaging;
- Spring mvc;
- Spring security;
- Spring HATEOAS;
- Spring integration.
Итак, я думаю предисловия было достаточно, теперь у нас есть некое представление, что мы сейчас увидим, поэтому надо пойти и таки зарегистрироваться!
Первые шаги
Для начала пойдем на их лендинг, там мы увидим: Здесь мы видим, что уже можем зарегистрироваться, это мы сделаем чуть позже. Первый российский сервис для хранения кода и работы с ним… Судя по всему да, первый. Я до этого о других не слышал. И здесь у меня возникает вопрос: а почему еще раньше не сделали это? Он уже должен был давно появиться. Далее нам перечисляют фичи проекта:
-
Можно работать в команде. Без этого вообще непонятно, кому такой проект нужен был бы.
-
Обсуждение кода. Возможность комментировать участки кода. Интересно, посмотрим как они это реализуют.
По набору функционала можно сказать, что проект еще только на старте своего развития. Есть еще очень много фич, которые хотелось бы. Будем ждать. Далее, еще раз повторим, что код хранится на территории России и на российских серверах. Думаю будут те, кому это важно. И собственно миссия компании: “Мы уверены, что GitFlic станет не только платформой для хранения кода и работы с ним, а полноценным сообществом разработчиков и просто людей, которые любят заниматься программированием, как в качестве хобби, так и основного заработка”. Идея вполне себе интересная. И на этом заканчивается лендинг.
Ценовая политика
Пока оплата нехитрая. 250 рублей за человека в команде больше 5 человек. Это, грубо говоря, 3,5 доллара. Цена небольшая, но пока что им особо и предложить нечего. Только в будущем, поэтому сравнивать цену с другими местами для хранения репозиториев нет смысла. В будущем обещают и CI/CD, и статический анализ кода, и трекер задач. А еще и запуск приложений в облаке. Последнее кажется очень даже интересным, но пока что это только слова, посмотрим что будет.
Регистрация
Пришло время зарегистрироваться и посмотреть, что там внутри…) 
Регистрация, как обычно, везде, дизайн оставляет желать лучшего, но как говорил технический директор: “До дизайна тоже дойдут руки и он будет лучше”. Хорошо, поверим)) Создал тестовый проект, чтобы посмотреть, что и как выглядит. Все напоминает GitHub: и кнопки на тех же местах, и функционал весь похожий, доступны подписки на других разработчиков и возможность оценить проект (здесь это названо разделом “Избранное” ). Вот ссылка на мой аккаунт, будет желание, подписывайтесь. Не знаю, буду ли использовать этот проект, посмотрим. Тот факт, что он по функционалу похож на GitHub, – это даже хорошо. Тем, кто пользовался GitHub, будет легче перейти на GitFlic. К тому же изобретать второй раз велосипед нет смысла. Из того, что отличает от GitHub: при создании проекта изначально выбирается язык программирования, на котором будет проект. 
Спорное решение, как по мне. На GitHub это определяется количеством кода. Может, это временное решение, которое сделано, пока нет функционала по определению в репозиториях. В только что созданном проекте прилагается шпаргалка для работы с гитом. Полезно, спасибо. Из интересного: если попробовать удалить репозиторий, то кнопка не нажимается. Быть может это исправят, когда будете читать статью, но сейчас, когда я пишу, она не работает. 
А так функционал повторяет то, что сделано в GitHub. Но на этом этапе развития проекта я не вижу ничего плохого в этом. Такой подход успешно работает и показал, что имеет место быть.
Переносить свои проекты или нет?
Хороший вопрос, потому что если уже использовать GitFlic, то нужно понять, зачем. Я думаю, что тем, кто боится отключения GitHub, стоит создать копии своих проектов здесь. Кого это не касается, переносить не вижу смысла.
Выводы
Я думаю, что это отличная инициатива. Необходимость проекта есть и появились люди, которые решились на его создание. Что важно – это не государственный проект, а это значит, что будет конкурентная борьба с предоставлением фич, из-за которых будут приходить люди. Целевая аудитория также есть, а это значит, что проект будет жить. Да, проект еще сырой. И пользоваться им полноценно и только им пока что не получится (как минимум без CI/CD в наше время разработка не может проходить). Я думаю, что можно присматриваться к GitFlic, создавать какие-то проекты, чтобы лучше узнать как пользоваться и ждать обновлений. Друзья, как всегда, приглашаю подписаться на мой телеграм-канал. Там я пишу о разработке, о новых моих статьях, в чате канала часто обсуждаем интересные темы, канал авторский, поэтому там всегда хорошо и уютно) В этой статье я попытался показать вам новый проект — место для хранения кода. Жду вашего фидбека, мне очень интересно, что думаете об этом. Всем добра!