Git *

Leaquor.jl: Secret Scanning with Julia

Большинство инструментов для поиска секретов в Git-репозиториях страдают от одной серьёзной проблемы: их JSON-вывод часто кривой или трудночитаемый, что усложняет автоматизацию. Они неплохо находят утечки, но попытка использовать их вывод в CI-пайплайне или бэкенд-сервисе обычно превращается в борьбу с битыми данными или написание кастомных парсеров.

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

Грамотная работа с Git.

Бывает что работа идет в изолированные друг от друга контурах и исходный код – а это может быть не только код приложения, скрипты автоматизации но и чарты Helm, необходимо распространять в виде архива/бандла. В Git для этого уже есть подходящий функционал.

git archive — команда Git, которая создает архив файлов из репозитория, не включая служебные данные Git (например, директорию .git).

git bundle create — команда Git, которая создает "бандл" (bundle) — файл, содержащий историю изменений, коммиты и другие данные репозитория. Это полезно для передачи репозитория или его части без прямого доступа к удаленному серверу.

Разница с git archive:

• git archive создает архив файлов без истории Git.

• git bundle сохраняет историю коммитов, ветки и другие данные Git, что позволяет восстановить полный репозиторий.

Чтобы верифицировать git bundle, можно использовать команду git bundle verify. Она проверяет целостность бандла, его содержимое и совместимость с текущим репозиторием (если проверка выполняется в контексте существующего репозитория).

Проверка целостности бандла:
Выполните команду:

git bundle verify /путь/к/файлу.bundle

Пример использования в CI/CD. Заворачиваем команды Git в Makefile, затем таргеты Make можно вызывать вручную или из конвейера CI/CD:

# Variables
GIT_BRANCH := $(shell git rev-parse --abbrev-ref HEAD)
GIT_COMMIT := $(shell git rev-parse --short HEAD)

# Target: Create git archive
.PHONY: archive
archive:
	@echo "Creating git archive..."
	git archive --format=tar.gz --output=archive-$(GIT_BRANCH)-$(GIT_COMMIT).tar.gz HEAD
	@echo "Archive created: archive-$(GIT_BRANCH)-$(GIT_COMMIT).tar.gz"

# Target: Create git bundle
.PHONY: bundle
bundle:
	@echo "Creating git bundle..."
	git bundle create bundle-$(GIT_BRANCH)-$(GIT_COMMIT).bundle --all
	@echo "Bundle created: bundle-$(GIT_BRANCH)-$(GIT_COMMIT).bundle"

# Clean up generated files
.PHONY: clean
clean:
	@rm -f archive-*.tar.gz bundle-*.bundle

make archive
Creating git archive...
git archive --format=tar.gz --output=archive-main-e488a6b.tar.gz HEAD
Archive created: archive-main-e488a6b.tar.gz

make bundle
Creating git bundle...
git bundle create bundle-main-e488a6b.bundle --all
Enumerating objects: 126, done.
Counting objects: 100% (126/126), done.
Delta compression using up to 8 threads
Compressing objects: 100% (64/64), done.
Writing objects: 100% (126/126), 55.00 KiB | 5.50 MiB/s, done.
Total 126 (delta 66), reused 107 (delta 55), pack-reused 0
Bundle created: bundle-main-e488a6b.bundle

Для аналитики полезно конвертировать историю git в sqlite или duckdb. Для крупных проектов вроде k8s это может быть очень полезно:
git_duckdb.py

Обойдемся и без Terraform: внедряем GitOps-подход для виртуальных машин

Для работы с OpenStack удобно использовать Terraform. Хотя компания Hashicorp прекратила свою деятельность на территории России, нам все еще доступен open source-форк под говорящим названием OpenTofu. Он позволяет автоматизировать создание виртуальных машин на основе текстовых файлов конфигурации. Схема его работы примерно такая:

1. В GitOps-репозитории находятся terraform-файлы с описанием параметров виртуальных машин и DNS.

2. На основе этих файлов формируются конфигурации для новых ВМ.

3. Все изменения вносятся через pull request, а их корректность проверяется автоматическими запусками тестов в CI.

4. После слияния изменений CI запускает процесс приведения нового желаемого состояния репозитория к действительному.

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

В своей статье Кирилл Яшин рассказывает, как с нуля реализовать такой подход к виртуальным машинам, используя провайдеры для работы с OpenStack и DNS.

Не пишите ничего на Groovy.

Есть такой шутливый пост про разработку, называется no-code framework. «Лучший способ писать безопасные и надежные приложения. Ничего не пишите, и никуда не деплойте».

Нечто подобное, я мог бы написать про Groovy. Не пишите ничего на Groovy. Особенно пайплайны для Jenkins. Когда-то давно, когда в Jenkins еще не было декларативных пайплайнов, сторонние разработчики сделали плагин – Job DSL, благодаря, которому стало возможным писать джобы на Groovy. Хотя вернее будет назвать этот усечнный вариант языка – Jenkins Groovy.

Для человека у которого в руках молоток, любая проблема выглядит как гвоздь, а для разработчика, девопса или тестировщика, любая задача выглядит как пайплайн на Groovy. Все начинается с хорошей идеи вынести несколько функций в общую библиотеку, а заканчивается монструозной автоматизации, напоминающей машину Руба Голдберга.

Заканчивается это осознанием, того, что так больше жить нельзя, и нужно мигрировать на какой-то другой ci фреймворк. Jenkins здесь не причем – это отличный инструмент, который позволяет гибко настраивать CI под любые задачи, и масштабируется, в умелых руках до тысяч пайплайнов и дестков тысяч билдов.

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

Разработчики на Groovy встречаются крайне редко, а DevOps инженеры и тестировщики не смогут написать хороший, понятный, тестируемый код. Даже если они научатся, потом эти навыки негде будет применить, потому что за пределами Gradle, Jenkins и Jira, он, сейчас нигде не используется.

Если вам нужно шарить код в CI, то можно писать утилиты или автоматизацию на Python, Go, Bash и упаковывать это все в контейнеры.

Если вы хотите использовать Groovy для того, чтобы написать на нем свой кастомный workflow engine для Jenkins, то остановитесь и подумайте хорошо. Скорей всего это ошибка – все тоже самое можно реализовать с помощь скрипта на Bash или Python, который вызывается внутри декларативного pipe.

Если российские компании, которые написали миллионы строчек кода на Jenkins Groovy и на этом они сейчас теряют сотни тысяч человеко часов.

Решение этой проблемы не переезд на GitLab пайплайны – просто не пишите на Groovy. Если у вас меньше 200 разработчиков и не используется монорепозиторий, вам не нужен Bazel, просто не пишите Groovy.

Все что я написал про Groovy и Jenkins, можно применить к TeamCity и Kotlin DSL.

Мы так и не дождались альтернативы GitHub и GitLab. Gitea многим не нравится (в том числе и мне) из-за фронтеда, а от BitBucket, многим российским компаниям нужно будет отказываться в ближайшее время.

GitLab невероятно требователен до ресурсов и прихотлив в обслуживании. Это одна из архитектурных особенностей этого продукта. Community Edition сильно урезан именно там где это нужно больше всего – PR management. Развивать своими силами GitLab CE практически не реально.

Возможно в этом нет смысла, потому что возможно GitLab скоро продадут и сделают тоже самое, что Broadcom сделала с VMware.

Недавно на глаза попался Harness Open Source и на первый взгляд там есть все что нужно. И даже то чего у других нет: GitSpaces

Надежность – это главное для хостинга Git, и это лучше всего это проверить на практике:

docker run -d \
  -p 3000:3000 \
  -p 22:22 \
  -v /var/run/docker.sock:/var/run/docker.sock \
  -v /tmp/harness:/data \
  --name harness \
  --restart always \
  harness/harness

Импортируем с помощью кнопки, один из крупнейших Open Source проектов – ElasticSearch Kibana. 4 миллиона строчек кода импортируются из GitHub в Harness без всяких проблем за несколько минут. 3,8Гб JS собираются встроенным в Harness Drone CI без особых проблем.

Судя по тестам k6 один инстанс в докере, на нормальном железе может держать примерно 2000 тысячи пользователей. 2 виртуальные машины, объектное хранилище, баларансировщик нагрузки и нормальные бэкапы, может понадобится для того чтобы переехать из GitLab или BitBucket.

Лицензия Apache 2.0 поэтому то чего не хватает, можно допилить. Интересный проект.

Это задачка для DevOps-инженера: почему ArgoCD не расшифровывал секреты из Vault

Нашему DevOps-специалисту Антону нужно было развернуть helm-чарт для Airflow с использованием ArgoCD. Как известно, ArgoCD реализует концепцию GitOps и подразумевает хранение манифестов в репозитории. Но часть данных в values чувствительна, например пароль от базы данных PostgreSQL. Поэтому неплохо было бы вынести эти данные в хранилище секретов (в этом случае — HashiCorp Vault), чтобы скрыть информацию от лишних глаз.

Есть несколько способов подтянуть секреты из Vault в поды. Наиболее предпочтительный по ряду причин — vault-injector. В обычной ситуации Антон бы воспользовался им, но в случае с helm-чартом Airflow задача показалась непростой. Поэтому он решил воспользоваться менее предпочтительным, но точно рабочим (как думал Антон) вариантом с ArgoCD Vault Plugin.

Какая вылезла проблема

Когда секреты были добавлены в хранилище, а ArgoCD Application написан, Антон попытался развернуть его для теста. Вот примерный Application, с которым это делалось (весомая часть пропущена для компактности):

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
 name: airflow
 labels:
   app.kubernetes.io/name: airflow
   app.kubernetes.io/component: airflow
 namespace: argocd
 finalizers:
   - resources-finalizer.argocd.argoproj.io
spec:
 project: default
 destination:
   namespace: some-namespace
   name: cluster
 source:
   repoURL: "airflow_repo_url"
   targetRevision: "revision"
   chart: airflow
   plugin:
     name: argocd-vault-plugin-helm
     env:
       - name: HELM_VALUES
         value: |
             ...
             metadataConnection:
               user: user
               pass: <path:path/to/airflow/secrets#postgres_password>
               protocol: postgresql
               host: postgres.db.url
               port: 5432
               db: airflow_db
               sslmode: prefer
             ...
   
 syncPolicy:
   automated:
     prune: true
     selfHeal: true
   syncOptions:
     - Validate=true
     - CreateNamespace=true

Ничего необычного, за исключением прокидывания values прямо из Application и того самого секрета. А еще — компонент webserver отказался запускаться, ссылаясь на невозможность подключиться к базе данных. Хотя данные были абсолютно точно правильными.

В чем итоге была проблем и как Антон с ней справился, читайте в статье →

Зачем нужен code review

Выстроенный code review позволяет:
— найти баги и не пропустить их в прод. Конечно, в дополнение к статическому анализу с помощью настроенного pre-commit и тестам;
— выявить проблемы в архитектуре;
— сделать код единообразным. Спорный тезис, за единообразие должны отвечать линтеры и автоформатирование. Но code review помогает наладить те вещи, которые автоформатирование не тянут, например, именование переменных.

В долгосрочной перспективе постоянные code review:
— налаживают обратную связь между участниками;
— бустят уровень разработчиков, позволяя учиться на своих и чужих ошибках и давая обширную практику чтения чужого кода;
— помогают делиться знаниями о технологиях, вариантах решения проблем, возможных проблемах и самом проекте в команде;
— дают приток новых идей для улучшений в процессах, подходах и автоматизации;
— увеличивают децентрализацию знаний и bus factor.

В статье даны примеры хорошего и плохого code review, способы прокачки и вообще много разных нюансов.

Pre-commit — must have утилита любого проекта

Бывает, смотришь на код и сразу видно, что код плохой. Признаков может быть множество:
— разные куски кода по-разному отформатированы;
— импорты в файлах никак не структурированы;
— используются вперемешку синтаксис старых и новых версий питона;
— где-то видны зачатки использования типов, но не везде;
— где-то docstring есть, где-то нет;
Всё это характеризуется так: нет единого стиля в написании кода. Проблема становится особенно актуальной, когда над проектом трудится несколько разработчиков.

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

Для решения всех обозначенных проблем есть замечательная утилита — pre-commit. Один раз в конфиге прописываете, какие анализаторы кода нужно запускать, и далее при любом коммите они будут запускаться автоматически. С этого момента код будет опрятным и шелковистым. Вы просто не сможете сделать коммит, если у анализатора есть вопросики к коду.

В DevFM пишу о полезном для разработчика.

Для тех, кто хочет распилить монорепу на подмодули или уже сделал это. Задача со звёздочкой.

Дано: в репозитории около 50 подмодулей,  текущие ветки у них имеют разные названия. Джун Вася создал в каждом подмодуле новую ветку и внёс минорные правки. Чтобы провести ревью, миддл Серёжа получил Васины изменения, переключил ветки родительского репозитория и выполнил команду:

git submodule update --init --recursive

После ревью Вася пошёл исправлять замечания, а Серёжа вернулся к разработке своей фичи, вот только подмодули теперь в состоянии head detached.

Вопрос: как быстро подгорит у программистов из-за необходимости выставлять подмодули из состояния head detached в соответствующие feature-ветки, если процесс повторять?

Решение: использовать команду:

git submodule foreach --recursive 'git name-rev --name-only $sha1 | xargs git checkout'

По хешу команда найдёт указатель и на него переключится. Если есть несколько указателей для текущего коммита, будет выбрано имя ветки первое по алфавиту.
Если на текущий коммит подмодуля никакая ветка не указывает, получим head detached. Рекурсивно (если у подмодулей есть подмодули) тоже работает.

Ответ: так и живём.

Всем DevOps! Автоматизация проверки одобрений merge requests с помощью GitLab CI/CD и GitLab API — это классный способ без лишних затрат оптимизировать процесс управления кодом в вашей команде.

Наш DevOps-инженер Виктор рассказал, как он смог настроить approve rules для merge request в бесплатной версии GitLab CE.

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

💻 Если ещё не читали — тогда вам сюда!

Российские IT-компании готовятся к массовому отключению иностранных сервисов. Большинство привычных сервисов могу скоро просто отвалиться.

Все из-за санкций Минфина США, которые запрещают предоставление услуг в сфере программного обеспечения, IT-консультирования и проектирования на территории РФ.

Российские IT-конторы, соответственно, вынуждены искать бесплатные альтернативы с открытым кодом, на которые не распространяется запрет, а облачные хранилища теперь — только российские.

Кстати, как я смотрю, Сбер очень активно к этому готовился. У них и IDE на базе PyCharm— GIGA IDE, и гит-платформа GitVerse (полный аналог GitHub), и куча еще всего.

Я пока не особо тестил GIGA IDE, т.к. полностью перешел на майковский VS Code. Но он на базе комьюнити версии, только с разными плюшками и ИИ. А гит-платформа выглядит симпатично, ничего больше сказать не могу. Вероятно, всё это имеет очень хороший смысл, если трудишься полностью в их экосистеме.

В любом случае, молодцы, что предоставляют альтернативу.

Состоялся выпуск распределенной системы управления исходными текстами Git 2.46.

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

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

Исходный Код Git распространяется под лицензией GPLv2+.

По сравнению с прошлым выпуском в новую версию принято 746 изменений,
подготовленных при участии 96 разработчиков, из которых 31 впервые
участвуют в разработке.

Основные изменения:

• добавлена экспериментальная поддержка нового вида битовых карт — «pseudo‑merge reachability bitmap», в которых в отличие от структуры «reachability bitmap» данные о наборах объектов, имеющих отношение к коммитам, хранятся в привязке сразу к нескольким коммитам.

• реализован интерфейс командной строки для команды «git config», в котором вместо разрозненных опций для просмотра, переименования и удаления настроек и секций, таких как «‑get», «‑get‑all», «‑unset» и «‑remove‑section», предложен набор отдельных субкоманд.

• В команду git добавлена опция «‑no‑advice», отключающая все сообщения с рекомендациями и подсказками, что может оказаться полезным для предотвращения забивания лога лишней информацией при автоматизированном вызове git.

Состоялся выпуск распределенной системы управления исходными текстами Git 2.45.

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

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

Исходный Код Git распространяется под лицензией GPLv2+.

По сравнению с прошлым выпуском в новую версию Git принято 540 изменений, подготовленных при участии 96 мейнтейнеров проекта, из которых 35 впервые приняли участие в разработке.

Основные изменения:

• добавлена предварительная поддержка бэкенда "reftable" для эффективного хранения в репозитории ссылок на ветки и теги;

• предоставлены средства для обеспечения переносимости между идентификаторами объектов на базе хэшей SHA-1 и SHA-256;

• добавлена новая команда "git reflog list" для показа известных reflog-ов и соответствующих им ссылок на теги и ветки;

• в команде "git checkout -p" разрешено использовать символ "@" в качестве синонима имени "HEAD";

• предоставлена возможность определения альтернативных префиксов для вывода "git diff", отображаемых перед файловым путём;

• добавлен параметр core.commentString для определения строки-разделителя вместо символа "#" для игнорирования комментариев в сообщении для коммита.

Описание и комменты к код ревью

Есть один очень простой, но удивительно эффективный способ ускорить код ревью в команде и сделать этот процесс более приятным.

Выложив Pull Request, напиши к нему описание и оставь комментарии.

Вспомните свои ощущения, когда нужно поделать ревью. Лично я зачастую испытываю лень. Нужно открыть код, разобраться, какую задачу и каким способом он решает, составить собственное мнение, оставить комментарии... Можно устать, просто прочитав это предложение.

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

Не нужно растекаться словом по древу. Достаточно буквально 3-5 предложений. Читать огромную портянку текста тоже никто не захочет.

Сделав это, оставьте комментарии к самому коду. На что ревьюерам стоит обратить внимание? Где вы сомневаетесь в своём решении? Если есть доработки какого-то общего кода, то зачем они были сделаны?

Эти комментарии облегчат жизнь человеку, который будет смотреть ваш код. Помогите ему выделить главное из кода и заострить своё внимание именно на этом.

Больше интересного про жизнь в IT у меня в ТГ

[Отладка] git bisect

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

Возможно, ты уже сталкивался с ситуацией, когда нужно выяснить, после какого изменения в коде проекта появилась ошибка. Перебирать все коммиты вручную — не самое приятное занятие. Особенно, если ошибка была допущена давно. Именно здесь на помощь приходит git bisect.

Принцип работы git bisect основан на методе бинарного поиска. Тебе лишь нужно указать «хороший» коммит, в котором ошибка точно отсутствует, и «плохой» коммит, в котором ошибка уже есть. Git bisect автоматически проведет тебя через процесс бинарного поиска между этими двумя точками, поможет постепенно сузить круг «подозреваемых» и найти коммит, начиная с которого стал проявляться баг.

Использование git bisect начинается с запуска команды git bisect start, после чего ты помечаешь известные «хороший» и «плохой» коммиты соответствующими командами. Git затем предложит тебе проверить определенный коммит, и ты сообщишь, есть ли в нем данная ошибка. Процесс повторяется, пока не будет найден коммит, который послужил причиной появления бага.

Ссылка на доку здесь.

А тут мой тг-канал со свежими новостями из мира мобильной разработки.

Разработчики дистрибутива Arch Linux объявили о завершении миграции системы отслеживания ошибок на платформу GitLab и включении на обслуживающем проект сервере GitLab поддержки запросов на слияние (merge request). Модернизация системы отслеживания ошибок стала следующим шагом после перевода инфраструктуры для разработки пакетов с Subversion на Git и GitLab.

Старый интерфейс отслеживания ошибок в Arch Linux, основанный на платформе Flyspray, будет через какое-то время отключён, но доступ к старым записям планируют сохранить через размещение статической архивной копии сайта bugs.archlinux.org, в которой записи будут доступны по старым ссылкам.

В сообщениях об ошибках, разбиравшихся в процессе миграции, добавлены финальные комментарии, указывающие на новый адрес обсуждения в GitLab. Кнопки уведомления о проблемах, присутствующие на страницах пакетов, перенаправлены на новую систему. Процесс разбора сообщений о проблемах в Arch Linux останется прежним — первичный разбор сообщений осуществляют участники команды Bug Wranglers, после чего проблема перенаправляется для исправления соответствующим сопровождающим.

Источник: OpenNET.

После трёх месяцев разработки опубликован выпуск распределенной системы управления исходными текстами Git 2.43.

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

По сравнению с прошлым выпуском в версию Git 2.43 внесено и принято 464 изменения, подготовленные при участии 80 разработчиков, из которых 17 программистов впервые приняли участие в разработке, включая:

• в команду "git repack" добавлены опции "--filter" и "--filter-to", позволяющие выполнить переупаковку репозитория c учётом заданного фильтра объектов и при необходимости перенести в отдельное место объекты, не удовлетворяющие заданному фильтру;

• добавлена возможность работы с несколькими pack-файлами с информацией о недостижимых объектах ("cruft packs"), на которые в репозитории отсутствуют ссылки (не ссылаются ветки или теги);

• добавлено распознавание попыток выполнения двойной отмены коммита через "git revert" и учёт этого факта при формировании сообщения об отмене;

• Разрешено совместное использование опций "--rfc" и "--subject-prefix".

Источник: OpenNET.

Вышел релиз GitExtensions 4.2, инструмента с графическим интерфейсом для управления репозиториями git, умеющего интегрироваться в системное меню работы с файлами и, через плагины, в IDE (JetBrains, VSCode, MSVS). Код проекта написан на C# и распространяется под лицензией GPLv3.

Основные изменения:

• новый плагин интеграции с GitLab;

• в плагин JIRA добавлена поддержка токенов личного доступа;

• различные улучшения производительности;

• различные улучшения пользовательского интерфейса;

• улучшения в диалоговом окне журнала команд Git и в диалоговом окне «Rebase»;

• разрешено выполнение операции сохранения «Save as...» сразу для нескольких файлов;

• редактор теперь может перемещать строку вверх/вниз с помощью ALT + UP и ALT + DOWN;

• для OpenSSH реализовано выставление переменной окружения SSH_ASKPASS, если запрашивается пароль (требуется OpenSSH 8.4 или выше; не действует для более старых версий OpenSSH);

• обеспечена автоматическая установка GitExtensions в качестве редактора только в текущем окружении;

• разрешён сброс непроиндексированных изменений, не затрагивая промежуточные;

• более удобная обработка ошибок «Не удалось загрузить файл или сборку»;

• вертикальная табуляция (SHIFT + ENTER) теперь рассматривается как перевод строки;

• добавлена поддержка сборки GitExtensions для Windows на системах Arm64 (WoA), однако для этого требуется сборка вручную;

• для скриптов реализована опция "{HEAD}";

• для сборки теперь требуется .NET 6.0 Desktop Runtime v6.0.24 или новее;

• рекомендованная версия Git 2.42.

Источник: OpenNET.

Вышел новый стабильный выпуск системы управления проектами Trac 1.6 с поддержкой Python 3, предоставляющей web-интерфейс для работы с репозиториями Subversion и ​Git, встроенный Wiki, систему отслеживания ошибок и раздел планирования функциональности для новых версий. Код написан на языке Python и распространяется под лицензией BSD. Для хранения данных могут применяться СУБД SQLite, ​PostgreSQL и ​MySQL/MariaDB.

Trac придерживается минималистичного подхода к управлению проектом и позволяет автоматизировать типовые рутинные операции на уже сложившиеся в среде разработчиков процессы и правила. Встроенный wiki-движок даёт возможность использовать wiki-разметку в описаниях проблем, целей и коммитов. Поддерживается создание ссылок и организация связей между сообщениями об ошибках, задачами, изменениями в коде, файлами и wiki-страницами. Для отслеживания всех событий и активности в проекте предлагается интерфейс в виде шкалы времени.

В форме плагинов доступны модули для ведения новостных лент, создания дискуссионной площадки, проведения опросов, взаимодействия с различными системами непрерывной интеграции, генерации документации в Doxygen, управления загрузками, отправки уведомлений через ​Slack, поддержки Subversion и Mercurial.

Источник: OpenNET.

​​Как восстановить удалённый коммит в Git?

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

Потом понял, что закоммитил в мастер, а не в ветку с фичей. Поэтому сделал git reset --soft, чтобы удалить коммит, сохранив все изменённые файлы, и переключился в фича ветку. 

Если ветки сильно отличаются, то иногда приходится делать git clean -fxd, чтобы удалить все ненужные артефакты. И тут я понял, что удалил все свои изменения.

Повезло, что перед этим я закоммитил свои изменения, хотя коммит и был удалён. Ведь git позволяет восстановить удалённые коммиты. Для этого я сделал:

git reflog 

Нашёл в списке хэш моего коммита и перенёс из него все изменения в текущую ветку с помощью: git cherry-pick —no-commit <hash>

https://t.me/cherkashindev/105