![](https://habrastorage.org/r/w1560/getpro/habr/upload_files/bac/ed2/09a/baced209ac3e64a9e5ec7289284c541e.png)
Всем привет!
Сегодня хочу поделиться решением проблемы поиска по коду. Статья будет полезна пользователям систем контроля версий в средних и маленьких компаниях, а также для понимания интересных подходов к ее решению.
GIT, SVN и иже с ними
Всем привет!
Сегодня хочу поделиться решением проблемы поиска по коду. Статья будет полезна пользователям систем контроля версий в средних и маленьких компаниях, а также для понимания интересных подходов к ее решению.
Статей на тему много, но, видимо, недостаточно: время от времени слышу от коллег (последние 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, о которых вы могли не слышать, потому что ну почему вы?
Мы взглянем на:
Автор оригинала Скотт Чакон — сооснователь 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, новым детальным представлением графиков отчётов Insights, результатами сканирования SAST в представлении изменений мерж-реквеста и многими другими фичами!