Git *

Статья о том, какие неочевидные вещи можно узнать о вас из логов гита. Методы ниже не бьют на 100%, но «щито поделать, десу».

Собрали гайд по работе с Git для новичков. 

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

Сохраняйте и пользуйтесь.

Поиск по коду — одна из тех функций, ценность которых ощущается мгновенно. Она либо есть и экономит часы, либо её нет — и ты начинаешь открывать файлы вручную, клонировать репозиторий, запускать find или средства своей IDE и вспоминать «где же это было».
Мы добавили в GitVerse поиск по коду в репозиториях. и сделали это быстро. Не потому что «срезали углы», а потому что опирались на инструмент, который десятилетиями решает задачу поиска по коду внутри Git: git grep. Пока другие поднимают тяжёлые поисковые платформы, возводят кластеры, строят индексаторы, мы выбрали простое и проверенное решение, которое работает прямо сейчас.

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

Привет, меня зовут Макс Мартынов и я ведущий разработчик в Атвинте. В этой статье расскажу про наш подход к Git workflow, в котором баги одной фичи не блокируют деплой другой. Существует множество подходов и наш, конечно, не единственно верный.

Всем привет!

Если вы работаете с Git относительно недавно, почти наверняка у вас возникала потребность в отмене коммита. И, что печально, вы быстро поняли, что простого "откатить все назад" нет.

Где-то советуют git reset, где-то - git revert, а в третьих и вовсе пишется про checkout. По тому же правилу летят restore, amend, reflog и куча технологических формулировок, требующих знания git и после которых становится только сложнее, нежели понятнее.

На самом деле все это объясняется: под словами "отменить commit" можно иметь в виду совершенно разные действия, и мы разберем, для каких случаев, какая команда подходит.

Статья Яна Уитлока о том, почему он не может отказаться от Magit, вдохновила меня поделиться своим взглядом на Magit. Этот текст посвящён перебазированию.

Я открыл лог Git. Вызвал Magit, привязанный к F3, и нажал lL. Первая l включает работу с логом, вторая — показывает его для всех локальных и отслеживаемых ими удалённых веток.

Git — это вызов, через который проходит каждый второй новичок в разработке. Ветки называются «asdasd», коммиты — «правки», а pull request пугает своей красной кнопкой. Знакомо?

Меня зовут Сергей Прощаев, я Tech Lead в FinTech и преподаватель на курсах в OTUS. В этой статье разбираем самое главное: как создавать ветки и почему их нельзя называть как попало, что писать в коммитах, как сделать pull request в лучших практиках команд разработки

гайд по синхронизации obsidian vault через git с шифрованием через git-crypt и gpg (заметки хранятся на сервере в зашифрованном виде, локально обычный markdown )

Недавно автор решил попробовать что-то помоделить в Blender. На данный момент он ещё только начинает осваиваться в 3D, но имеет небольшой опыт в разработке ПО, преимущественно с использованием Git, потому хотел бы и тут избежать версионирования проектов в духе "projectN_final5_20260305_fix3.blend", который подразумевается при "инкрементальном" сохранении.

На первый взгляд ничего сложного тут быть не должно: в Blender работа ведётся с набором точек-координат-чисел и их связей, настроек модификаторов, ссылок на текстуры и референсы и т.п.; потому всё это должно иметь некоторую стандартизированную структуру, возможно упакованную в ZIP-архив. Файл проекта .blend же является таким ZIP-архивом, ведь так? Распакуем его и просто занесём в Git? Неправильно!

В данном случае придётся прибегнуть к помощи фреймворка OpenUSD. Но для начала хотелось бы рассказать о том, какие проблемы он был изначально призван решить и какими ограничениями обладает.

На своем тг-канале я предлагаю подписчикам выбор, какую бредовую идею запилить следующей. На этот раз подписчики выбрали новый челлендж: сделать Git в Telegram. Чтобы можно было через бота инитить проекты, пушить файлы, коммитить — и всё это в публичном канале с тредами.

С практической точки зрения этот проект нахуй не нужен. Есть гитхаб, есть гитлаб, есть куча нормальных инструментов. Но как эксперимент — почему бы и нет? Чисто посмотреть, можно ли заставить Telegram работать как VCS.

Я тогда подумал: «Ну, бот на aiogram, база данных, пара команд — делов то))»

Словари, датаклассы и прочая е*атория

Когда я только начинал, первая мысль была: «Положу всё в JSON, на кой мне база данных?» Ну серьёзно, проектов мало, пользователей немного, файлы текстовые че заморачитватся.

Подергал JSON туда-сюда пару дней и понял: не варик.

Во-первых, конкурентный доступ. Два юзера одновременно коммитят — один из них перезаписывает файл другого. Во-вторых, целостность данных. Если бот упал в середине записи — JSON остаётся в невалидном состоянии. В-третьих, версионность. Хранить историю изменений в JSON — это просто перенести проблему из кода в структуру файла.

Короче, JSON — для конфигов, а не для данных, которые меняются каждую секунду.

Выбор пал на SQLite.

Почему:

Это перевод статьи с opensource.com, которая мне показалась особенно полезной и практичной, поэтому решил поделиться адаптированной версией для русскоязычной аудитории. Оригинал доступен по ссылке: https://opensource.com/article/22/10/docs-as-code

В статье разбирается подход Docs as Code — способ встроить документацию в процесс разработки так, чтобы она проходила через Git, ревью и автоматическую сборку вместе с кодом. Материал будет полезен разработчикам, тимлидам и тем, кто выстраивает инженерные процессы в команде.

Краткое пошаговое руководство, как настроить SSH‑подключение к GitHub: от создания ключа до проверки соединения. Подойдёт новичкам, которые хотят избавиться от постоянного ввода логина и пароля и безопасно работать с репозиториями

Как мы превратили стрессовые ручные релизы в предсказуемый one-click процесс с GitOps и автоматикой. 60+ модулей, аудиторы и регуляторика — в едином шаблоне, который масштабировался на 30+ сервисов. Без магии, но с инженерной дисциплиной

Разговор будет серьёзный. С 1 марта 2026 вся публичная информация для потребителя должна быть на русском — N 168-ФЗ. Пока что разработку это не касается, но стоит быть готовыми. Предлагаю договориться о словаре разработчиков Российской Федерации.

CLI-обёртка над git worktree на чистом Bash. Автоименование worktrees, централизованное хранение в ~/.git-wt/, копирование .env файлов, shell-автодополнение и поддержка AI-агентов через SKILL.md. Сделана для параллельной работы нескольких Claude Code / Cursor / Windsurf на одном репозитории, но полезна и для код-ревью, хотфиксов и тестирования. Ноль зависимостей, установка за 5 секунд.

git rebase это отличный способ сделать историю линейной и визуально красивой. Но для каждого коммита, у которого возникает конфликт, приходится его исправлять и делать git rebase --continue. В случае длинных веток таких остановок для исправления конфликтов может быть довольно много. В этой статье я расскажу про нестандартный метод, как можно исправить все эти конфликты разом, что позволяет сделать git rebase быстро и чисто механически.

Когда я прихожу в новый проект и провожу аудит, почти всегда вижу одну и ту же картину. Код аккуратный, линтеры строгие, CI настроен. Но стоит открыть разметку или конфиги — и начинается творческий беспорядок. Кто-то форматирует по одному, кто-то по другому, кто-то копирует куски из StackOverflow, не особо понимая синтаксис.

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

Со временем я перестал разделять «код» и «не код». Если файл участвует в работе продукта — он должен быть проверяемым. Автоматически. Без надежды на внимательность разработчика.

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

Flutter & GitLab CI/CD. Доставка мобильного приложения в Significa, TestFlight и Google Play

Привет! Меня зовут Данил Абдрафиков, я мобильный разработчик в компании TAGES. После успешной настройки сборки и подписания Flutter-приложений во второй части, остался последний, но не менее важный этап — дистрибуция приложения.

В современных условиях автоматизация деплоя на такие платформы, как Google Play, TestFlight и Significa, становится необходимостью. В этой статье мы разберем, как с помощью GitLab CI/CD настроить автоматическую отправку ваших приложений в магазины, чтобы вы могли сосредоточиться на разработке, а не на рутинных задачах.

Сложно поддерживать CI/CD, когда граф пайплайна в GitLab превращается в бесконечную «простыню», параллельные запуски terraform apply приводят к блокировкам, а для игнорирования некритичных ошибок приходится писать || true. 

Может показаться, что для решения этих проблем нужны «костыли» или переход на enterprise-лицензию. На деле же с ними помогут встроенные возможности GitLab CE. В статье разбираем неочевидные ключевые слова .gitlab-ci.yml, которые сэкономят вам время и нервы.

Unreal и Unity быстро превращают репозиторий в смесь кода, тяжёлых ассетов и командных привычек — и выбор VCS начинает влиять на работу каждый день. В статье сравниваются SVN и Git именно в контексте UE/Unity: блокировки файлов, права доступа, скорость, ветки и совместимость с CI/CD. Также разберем практические замечания по миграции и тому, как выстроить процесс так, чтобы он был понятен и разработчикам, и людям, которые живут в ассетах.