Системы управления версиями *

Мы с радостью объявляем о релизе GitLab 16.11 с GitLab Duo Chat в общем доступе, продуктовой аналитикой в общем доступе, областями видимости для политик безопасности и многими другими фичами!

Привет, Хабр! На связи Андрей Аврамчук (@Mimizavr). Недавно я побывал на онлайн-презентации GitVerse — платформы для совместной разработки и хостинга кода. Планируется, что она станет инструментом нового поколения, избавляющим разработчика от многих болей. Под катом вы узнаете:

— Чем GitVerse может помочь открытому ПО.

— Почему перенос своих проектов на платформу — это легко и приятно.

— Куда спрятаться от ИИ (спойлер: никуда).

— Умеет ли GitVerse в CI/CD.

— И наконец, какие есть причины смотреть в будущее с оптимизмом.

Мы с радостью объявляем о релизе GitLab 16.10 с семантическим версионированием каталога CI/CD, шаблонами вики-страниц, возможностью перенаправлять трафик CI на вторичные ноды Geo, новой интеграцией ClickHouse для высокопроизводительной аналитики DevOps и многими другими фичами!

Недавно я провела в Mastodon опрос о том, насколько мои читатели уверены в том, что они хорошо понимают работу HEAD в Git. Результаты (на основании примерно 1700 голосов) меня немного удивили:

10% — 100%

36% — достаточно сильно уверен

39% — уверен в некоторой степени

15% — представления не имею

Меня удивило, что люди не уверены в своём понимании: я-то считала, что HEAD — это довольно простая тема.

Обычно, когда остальные, в отличие от меня, считают какую-то тему запутанной, причина заключается в какой-то скрытой сложности, которую я не учитываю. И в дальнейших обсуждениях выяснилось, что HEAD действительно чуть сложнее, чем я считала!

Мы, разработчики ПО, пользуемся git каждый день, однако большинство из нас применяет только самые основные команды, например, add, commit, push и pull, как будто на дворе по-прежнему 2005 год.

С тех пор в Git появилось множество фич, пользование которыми может сильно упросить вашу жизнь. Так давайте исследуем некоторые из недавно добавленных современных команд git, о которых вам стоит знать.

Я работаю над созданием Graphite, источником вдохновения для которого стал внутренний инструментарий Facebook. Когда я решил создать стартап с друзьями, то никогда раньше не слышал о Mercurial, хотя всегда страстно любил инструменты разработчика. Мой предыдущий опыт разработки включал в себя личные проекты, домашнюю работу в колледже, разработку для iOS в Google и развитие инфраструктуры в Airbnb. На протяжении всей моей карьеры использование git было таким же естественным, как воздух. Он настолько популярен, что лично я считал его единственным подходящим инструментом для создания изменений в коде и управления ими.

Забавно, что специалист по Mercurial Грегори Gregory Szorc работал рядом со мной в Airbnb, хотя я знал его только как приятного коллегу, но не представлял, что он контрибьютор.

В 2021 году мои коллеги по команде Томас и Ник раскрыли мне глаза. Они пришли из Facebook и, к моему удивлению, едва знали Git. Зато они имели глубокое понимание паттернов Mercurial и рабочего процесса Facebook на основе «многослойных diff» (stacked diff). Со временем они убедили меня в полезности этого паттерна и мы развернули направление развития компании, чтобы реализовать многослойные diff для разработчиков GitHub.

Но пост посвящён не нашему стартапу. Он о важном вопросе, не дававшем мне покоя последние три года. Почему фейсбукеры не пользуются Git? Зачем они выбрали Mercurial и создали на его основе собственные рабочие процессы? Я знаю что Google не пользуется Git, но это логично, культура разработки Google возникла на пять лет раньше Git. Facebook же был основан примерно в то же время, что и создан Git, около 2004 года, и ко времени, когда Facebook начал серьёзно выбирать инструментарий для управления исходниками, Git был старше и популярнее Mercurial. Так почему же Facebook не использует Git?

Мы с радостью объявляем о релизе GitLab 16.9 с GitLab Duo Chat, доступном для Premium пользователей SaaS и в инстансах с самостоятельным управлением! Также появилась возможность запрашивать изменения в мерж-реквесте без блокировки мержа, улучшенный интерфейс страницы переменных CI/CD, новые настройки для автоматической отмены конвейеров и многие другие фичи!

11 января 2024 года была опубликована информация об уязвимости в GitLab CE/EE, затрагивающая все версии с 16.1 до 16.1.6, 16.2 до 16.2.9, 16.3 до 16.3.7, 16.4 до 16.4.5, 16.5 до 16.5.6, 16.6 до 16.6.4 и 16.7 до 16.7.2. Данная уязвимость получила идентификатор CVE-2023-7028 и 7.5 баллов критичности по CVSS NVD - CVE-2023-7028 (nist.gov).

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

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

Первый раз столкнулись с Git и не понимаете, что это такое?

Устали бездумно выполнять серию комманд чтобы закинуть свой проект на GitHub?

Хотите понять, чем отличается merge, rebase, push и pull?

Надоело видеть ошибку о non fast-forward merge и не понимать, что с этим делать?

Сейчас попробуем разобраться в этом всем.

Автор оригинала Скотт Чакон — сооснователь GitHub и основатель нового клиента GitButler. Этот клиент ставит во главу угла рабочий процесс и удобство разработки, в том числе код-ревью, и не является просто очередной обёрткой над CLI git.

Далее в нашей серии постов из трёх частей у нас новые фичи! Здесь я расскажу про пять относительно новых вещей в git, о которых вы могли не слышать, потому что ну почему вы?

Мы взглянем на:

• Штуки с git branch.
• Принудительный безопасный пуш.
• Подписывание коммитов ключом SSH.
• Подписывание пушей.
• Обслуживание Git.

Автор оригинала Скотт Чакон — сооснователь GitHub и основатель нового клиента GitButler. Этот клиент ставит во главу угла рабочий процесс и удобство разработки, в том числе код-ревью, и не является просто очередной обёрткой над CLI git.

Далее в нашей серии постов из трёх частей у нас новые фичи! Здесь я расскажу про пять относительно новых вещей в git, о которых вы могли не слышать, потому что ну почему вы?

Мы взглянем на:

• Штуки с git branch.
• Принудительный безопасный пуш.
• Подписывание коммитов ключом SSH.
• Подписывание пушей.
• Обслуживание Git.

Автор оригинала Скотт Чакон — сооснователь GitHub и основатель нового клиента GitButler. Этот клиент ставит во главу угла рабочий процесс и удобство разработки, в том числе код-ревью, и не является просто очередной обёрткой над CLI git.

В первом посте из этой короткой серии по Git я хотел начать с вещей, уже существующих какое-то время. При этом кажется, что многие люди о них не знают или не умеют ими пользоваться. В них нет ничего нового, но я нахожу их полезными и, возможно, не совсем освещёнными. Я просто хочу рассказать о:

• условной конфигурации;
• git blame и git log с диапазонами строк;
• git blame с отслеживанием;
• git diff по словам вместо строк;
• запоминании разрешения конфликтов.

Мы с радостью объявляем о релизе GitLab 16.8 с поддержкой менеджера секретных ключей GCP, возможностью ускорения сборок с прокси зависимостей Maven, общим доступом к рабочим пространствам, новым представлением DevOps c бенчмарками на основе DORA и многими другими фичами!

Небольшой обзор систем контроля версий, альтернативных git, и основанных на математической теории. Речь пойдёт о двух системах распределённого контроля версий: Darcs, написанной на Haskell, и Pijul, написанной на Rust. Обе они сейчас активно развиваются и предлагают свои сетевые репозитории. Оказалось, что про них на Хабре толком нет ничего, тогда как про git образовался целый хаб. Поскольку я люблю и использую Haskell, я остановил свой выбор на Darcs, и вот, спустя два месяца непрерывной работы над библиотекой геометрической алгебры для hackage, я готов поделиться впечатлениями от её использования.

📘 Нативное решение Unity

В 2018 разработчики из Unity релизнули централизованное хранилище для итеративных обновлений движка и расширений Editor, которое получило название UPM - Unity Package Manager.

Вышел релиз GitLab 16.7 с GitLab Duo Code Suggestions в общем доступе и бета-версией каталога CI/CD

На этот раз мы с радостью объявляем о релизе GitLab 16.7 с фичей GitLab Duo Code Suggestions в общем доступе, бета-версией каталога CI/CD, новым детальным представлением графиков отчётов Insights, результатами сканирования SAST в представлении изменений мерж-реквеста и многими другими фичами!

Мы все были там: Вы работали над множеством изменений одновременно, некоторые из которых не имели ничего общего. Для удобства вы решили объединить все эти изменения в один коммит и на этом закончить. Но хотя это может показаться заманчивым, на самом деле это может привести к большим проблемам в дальнейшем. Большие коммиты могут:

Сегодня мы с радостью объявляем о релизе GitLab 16.6 с бета-версией GitLab Duo Chat, правилами соответствия требованиям на основе подтверждения мерж-реквестов, улучшенным механизмом ветвления, улучшенным интерфейсом пользователя для управления переменными CI/CD и многими другими фичами!

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

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

О том, какой путь проходит релиз и какие инструменты обеспечивают его надежность, расскажет engineering manager Mindbox, Бадал.

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

«Какого же размера он должен быть? Бывает ли идеальный размер? Если бы теоретически можно было полностью его контролировать, то насколько большим его нужно делать?»

Вы гуглите, находите множество ресурсов, сайтов и статей наподобие этой, которые анализируют тему и делают примерно такой вывод:

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

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

Однако моя статья будет немного о другом:

«Мы проанализируем PR примерно 30 тысяч разработчиков, чтобы проверить, как размер PR коррелирует с временем внедрения, полученными комментариями и отказами во внесении изменений, чтобы найти статистически наилучший размер и понять, что на него влияет.»

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