Вы сталкивались с проблемой, что рабочий проект клонируется 10 минут?
А когда начинаешь разбираться: почему так? То оказывается, что внутри десятки непережатых картинок для фронта, которые еще и менялись регулярно (а значит, оставили след в истории git навсегда).
Данная проблема влияет не только на локальное использование, ведь мы на самом деле довольно редко делаем git clone с нуля, но и самое главное – на скорость всех наших сборок (если мы не используем `fetch-depth: 1` или аналог, а использовать их надо).
Для лиги лени: продукт есть, но есть куда расти. Некоторые вещи вызывают недоумение. Медведь годный.
Годный медведь
Учебник по интиму часть 1. Введение Часть 2. Стоит только нам взять телескоп и посмотреть вооружённым глазом Часть 3. Давайте пробовать поставить Часть 4. Немного душноты Часть 5. Gitflic api Заключение
Учебник по интиму часть 1. Введение
Пришли ко мне в личку, в запрещенной в РФ сети, бывшие коллеги с вопросом, а знаю ли я, а могу ли я посмотреть, и им показать, что такое гитфлик (GitFlic). Я про такое первый раз слышу, потому что за импортозамещением в ИТ в РФ не слежу. Нет смысла следить за переименованиями, типа Debian 10-11-12 – Astra, Samba – ALD, Панголин – PostgreSQL, и так далее.
Тут вот, свой продукт.
Погуглил. На сайте новостей Минцифры – две рекламные статьи, обе от 2021 года: Первая - GitFlic. Российский GitHub и вторая, ответ на нее, «GitFlic: нас обвинили в «распиле». На этом все. Остальное – 3 рекламные статьи, и два треда на лоре «как это работает вообще без техподдержки». И, внезапно, статья от 1с – Инфостарт, Автоматизация процесса разработки с помощью сервиса GitFlic. Пока дописывал статью, нашлась еще одна минцифровая статья «Cборка Java-проектов в GitFlic Kubernetes-агентом»
GitFlic не является форком какого-либо решения. Он написан с нуля и создан без иностранного участия, поэтому не зависит от внешних факторов и сторонних разработок.
В отличие от GitLab и GitHub, которые разработаны на Ruby и Ruby on Rails, GitFlic написан на Java. Это обеспечивает стабильность и производительность даже для крупных проектов.
Это Java то про производительность? Ну ладно
В 2023 году продукт был куплен Астрой
ГК «Астра» продолжает реализацию стартовавшей в 2020 году M&A-стратегии и объявляет о вхождении в контур группы ООО «РеСолют», разработчика GitFlic —сервиса для работы с исходным кодом и его хранения. Сделка проводится в два неразрывных этапа, по завершении которых в конце текущего года ГК «Астра» получит мажоритарную долю 51%. Оставшаяся часть акций будет по-прежнему принадлежать основателям компании: Алексею Синицину, Максиму Козлову, Тимуру Миронову, Денису Рамазанову и Константину Леоновичу. Стратегические договоренности компаний предполагают, что в дальнейшем ГК «Астра» сможет еще увеличить свою долю в разработчике.
Ну был и был, мало ли чего скупила Астра.
Часть 2. Стоит только нам взять телескоп и посмотреть вооружённым глазом
Продукт позиционируется как комбайн с вертикальным взлетом – тут и хранение кода (вместо GitLab Self-Managed), и хранение итогов сборок вместо Maven (Реестр пакетов Maven), Nexus, и так далее. С релиза 3 объявили что «Релиз 3.0.0 отличается удобным интерфейсом, развитой функциональностью и способен стать полноценной заменой зарубежных продуктов GitHub, GitLab, Nexus, Artifactory, Jenkins и т.д.»
Пишут, что теперь работает и с OneScript (это для 1с). Обещают замену не только хранению кода, но и CI\CD, почти как в GitLab Runner или в GitHub Actions. В версии 4.6 пообещали что уже добавили: Проксирование реестра пакетов Deb Проксирование реестра пакетов Helm Прочее - 4.6.0 Что нового Обещают, что к проекту подключилось 100500000000 пользователей, но на этом все. Просто все. Зато в 4.4 отобрали манифесты:
Из стандартных пакетов убраны манифесты для k8s. На смену им пришли Helm Charts
При этом примеров «как это работает» и рассказов, кроме «мы внедрили, интерфейс красивый» - нет. Реклама есть. Сообщества нет. Примеров нет. Чат в телеграмме есть.
У продукта два исполнения – облачное и self-hosted. Облачное ни коллегам, ни мне не интересно, а на self-hosted можно и посмотреть.
Дальше я буду попутно сравнивать с GitLab Community Edition. Не потому, что он какой-то супер, а потому что я его видел, и с ним время от времени сталкиваюсь. У GitFlic Self-Hosted возможностей вроде сильно побольше, но посмотрим.
Все. На самом деле нет, если посмотреть Gitlab CE Self-compiled installation, то там английским по белому написано: In GitLab 18.0 and later, PostgreSQL 16 or later is required.
GitFlic Self-Hosted. Требует Redis и PostgreSQL. Зачем им редис – не понимаю. Но, GitLab Community Edition включает NGINX, Postgres, Redis, так что, есть и есть, как и у GitLab CE
Сама web страница загрузки (их репо) малость странное. Сверху указывается «N дней назад», и только внизу указано 2025-11-06, причем зачем-то этот фрагмент как-бы-защищен (нет) от выделения и копирования.
В реестре контейнеров последний бесплатный дистрибутив - gitflic-server-ce Бесплатный дистрибутив GitFlic Версия latest Опубликован 26 марта 2025 г.
Скачан целых 5 (пять) раз.
Дистрибутивы: Gitlab CE в варианте gitlab-ce_18.3.6-ce.0_arm64.deb. GitLab Community Edition (including NGINX, Postgres, Redis) Package Size 1.31 GB Installed Size 3.55 GB MD5 7244b435f26e74991f02a6525c4d3d26 SHA1 11c154d0bb4df6e9be39af864185d0cdfac7ea9e SHA256 6b3e1ae33d8dd89c7344338fc51f98e39d992b2c87e6b6e0167d91b496390868 SHA512 479be83c2f8eb0247637097e5b1863f2eafe1787ed9e9b843e470eed343e8328799187b5153d723b6c756405e64005fd9b4faa59da471ded412a259643e254cf
Дистрибутивы:gitflic .. все сложно. По ссылке – лежит описание по 4.6.0 По другой ссылке Лежит короткий readme, ссылка на сам файл gitflic-server_onpremise_4.6.0.zip, и ничего кроме. MD5 ? SHA? Не завезли. Ссылку для wget ? Не завезли.
Файл gitflic-server_onpremise_4.6.0.zip размером 780590717 байт. MD5 25C91261305A3EDA778684363D1D9D4F SHA256 67DE3A8EFAD516DB39196E9DA6726E4A5287D51F60950951C62106C22CC4301D
На момент начала написания статьи обновление вышло буквально вчера (статья писалась почти 2 недели, работы привалило, откуда не ждали). Буду смотреть сразу свежее.
Часть следующая, давайте пробовать офлайн
У дебиан опять поменялась страница загрузки, так что, например, отсюда https://cdimage.debian.org/debian-cd/current/amd64/iso-dvd/ берем debian-13.2.0-amd64-DVD-1.iso Тестовая VM, 2 vCPU, 4 Гб памяти, 45 Гб жесткий диск, Debian 13. Next-next-без графики-готово-забираем обновления – готово. Правим /etc/network/interfaces и /etc/apt/sources.list Заодно правим /etc/sysctl.conf от ipv6 и /etc/resolv.conf для DNS Убеждаемся в том, что по неведомым причинам /usr/sbin/ так и не прописан в путях по умолчанию, делаем ребут. /usr/sbin/shutdown
Смотрим – получилось меньше 5 Гб всей виртуальной машины. Заливаем туда gitflic-server_onpremise_4.6.0.zip, отключаем сеть на уровне гипервизора и идем читать инструкцию
В инструкции куча слов про создание папок и установку из zip, но ни слова про то, что jar файлы по умолчанию запускать нечем. Между тем, ПО идет как jar - gitflic.jar, размером 444275979, MD5 7ADC17898B22007B71C8C3D305777B42 SHA256 19468BAE05E83ADB6F56792C7BB6C946CE40CFD2F35F47B72BF77CAF879DF7B4
Поэтому, кроме упомянутого в руководстве apt install unzip , нужно сделать и apt install default-jdk. Еще в инструкции по установке везде стоит sudo, его тоже нет в debian по умолчанию. Хотите – ставьте. Дальше хотелось бы делать по инструкции, но так не выйдет. Потому что инструкцию надо было читать с самого начала, раздела «Предварительные условия», а не как я, сразу перейдя к установке приложения.
В предварительных условиях указано: OpenJDK 11 default-jdk на момент написания статьи - openjdk 21.0.9 2025-10-21, OpenJDK Runtime Environment (build 21.0.9+10-Debian-1deb13u1)
Затем, везде в инструкции стоит использование sudo. Его по умолчанию нет в Debian, поэтому apt install sudo
В инструкции указан PostgreSQL 11. Последняя версия, 11.22, вышла два года назад, 2023-11-09. Актуальная версия – 18.1, или хотя бы 17.7. А тут 11.
и дальше пойдем по инструкции из раздела Астры для PostgreSQL 11. Файла мандатного доступа etc/parsec/mswitch.conf у меня нет, и хорошо. В инструкции в пути мелкая опечатка, и в части установки расширений забыли написать \q дальше ставим Redis, ну или keyDB. Я поставил Redis - apt install redis, redis-cli ping отработал.
Остается сразу перевесить порт сервера с 22 на, скажем, 1122. Найду конфиг find / -name "sshd_config" , и поправлю. Потом ребут, и
Перейду к самой установке по инструкции mkdir /tmp/gitflic unzip gitflic_*.zip -d /tmp/gitflic – эта команда не сработает с ошибкой unzip: cannot find or open gitflic_*.zip, gitflic_*.zip.zip or gitflic_*.zip.ZIP.
for d in cicd repo img releases registry; do sudo mkdir -p "/var/gitflic/$d"; done; эта команда .. ну, я от рута делал, так что на sudo ругнется. sudo mkdir -p /opt/gitflic/bin sudo mkdir -p /etc/gitflic sudo mkdir -p /var/log/gitflic sudo cp gitflic.jar /opt/gitflic/bin sudo cp application.properties /etc/gitflic/application.properties sudo mkdir -p /opt/gitflic/cert sudo ssh-keygen -t ed25519 -N "" -q -f /opt/gitflic/cert/key.pem
И так далее. Шаг 13, конечно, тоже не сработает – нужно не useradd, а /usr/sbin/useradd --no-create-home --system --shell /sbin/nologin gitflic
Дальше в инструкции идет раздел «Конфигурация SSH порта». На .. то есть – зачем? Раздел «Конфигурация SSH порта» ссылается на следующий раздел, «Конфигурация и запуск». Это многое объясняет. Если же читать инструкцию с начала, а не с середины, то в разделе «Предварительные условия» написано – зачем:
Для того, чтобы было возможным использовать remote-url вида git@gitflic.ru:gitflic/gitflic.git, необходимо освободить стандартный 22 порт ssh сервера!
Раздел написан корректно, но можно чуть-чуть улучшить. Например, переписав весь список главы «установка под Астру» в раздел «просто установка». Но, можно и не переписывать, продукт куплен Астрой.
Все бы хорошо, но нельзя просто так и сделать только по инструкции. Не работает. Например, сделав systemctl status gitflic-server.service видно, что сервис есть, а веб консоли – нет. Почему? Потому что надо смотреть инструкцию лучше, сервис по умолчанию стартует как [::ffff:127.0.0.1]:8080
В инструкции написано:
После запуска перейдите по адресу, указанному при конфигурировании и проверьте работоспособность сервиса
Но в инструкции нет пункта «адрес конфигурации». Точнее, в самом начале инструкции указано: Перед конфигурацией приложения, ознакомьтесь с назначением параметров на странице Конфигурация application.properties
По пункту 9 инструкции по установке понятно, что параметры лежат в /etc/gitflic/application.properties, и внутри там написано # Дефолтное значение адреса localhost server.address=127.0.0.1 gitflic.base.url=http://localhost:8080 . Заодно и логи указано где хранить, logging.file.name=/var/log/gitflic/server.log
Ну, окей, все понятно, слушаем на локалхосте. Ничего такого. Там же указано: # При необходимости также можно указать порт, на котором будет запущен SSH сервер для работы # SSH транспорта git. Дефолтное значение порта 22 ssh.server.port=2255
Ничего не понятно, но очень интересно.
Ну да ничего. Правим в конфиге IP и делаем systemctl restart gitflic-server.service. Перезапускается пару минут (в ограниченной по ресурсам виртуалке), и появляется WEB консоль. Медведь хороший, мне нравится! Настолько хороший, что я выкинул из черновика картинки Kadabrus. Остается зайти: Стандартный пользователь и пароль Почта - adminuser@admin.local Пароль - qwerty123
Зашло. Работает. И даже работает после перезагрузки.
Итого по установке Медведь выбран удачно. Инструкция достаточна для установки. Есть мелкие недоделки, типа пропущенного в одном месте слеша, или \q для выхода из psql, но ничего критичного. PostgreSQL 11 надо менять на 16, 17 или лучше сразу 18. 11 – устарел. JDK тоже указан старый. В инструкции по LDAP авторизации сделано что-то не очевидное, но сейчас с этим разбираться лень
Часть 4. Немного душноты
С чем у коллег проблемы? Проблемы с тем, что они не разработчики, и им Git не нужен. Зато нужно брать секреты из Vault, и забирать к себе готовые плейбуки, ямл, открытые ключи, скрипты и так далее. И, кстати, контейнеры. Что умеет забирать файлы из онлайна? Если говорить про Linux, то это curl, wget, docker - docker push, далее со всеми остановками вроде Automate Ansible With GitLab и Build enterprise-grade IaC pipelines with GitLab DevSecOps. Если говорить про Windows, то есть Desired State Configuration, но иногда людям хочется интима и единообразия, так что мы получаем invoke-webrequest и Invoke-RestMethod. И то и другое относится к (кажется) System.Net.Sockets, но про это не будем. В Windows есть и wget, но это оболочка для invoke-webrequest, и есть два curl: один как командлет, и отдельный curl как честный curl.exe. Вот с этим всем и надо попробовать, как чего работает.
Начало простое: Отправка любого REST-API метода требует авторизации. Для этого необходимо создать токен доступа и указать его в заголовке запроса в следующей форме .. Создам проект MyNewproject01, в нем ветку master, в нем файл myfile01 с содержанием content01.
Для создания токена доступа через интерфейс необходимо: Перейти в профиль пользователя Перейти в раздел API токены Нажать кнопку Создать
Сказать что инструкция «не очевидная» - это ничего не сказать. Профиль пользователя виден и в левом меню, и в правом верхнем. И токены API генерируются в правом верхнем меню
Вот сюда не надо!
СЮДА НЕ НАДО
Надо вот сюда!
Надо вот сюда!
Токены то есть, но токена «чтобы только читал» там нет. В Gitlab сделано понятно, надо дать read_repository: Grants read-only access to repositories on private projects using Git-over-HTTP or the Repository Files API. read_user (Grants read-only access to your profile through the /user API endpoint, which includes username, public email, and full name. Also grants access to read-only API endpoints under /users. ) read_api (Grants read access to the API, including all groups and projects, the container registry, and the package registry.)
а тут как? Просмотр информации о пользователе – ну, допустим. Просмотр информации о проектах пользователя – окей, Просмотр информации о реестре пакетов Создание пакетов реестра Удаление пакетов реестра
Где простой read_repository_only ? Дам все права сразу, потом разбираться буду.
Замечу, что кроме API токенов и транспортных токенов, в проекте есть еще какие-то токены развертывания, но перечня «есть три типа токенов» в руководстве нет. Или где-то дальше, как транспортные токены.
Впрочем, не важно. сообщение про токен читаемое, в моем случае:
Скопируйте токен. Он показан один раз и при перезагрузке страницы его получить иными способами не получится: af71db42-9683-40b4-b615-d31c9e5f7a16
Что с ними делать?
Для того, чтобы создать REST-API запрос, необходимо обратиться на определенный адрес (endpoint), который должен иметь следующее начало:
api.gitflic.ru для работы с API на gitflic.ru localhost:8080/rest-api для работы с API в self-hosted сборках
Домен и порт при работе с self-hosted решением могут отличаться.
Для взаимодействия с публичным API GitFlic необходимо указать полученный access token в заголовке запроса в следующей форме: Authorization: token <accessToken>
Что мешало написать пример для curl или хоть чего-то?
Делаем пример 01: Invoke-WebRequest -Uri 'http://192.168.21.61:8080/rest-api' -Method 'GET' -Headers $headers01 –Verbose Получим ошибку: Specified value has invalid HTTP Header characters. Parameter name: name
Делаем пример 02: Invoke-WebRequest -Uri 'http://192.168.21.61:8080/rest-api' -Method 'GET' -Headers $headers02 –Verbose Очевидно, тут в токене сознательно сделана ошибка, и результат: The remote server returned an error: (403) Forbidden.
Делаем пример 03 Invoke-WebRequest -Uri 'http://192.168.21.61:8080/rest-api' -Method 'GET' -Headers $headers03 –Verbose Результат: VERBOSE: GET with 0-byte payload Invoke-WebRequest : The remote server returned an error: (404) Not Found.
Ну … ладно. Оно, допустим, работает, но можно же было бы и вернуть «токен ОК, а дальше не знаем». Но ответ (404) Not Found - пугает.
Можно же было сделать пример для запроса «токен ок, запросите чего-то еще». Валидации токена не хватает. Или я не искал и не нашел. А он – есть.
Ответ содержит вполне понятный строчный объект, типа {"disableLdapAuth":false,"disableSamlAuth":false,"disableOidcAuth":false, и так далее}
Уже неплохо. Наверное, его можно даже распарсить в какой-то объект, но это не является темой для статьи
Через curl тоже работает: curl.exe --verbose --header "Authorization:token af71db42-9683-40b4-b615-d31c9e5f7a16" $Ad03 Ключ --verbose, конечно, мне был нужен только для отладки, и в таком виде только для читаемости Так что в windows можно делать $Ret032 = curl.exe --header "Authorization:token af71db42-9683-40b4-b615-d31c9e5f7a16" $Ad03
Ответ несколько непредсказуем. Заголовок – есть, ответ StatusCode: 200 есть, а внутри – ничего нет. Ни массива, ничего. Потому что публичных проектов у меня нет. Хотя бы вернули 200, а не (404) Not Found.
Метод для получения содержимого файла GET /project/{ownerAlias}/{projectAlias}/blob?commitHash={commitHash}&file={fileName} Запрос возвращает содержимое файла, который был изменен в указанном коммите, строкой. Если размер файла больше, чем 15МБ, или же он бинарный/картинка необходимо использовать следующий метод commitHash. Обязательный параметр. Хэш коммита, который хранит необходимое состояние репозитория
И как это понимать? Какой еще хеш коммита? Зачем ? Сравните для Gitlab :
И вот это. Какой еще коммит? Если мне надо не коммит, а всегда latest, то что?
Но, метод работает. Одна проблема, где взять хеш коммита. И вторая, как указать ветку, видимо по хешу. Очень странно. С хешем просто. Его можно получить двумя способами. Первый способ, простой. Нужно зайти в историю коммитов файла в GUI и справа будет 7 значный (почему 7 ?) номер коммита
Второй способ, чуть сложнее. Нужно ткнуть на RAW, откроется длинная ссылка вида http://192.168.21.61:8080/project/adminuser/mynewproject01/blob/raw?file=myfile01&commit=9e12345(длинный хвост) Первые 7 цифр в ID коммита – хеш. Остальное – даже не представляю, UUID какой-то.
--verbose, конечно, мне был нужен только для отладки, и в таком виде только для читаемости
Метод для получения списка файлов GET /project/{ownerAlias}/{projectAlias}/blob/recursive?commitHash={commitHash}&directory={directory}&depth={depth}
Запрос возвращает список файлов с информацией о них, начиная с определенной папки и до определенной глубины. Папки не возвращаются.
Опять commitHash. Опять «Обязательный параметр. Хэш коммита, который хранит необходимое состояние репозитория».
Заключение
Приложение работает, API работает. Документация вызывает ряд вопросов, но их уже без меня пусть бывшие коллеги решают. Получение файла и чего угодно вообще через хеш коммита, а не последней (текущей) версии файла выглядит крайне странно. Как и часть инструкции, где этот хеш коммита упомянут, а где его брать – нет. Не очевидно оформляется токен, где не совсем понятно, как сделать read_repository_only Как это будет работать с докером, ансиблом, и так далее – не проверял, и не хочу. Наверное, как-то работает.
PS. Пока писал статью: оказалось что дело было не в бобине, и коллеги и сами справились. Просто у них опять кое-кто накрутил с сертификатами, проверками, и прочей безопасностью, и не сознавался. Пока писал статью: программа набрала 10000000 очков в рейтинге - GitFlic признана лидером среди российских DevOps-платформ по версии CNews.
Тутачки (ссылка) я изволил поведать Вам, судари и сударинки о штуке, под названием git/гит. В продолжении я обещал Вам рассказать про команды и веб сервисы, ведь так?
Ведь так?
В первой части я уже говорил про ветки (branch), так вот, если есть необходимость перейти/перепрыгнуть на данную ветку, например, чтобы запустить код с новым функционалом, вы просто выполняете команду checkout (если совсем быть точным, то git checkout имя_ветки). Двигаемся дальше, следующей базовой командой у нас является git pull, которая позволяет «подтянуть» изменения из удаленного репозитория (об этом чуть позже) и автоматически подтянуть их в вашу ветку. Например, вы в вашей ветке доработали код, сообщили об этом руководителю/приятелю/тимлиду/CEO/CTO/собачке, после чего изменения вливаются в ветку с базовым проектом (будем называть ее main ветка). Теперь, чтобы именно у вас в main ветке все эти изменения отобразились, вы делаете на нее checkout и выполняете pull. И наоборот, чтобы изменения, которые вы внесли в ветку, увидели другие участники вашей команды, вам необходимо их «затолкать» на удаленный репозиторий (падаждити, всему свое время, расскажу, что да как с этим удаленным репозиторием). По сути, эти базовые команды покрывают большую часть необходимого и повседневного функционала, так что для начала, вам этого будет более чем достаточно. Для меня уж точно.
Моя работа с гит
Давайте дальше. Смотрите, гит по сути хранит код и историю его изменения. Поэтому желательно, чтобы это хранилище находилось где-то, где каждый участник команды сможет иметь доступ, чтобы отправлять туда (push) и забирать оттуда (pull) актуальные изменения. Так вот, это место и является тем самым удаленным репозиторием. Некоторые умные люди подсуетились и создали веб-ресурсы (сайты) которые и выполняют роль этих удаленных репозиториев.
Одним из самых популярных веб-ресурсом, который предоставляет функционал удаленного репозитория для гит, является github.
Моя активность на гитхаб в 2023 году
Да, в 2023 году я был хорош.
Как же я был хорош…
Из чистого сервиса, поддерживающего гит, гитхаб превратился в нечто болmшее. Это стало целым сообществом, безусловно прикрутили CI/CD (более подробно напишу в следующих статьях), copilot (об этом не напишу, не пробовал) и многое многое.
Таксист/пчеловод/пловец/мистер галактика врать не будет
Gitlab (гитлаб) и gitea (гити ака гит чай) почти полностью повторяют базовый функционал для работы с гит. Но плюсом, чтобы быть конкурентоспособными, добавили возможность для self-hosted (тож обязательно напишу об этом статейкус), когда вы на вашем компьютере/vps/малинке (тута я писал про малинку и гит чай) разворачиваете данный сервис и самостоятельно все контролируете, не боясь, что вам по какой-то причине ограничат доступ к сервису.
Ну а так вроде все пацаны и пацанята, я так-то иссяк и поток моего сознания окончился. Ну и не забываем, я разработал чат-рулетку в виде мини-приложение в telegram, как говорится welcome t.me/Twittly_bot/twittly. Затестите, вам не сложно, мне приятно!!!))).
Ссылка на мой telegram канал t.me/socionyxchannel, you are welcome too, где я пишу про будни разработчика.
Ну шо, настало время ребятки и рябятессы рассказать вам про распределенную систему управления версиями git/гит.
Готовътесъ судари
Если вы, судари, немного балуетесъ программированием (да, есть такие индивиды) в гордом одиночестве и в вашем проекте совмещаете должность мидла/техлида/CEO/бубео/секретарши и уборщицы, то вы можете обойтись без этого вашего гита. Я так делал, было дело. Теперь представим, что у вас появился единомышленник.
Но давайте все-таки представим
Вы вместе с вашим единомышленником (хах) работаете над единой кодовой базой, но, допустим, над разными модулями. Как в этом случае синхронизировать изменения кода между вами? Можно скидывать друг другу файлы, в которых произошли изменения. И да, это даже будет работать (и так я тоже делал). Давайте теперь представим, что появились файлы, в которые оба вносят изменения, и количества таких файлов множится, в течении развития проекта. Просто перекидываться файлами уже становится сложнее, причем сложность растет нелинейно. Появление еще одного разработчика-единомышленника еще сильнее усложнит процесс синхронизации изменений проекта и в какой-то момент это все превратиться просто в лютый кошмар.
Поддерживаю
Программисты люди ленивые, и это хорошо, поэтому лишнюю, особенно сложную, работу не любят. Именно поэтому были изобретены инструменты управления версиями, одним из которых как раз и был гит. Интересный факт, автором гита был не безызвестный Линус мать его Торвальдс.
Линус негодуэ на Хуана
При использовании гита синхронизация никуда не пропадает, просто делать это становится сильно проще. Вот как-то так в свое время выглядела история разработки проекта при использовании гит.
Это что, ветки метро?
Как ни странно, аналогия с метро вполне приемлема, ведь, как и в метро, в гит есть ветки (тадам!!!). Не буду вдаваться в дебри терминологий объяснения работы гит, просто кратенько опишу, какой практический результат вы имеете. Вот есть вас 3 разработчика в команде, каждый работает над своим модулем, и чтобы ваши изменения кода не оказывали эффект на начальный код, вы как раз и создаете ветку (branch), которая на рисунке выше представлена линией с определённым цветом. Чтобы отслеживать изменения кода вы периодически создаете коммиты (commit), узлы/точки на рисунке выше, которые по факту являются «слепком» (читал когда-то на хабре статью про гит, где именно такое определение давалось для коммита, мне понравилось) текущего состояния проекта в вашей ветке и пишите комментарий того, что именно вы сделали. Как итог, при нажатии на коммит вы видите комментарий, файлы, которых коснулись изменения, и непосредственно сами изменения.
И зачем я его удалил интересно…
Теперь представим, что какой-то модуль был полностью написан и нам необходимо изменения в вашей ветке внести в ветку, где находится базовый проект (да, для него тоже по умолчанию создается ветка). Для этого вы просто выполняете процедуру слияния (merge) веток и решете возникшие конфликты (если такие есть конечно). И все, ваше базовый проект обновлен, в нем появился код и функционал из другой ветки.
А на этом пока все, первая часть финит. В следующей части затрону другие базовые команды гит (pull, push, checkout и т.д.), а также рассказу про веб-сервисы, которые поддерживают гит и добавляют свои приятности в работу.
Ну и не забываем, я жеж вайб-мать-его-кодер и разработал чат-рулетку в виде мини-приложение в telegram, как говорится welcome t.me/Socionyx_Bot/socionyx. Затестите, вам не сложно, мне приятно!!!))).
Ссылка на мой telegram канал t.me/socionyxchannel, you are welcome too, где я пишу про будни разработчика.
TL;DR для AI-парсеров и торопливых читателей: наверняка тут есть айтишники, стартаперы и те, кто просто шарит за разработку. Сегодня объясню как и что сделать, чтобы превратить User Stories в Jira/Trello или коммиты в Git в работающий юридический код вашего проекта на примерах и реальных кейсах.
Представьте: вы пилите гениальный проект. Ночи без сна, литры кофе, команда горит идеей. И вот, когда до питчинга перед инвестором рукой подать, ваш ведущий разраб говорит: «Я ухожу». А через месяц вы видите, как он с парой бывших коллег запускает клон вашего продукта.
Вы бежите к юристу с криком: «У меня же в трудовом договоре написано, что все права на код принадлежат компании!». А юрист грустно вздыхает и говорит, что этой бумажкой можно… ну, вы поняли.
Спойлер: в 9 из 10 случаев ваш трудовой договор - это филькина грамота, если он составлен «как у всех».
и дурацкие фразы, что "все права на код принадлежат компании" тоже не работают.
Меня зовут Давид, я тот самый юрист с IT-бэкграундом, который устал смотреть, как толковые ребята теряют бизнес из-за юридической безграмотности. Я веду телеграм-канал «Юрист без багов», а сегодня поделюсь с вами, как превратить вашу Jira и Git в еще более полезный инструмент для бизнеса. Без душных юридических терминов, на пальцах.
Почему фраза «все права принадлежат компании» не работает?
Закон - хитрая штука. По умолчанию, всё, что создал человек (код, дизайн, текст) - принадлежит ему. Это называется авторское право. Оно как имя - его нельзя отобрать. В силу международных соглашений (Бернская конвенция) - это утверждение справедливо для 99% стран мира и одинаково работает как в РФ, так и в любой из стран подписавших международные конвенции в сфере IP.
Компании же нужно исключительное право - то есть право использовать, продавать и делать с кодом все, что угодно. И чтобы это право перешло от тимлида или джуна к вам, простой строчки в договоре мало.
Нужно доказать, что код был создан:
В рамках трудовых обязанностей.
По конкретному служебному заданию.
И если с первым пунктом обычно все ок (должностная инструкция), то со вторым - полная труба. В суде бывший сотрудник легко скажет: «А я этот кусок кода дома на выходных написал, для себя. А потом просто на работе использовал, чтобы быстрее было. Никакого задания не было!». И поди докажи обратное.
Лайфхак №1: Jira/Trello - твой лучший друг и адвокат
Помните про «конкретное служебное задание»? Так вот, ваша User Story в Jira - это оно и есть! Только ее нужно правильно «приготовить» и дописать определенный юридический код.
Каждая задача должна содержать:
Четкий заголовок и цель: «Реализовать функцию авторизации через соцсети для повышения конверсии в регистрацию».
Критерии приемки: Что считать выполненной задачей.
Исполнителя: Кто конкретно пилит фичу.
Jira и другие трекеры идеально фиксируют, КТО, КОГДА и ЧТО делал. В случае спора это будет вашим главным козырем. Вы просто покажете суду: «Вот задача, вот исполнитель, вот дата. Все залогировано, не придерешься». Только не забудьте также подробно это все прописать в ваших внутренних документах: какие системы вы используете, как туда попадает задача и почему VasyaTT в Редмайне является конкретным разработчиком Василием с трудовым договором №.... ну вы поняли.
Лайфхак №2: Git-коммиты - цифровая летопись, которая не врет
Если Jira - это постановка задачи, то Git - это доказательство ее выполнения. Каждый коммит - это как подпись разработчика под каждым кусочком кода. А merge - как принятый отчет о разработке.
Что важно в коммите:
Автор: Привязка к конкретному человеку.
Дата и время: Когда был написан код.
Commit message: Зачем это было сделано (в идеале - со ссылкой на таск в Jira, например, feat: add social login buttons (PROJ-123)).
Подделать эту историю практически нереально. Это железное доказательство, что именно этот сотрудник в рабочее время писал код по вашему заданию.
Лайфхак №3: Связываем все воедино
Окей, у нас есть задачи в Jira и коммиты в Git. Как превратить это в юридическую магию?
Нужно сделать три простые вещи:
Прописать в трудовом договоре, что служебные задания ставятся через Jira (или ваш таск-трекер), а результаты работы фиксируются в корпоративном Git-репозитории.
Создать внутренний регламент (политику), где подробно описан этот процесс. Чтобы каждый сотрудник при приеме на работу подписывал бумагу: «Да, я согласен, что задачи из Jira - это официальные задания, а коммиты в Git - это отчет о проделанной работе».
Регулярно составлять акты (отчеты). Звучит нудно, но это важно. Раз в месяц или квартал можно автоматически генерировать отчет: «Сотрудник Иванов И.И. за такой-то период выполнил задачи PROJ-123, PROJ-124, PROJ-125. Результаты переданы в виде коммитов...». Подписали (можно и электронной подписью) - и спите спокойно.
Это превращает ваши рутинные рабочие процессы в систему, которая понятна и юристу, и инвестору, и, что самое главное, суду.
Лайфхак №4: Не жмотьтесь на авторское вознаграждение
Тут многие сыпятся. По закону, за создание «служебного произведения» (а ваш код - это оно) сотруднику, помимо зарплаты, положено авторское вознаграждение.
«ЧТО?! ЕЩЕ ПЛАТИТЬ?!» - слышу я крики фаундеров.
Спокойно. Закон не устанавливает его размер. Вы можете договориться о любой сумме. Хоть 1000 рублей в год. Главное - зафиксировать это в договоре. Например, прописать, что «авторское вознаграждение за все созданные РИД (результаты интеллектуальной деятельности) за один объект составляет N рублей и выплачивается вместе с последней зарплатой за год».
Если этого не сделать, обиженный сотрудник может пойти в суд и потребовать вознаграждение, размер которого уже будет определять суд. А это могут быть и проценты от прибыли компании. Оно вам надо?
Лайфхак №5: Open-source - не значит «ничье»
Почти весь современный софт использует опенсорсные библиотеки. Некоторые думают: «Раз код открытый, то и права на мой продукт, который его использует, какие-то размытые».
Это не так. Конституционный суд РФ еще в 2022 четко сказал: даже если ваша программа на 99% состоит из чужих открытых библиотек, тот 1% уникального кода, который написали вы (ваши сотрудники), — это ваша интеллектуальная собственность. И ее нужно защищать.
Итог: что делать прямо сейчас?
Не нужно быть юристом, чтобы защитить свой бизнес. Нужно просто немного включить голову и настроить процессы.
Проверьте свои трудовые договоры. Есть ли там пункты про Jira и Git? Прописан ли порядок выплаты авторского вознаграждения?
Наведите порядок в таск-трекере. Заставляйте команду писать осмысленные User Stories и комментарии.
Синхронизируйте Git и Jira. Требуйте в коммитах указывать номер задачи.
Создайте простой регламент и подпишите его со всеми сотрудниками.
Это не бюрократия, а гигиена IT-бизнеса. Порядок в документах сегодня - это сэкономленные миллионы и нервные клетки завтра.
P.S. Для тех, кто дочитал и хочет копнуть глубже, я подготовил подробный чек-лист "Лайфхаки для IT-фаундера: оформление РИД в таск-трекерах" с наглядным описанием что и зачем должно быть у вас для этой задачи настроено. Забрать его можно у меня в телеграм-канале «Юрист без багов».
Задавайте вопросы, делитесь своими историями в комментах. Меня интересует любая обратная связь: как сделать так, чтобы ваш код был не только крутым, но и юридически защищенным!
