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

Всем привет!

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

Статей на тему много, но, видимо, недостаточно: время от времени слышу от коллег (последние 10 лет, в 4-х разных компаниях):

«Не могу пошарить экран с кодом, у меня другая ветка сейчас».

«Не хочу переключать ветку, придется запускать кодогенерацию, у меня сбросятся build-файлы, потом это опять пересобирать!»

«Стаскивать ветку для просмотра ПР? Это же неудобно, надо "стэшить" изменения, ветку переключать».

Собеседование:

- Какую систему контроля версий используете?
- У нас RTC, но ты привыкнешь.

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

Так получилось, что на новом месте работы использовалась IBM Rational Team Concert или RTC. RTC - разработка компании IBM и является централизованной системой контроля версий. Лицензия на RTC подходила к концу, программисты пускали слюни на git. После обсуждений было принято решение перейти на git. И пока коллеги рассматривали все за и против между использованием rebase и merge команд, я решала написать об опыте перехода с RTC на git .

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

Мы с радостью объявляем о релизе GitLab 17.0 с каталогом CI/CD в общем доступе, панелью аналитики AI Impact, хостингом обработчиков заданий на Linux Arm, страницами с подробной информацией о развёртывании и многими другими фичами!

Мы с радостью объявляем о релизе 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 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 в представлении изменений мерж-реквеста и многими другими фичами!