Git - одна из наиболее популярных систем контроля версий, используемых разработчиками по всему миру. Однако, существует множество различных подходов к организации рабочего процесса с использованием Git. В этой статье мы рассмотрим некоторые из наиболее популярных методов, такие как Git Flow, Trunk-Based Development (TBD), на их основе бизируются остальные:
Привет Хабр, меня зовут Дмитрий Несмеянов, я являюсь руководителем направления разработки ML-инфраструктуры "ЛОКО-банка".
Сегодня я хочу рассказать про DVC: инструмент, который многие, незаслуженно, обходят стороной. Была хорошая статья от Райффайзен Банк, в этой статье я постараюсь резюмировать мою и коллег экспертизу в работе с DVC.
DVC (Data Version Control) - это система версионирования датасетов и не только, которая является надстройкой над git. Если вы умеете работать с git, поздравляю, вы умеете работать с DVC. Кроме того, DVC позволяет логировать эксперименты, а также делать Auto-ML.
Из уст переводчика: инструмент puro совсем новый по меркам продуктовой разработки (первый релиз – октябрь 2022), но, по моему личному мнению, api его уже достаточно стабилизирован, а сам инструмент выражает искреннюю радость подходами. Большинство его текущих преимуществ (и выгодных отличий от fvm) я разбирал ранее в этом исчерпывающем материале – "Полное руководство по использованию FVM (Flutter Version Management) – жонглируйте версиями Flutter sdk в своих проектаx" – где вполне наглядно показано торжество puro...
В жизни разработчика рано или поздно наступает момент, когда проектов становится так много, что одной единственной (обычно это stable) версией flutter sdk уже не обойтись. В данной статье мы рассмотрим консольный инструмент fvm для управления версиями flutter sdk, ВСЕ имеющиеся в нём команды и пройдём путь от установки до использования в проекте.
В качестве бонусных аспектов я также уделил время на изучение Sidekick (графическая оболочка для fvm) и на разбор имеющихся аналогов (Puro – сильно уверен, что вы не слышали о таком инструменте).
Прошу к изучению 🧐
Это практическое дополнение к моей предыдущей статье, где я рассказывал, почему вам может быть интересен способ ведения версий с помощью бранчей. Сейчас же я хотел подробнее показать, как это можно реализовать на примере одного сценария. Естественно, я не могу показывать свои реальные юзер флоу, поэтому предположим, что у нас есть большой сценарий, за развитие которого вы отвечаете.
Сегодня мы с радостью объявляем о релизе GitLab 16.2 c совершенно новым редактором текста, палитрой команд, поддержкой подписей без ключей с Cosign, новым уровнем настроек для панели аналитики разработки и многими другими фичами!
Актуальность конфигурационных файлов – основа основ стабильной работы сети и активного оборудования. Раньше конфигурационные файлы можно было просто копировать автоматизированным способом при помощи специальной утилиты, и этого вполне хватало для успешного восстановления после замены вышедшего из строя оборудования. Но появились новые задачи, это связано с тем, что многие вендоры начали развивать технологию Infrastructure as Code (IaC).
То есть, можно описать свои действия с устройством с помощью кода, а затем его применить, а не использовать интерфейс командной строки или GUI интерфейс. Это существенно уменьшает вероятность ошибки при каких-либо манипуляциях при управлении устройством. В связи с этим возникла другая задача – как отслеживать актуальность и историю изменений в данном коде. Центр информационных технологий РТ стал использовать систему контроля версий, так же как её используют большинство программистов.
Сегодня речь пойдет про Git.
Что такое «система контроля версий» и почему это важно? Система контроля версий – это система, записывающая изменения в файл или набор файлов в течение времени и позволяющая позже вернуться к определённой версии.
Сам Git является распределенной системой контроля версий (Distributed Version Control System, далее DVCS). В DVCS клиенты не просто скачивают снимок всех файлов (состояние файлов на определённый момент времени) – они полностью копируют репозиторий. В этом случае, если один из серверов, через который разработчики обменивались данными, умрёт, любой клиентский репозиторий может быть скопирован на другой сервер для продолжения работы. Каждая копия репозитория является полным бэкапом всех данных.
Всем привет! Меня зовут Маша, и я Golang Backend Developer в компании Ozon. В этой статье я хотела бы поговорить о теме, так или иначе объединяющую все сферы нашего любимого мира IT. А именно — VCS Git.
Без системы контроля версий сейчас невозможно представить ни один проект. Это оплот любой кодовой базы, это мощнейший инструмент, с помощью которого эту базу можно изменять и отслеживать. Однако нередко чистотой истории изменений пренебрегают, полагаясь на старое доброе «И так сойдёт!», абсолютно игнорируя при этом сложность понимания и поддержки такой истории в будущем.
В этой статье я рассмотрю причины такого подхода, его недостатки, а также способы решения проблем, к которым он приводит. Я выделила несколько основных принципов, которые помогут прийти к чистой истории изменений проекта. Давайте же вместе исследуем эту темную, неизведанную сторону Git, которая нам в этом поможет.
Сегодня мы с радостью объявляем о новом релизе GitLab 16.1 с полностью изменившимся опытом навигации, GitLab Dedicated в общем доступе, визуализацией ресурсов Kubernetes, аутентификацией через сервисные аккаунты и многими другими фичами!
В статье я рассказываю, как в репозитории веб-сервиса «GitHub» можно переименовать сразу множество файлов одним коммитом.
У меня небольшой учебный репозиторий, с которым я работаю через веб-интерфейс. Через веб-интерфейс можно переименовывать файлы по одиночке, но иногда появляется необходимость переименовать сразу много файлов по одному и тому же принципу. Операция переименования состоит из нескольких этапов: клонирование репозитория на свой компьютер, написание скрипта для переименования множества файлов и запуск переименования, создание коммита и отправка изменений в оригинальный репозиторий на «GitHub».
По ходу дела я касаюсь работы с «Git» из командной строки, немного разбираю настройку Git-репозитория, пишу скрипт на языке PowerShell, работаю с регулярными выражениями и создаю гранулированный токен доступа в «GitHub».
Хранилища кода являются неотъемлемой частью современной разработки ПО. Они позволяют командам разработчиков управлять своим кодом, устанавливать версии и совершенствовать процесс разработки. Современные реалии внесли свои коррективы в работу, заставив в короткие сроки перейти на российские аналоги ПО.
В статье Центр цифровой трансформации РТ рассказывает о своем опыте импортозамещения платформы Bitbucket на отечественный софт, о выявленных плюсах и минусах, и о сделанных выводах.
Привет, Хабр, Я QA инженер в команде интеграции. Моя команда интегрирует локальных платежных провайдеров, чтобы наши клиенты могли заводить и выводить деньги. Из-за большого количество провайдеров у нас возникла проблема с деплоем сервисов на нужную ветку для тестирования. В этой статье, я представлю наше решение этой проблемы в виде Slack бота и не только. Надеюсь, кому-то это тоже поможет решить подобную проблему.
Разработчикам несомненно надо уметь работать с Git и делать это через командную строку. Иногда бывают ситуации, когда просто нет возможности установить на машину альтернативный инструмент с графическим интерфейсом. При этом некоторые задачи удобнее выполнять в специализированных приложениях, и никто не запрещает использовать GUI в собственных проектах.
В этой статье собраны самые популярные графические интерфейсы Git. Есть как бесплатные инструменты с открытым исходным кодом, так и проприетарные решения с дорогими лицензиями. Некоторыми клиентами из статьи я пользовался сам, чтобы в итоге выбрать удобный вариант для своих задач.
В какой ветке вести разработку? Из какой ветки деплоить на PROD? В какой ветке чинить багу, выявленную на IFT? Многие команды закрыли для себя этот вопрос, но для многих он остаётся открытым.
Этот пост не будет содержать каких-то особых ноу-хау и киллер-фич. В нём я расскажу наиболее простую и понятную (лично мне) практику релизных циклов на основе git flow. И постараюсь объяснить каждое своё решение и каждый подход.
Доброе время суток, уважаемое Хабр коммьюнити. В этой публикации я хотел бы показать несколько известных мне подходов к версионной миграции данных в контексте DTO. Примеры будут продемонстрированы на языке Java.
Привет, Хабр! Сегодня поговорим об опыте работы Cбера с Helm. Дело в том, что в Сбере широко используется контейнерная платформа OpenShift от RedHat, которая дополняет Kubernetes собственными возможностями, упрощает деятельность по разработке и сопровождению сервисов в промышленной эксплуатации. Платформа отличная, но у неё есть ряд проблем, о которых поговорим ниже. А справиться с ними можно при помощи Helm. О том, как нам помог этот пакетный менеджер, — читайте под катом.
Поднялся вопрос стандартизации коммитов в команде. До этого были такие правила, мы пишем номер задачи и через тире описание того, что было сделано кратко. Номер задачи берется из номера issue. Например: #1 - реализован функционал сборки прода. Но, это надоело и стало как-то неудобно, когда у нас есть четкое деление задач на фиксы, фичи и так далее.
Нашли Conventional Commits и попробовали его на тестовом репозитории, понравилось. Решили внедрить это в команду, но столкнулись с тем, что люди не всегда делают коммиты правильно, а значит нужна какая-то валидация.
В нашей команде принято по максимуму IDE и его возможности. То есть, коммиты мы делаем не через консоль, а через встроенные утилиты. Поэтому, сразу пошли искать плагины, которые есть в PHPStorm и нашли вот эти 2 важных плагина: Conventional Commit и Git Commit Template. После их установки видим новые кнопки в окне коммита:
Существуют разные способы совместной работы над исходным кодом проекта. Так получилось, что сначала я познакомился с тем, как работать с командой «git push», посылая свои изменения в удаленный репозиторий, и как создать на сайте «GitHub» форк для отправки из него запроса на принятие изменений («pull request», сокращенно «PR»). И только после этого я узнал о том, что существует способ обмена изменениями в код с помощью файлов-патчей.
В этой статье я экспериментирую с командой «git diff», создаю тестовый проект и файл-патч из него в программах-оболочках «PowerShell» версии 7 и «Git Bash». Клонирую проект и применяю полученный файл-патч с помощью команды «git apply».
В последней части статьи я показываю, как можно применить программу «Git» для создания файла-патча с изменением в исходный код известного веб-приложения «WordPress». В конце этого примера я создаю сообщение об ошибке (ticket) в системе управления проектом «WordPress» и прикладываю к нему свой файл-патч.
