GitHub *

Как завести свой Git на небольшом VPS и не превратить его обслуживание в отдельный проект? Показываю свой путь с Gitea: настройку пользователей и SSH, перенос репозиториев из GitHub и подключение CI через Gitea Actions. А затем проверяю бэкап делом - восстанавливаю из внешней копии. С командами, ошибками и оговорками по безопасности - для личных проектов и небольших команд.

Привет! В предыдущей статье https://habr.com/ru/articles/1042328/ я рассказал о математической оценке коэффициента шума (КШ) методом отношения сигнал-шум. Сегодня перейдем от теории к практике - к автоматизации радиоизмерений. Покажу, как построить гибкую систему управления измерительными приборами на Python, которая не боится разношёрстного парка оборудования в лаборатории.

Всем привет!

Почти каждый, кто работал с Git больше пары недель, хоть раз сталкивался с одной и той же путаницей: почему git add — это не сохранение, зачем нужен какой‑то отдельный индекс, если есть коммит, откуда вообще берутся конфликты при мерже, если мы просто оба поправили один файл. И почему иногда git status показывает файл как изменённый, хотя вы точно ничего не трогали.

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

В этой статье cначала покажем, как Git на самом деле хранит файлы и их изменения, что такое индекс и почему он существует отдельно от рабочей директории и коммитов. Далее — как устроены ветки на уровне данных, а не только как указатель текущей линии разработки. После этого разберём, как Git определяет, какие именно строки поменялись, и как из этого механизма следует слияние т.е merge и, самое главное, конфликты при слиянии.

Изучив модель, пройдёмся по основным командам работы с файлами: add, rm, mv, restore, diff, log, stash, работу с .gitignore и с большими файлами.

А в конце мы вам покажем, как это всё применяется на практике.

Последние месяцы я рецензирую научный софт для JOSS, Journal of Open Source Software. Это настоящий рецензируемый журнал с редколлегией, только статья в нём короткая, около тысячи слов, а главный объект ревью - репозиторий с кодом. Ревью идёт в публичном GitHub-треде под именем рецензента, и весь процесс от заявки до вердикта открыт любому желающему. Я инженер, не учёный: ни PhD, ни публикационного списка у меня нет.

README редко ломается в один момент.

Обычно он просто постепенно перестаёт соответствовать проекту: переименовали команду, перенесли файл, удалили .env.example, сменили package manager — а инструкция осталась прежней.

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

Мне стало интересно: можно ли автоматически находить хотя бы часть таких расхождений, не выполняя команды из README и не отправляя исходный код в LLM?

Так появился RealityLint — open‑source CLI, который статически сверяет проверяемые утверждения из README с реальным состоянием репозитория.

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

На протяжении многих лет использования git я выявил для себя одну серьезную проблему, которую этот инструмент не дает возможности разрешить удобным способом. Я назвал эту проблему “проблемой длинного прыжка”. Суть такова: у вас есть старая залежавшаяся ветка, которая отстает от main-ветки на сотни и тысячи коммитов. Задача - обновить эту старую ветку до свежего main. Все усугубляется тем, что у вас тяжеловесный репозиторий: гигабайты, десятки или сотни гигабайт.

В GitHub прямо сейчас есть десятки тысяч репозиториев, которые распространяют вирусы. Любой из вас может найти такие репозитории и для этого вам не нужны какие-то специальные знания. Вам достаточно воспользоваться обычным поиском на сайте гитхаба.

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

Почему они за 2 года не решили эту проблему?

В Linux с давних пор киллерфичей была возможность централизованного управления (поиск, установка, удаление, обновление, разрешение зависимостей) софтом при помощи пакетных менеджеров (apt, yum, pacman и т.д.).

Однако существует большое количество интересных и полезных программ, которые распространяются разработчиками либо через собственный сайт, либо через релизы на GitHub, либо в виде статического бинарника, либо вообще исключительно в исходниках (при этом под той же Windows у того же проекта часто есть нормальный инсталлятор с автопроверкой обновлений).

Когда таких программ накапливается достаточное количество, их сопровождение превращается в настоящий цирк.

Я решил для себя этот вопрос создав собственный apt репозиторий.

Обнаружил что в скриптах сборки время от времени подвисает node-pre-gyp, который скачивает прекомпилированные бинарные библиотеки.

Начал выяснять откуда он их пытается скачать - оказывается, github.

Проверил github без VPN - оказывается, релизы с release-assets.githubusercontent.com не скачиваются. Причем из консоли еще скачиваются, из браузера не открываются. Вероятно, иногда и из консоли блокируется.

То есть частичная блокировка гитхаба все еще продолжается. Замечу, что он используется в огромном числе скриптов сборки огромного числа продуктов, и заменить его на зеркала централизовано нельзя, да и далеко не всегда известно, какой именно файл какая именно программа будет скачиваться.

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

В предыдущих статьях мы разобрались, c Linux и Bash.

Следующая ступенька — Git.

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

На самом деле сегодня Git используют практически все инженеры, работающие с инфраструктурой. В Git хранят не только исходный код приложений, но и Dockerfile, Kubernetes-манифесты, Terraform-конфигурации, Ansible Playbook, Bash-скрипты и CI/CD-конвейеры.

Фактически Git стал центральной точкой любого современного проекта.

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

За свои 17+ лет в активной разработке я встречал много проблем, но одна преследовала меня постоянно: JSON. Нет, с самим форматом все ок, но вот с его чтением — не все норм.

Когда я только начинал работать с PHP, я списывал это на скриптовость языка. Отчасти из‑за этого я даже поменял стек. Но когда приходили по‑настоящему большие файлы, это всегда было больно. Иногда — очень. Был проект, где мы ждали не обработку информации бизнес‑логикой, а банального парсинга. Файлы доходили до десятков гигабайт и не всегда влезали в оперативку. Тогда я и заработал себе персональный todo — разобраться с этим раз и навсегда.

Сейчас, находясь в поиске новых возможностей, я решил вспомнить эту старую боль. Я уже давно не PHP‑разработчик, но проблема в индустрии всё та же. Объемы данных растут, требования тоже, а воз и ныне там. Нет, есть море крутых решений. Даже тут, на Хабре. Но для меня всё не то.

Мне нужно решение, а не костыль. То есть: никакой кодогенерации и никаких JIT (я не противник JIT, просто не хочу тянуть эту сложность).

Я ступил на тонкий лед: в Go есть классная штука — пакет unsafe. Почему классная? Потому что она позволяет обойти тяжелые ненужные проверки. Плюс побитовые операции для ускорения всего, до чего только смогли дотянуться руки. Пока изучал чужие парсеры, столкнулся с обманом в репозиториях, подкручиванием статистики (куда же без него?) и перекладыванием ответственности (и аллокаций) на сторону разработчиков.

npm install — такая привычная многим из читателей команда, но за последние пару месяцев она обернулась сущим кошмаром для инженеров по безопасности. И ладно бы всё сводилось к проверке 5 пакетов из package.json, но у каждой зависимости по 10 своих зависимостей, а у тех ещё по 10. В итоге мы тянем 2000, а не 5 пакетов, и тут, кажется, уже руками не проверишь. И именно на этой боли всех безопасников, поддерживающих JS-проекты, сыграла команда TeamPCP. В этой статье я хочу подробно, от А до Я, разобраться, в чём опасность, почему так произошло и как от этого защититься.

Привет, Хабр!

Конфликты в Git заставляют немного паниковать, пока не научишься понимать, что именно происходит. Почему возник конфликт? Что я сделал не так? Не потеряю ли я свои изменения? И как теперь продолжить работу?

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

Что такое Git-конфликт?

Во-первых, Git позволяет нам, разработчикам, независимо работать над одним проектом в отдельных ветках. Пока изменения затрагивают разные файлы или разные независимые участки одного файла, Git обычно способен объединить их автоматически. Но что произойдет, если они затронут одинаковый участок файла? Давайте разберемся.

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

Как README превращается в PR-актив: структура, нарратив, quickstart

Когда кто-то впервые сталкивается с техническим продуктом, он открывает репозиторий. Инфлюенс, которому прислали питч, инвестор после дежурного «посмотрите наш продукт» делает то же самое, и разработчик, который наткнулся на тред в X, идёт туда же. Репозиторий - первая точка касания для аудитории с реальным весом: инженеры, тимлиды, CTO ранних стартапов, контрибьюторы в опенсорс. Они формируют репутацию инструмента до того, как о нём напишут медиа, их мнение распространяется быстрее любого пресс-релиза.

Что будет, если взять один HTML-файл, браузер, localStorage и git-хостинг с CRUD API? Получится мессенджер. Без backend, базы данных, регистрации, npm и WebSocket. В статье показываю, как устроен Macaroni Messenger: хранение сообщений в .macaroni/, outbox, git-agnostic adapters, storage branch, plugin API и опциональное шифрование.

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

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

Что он обещает? Идея простая — скилл указывает нейронке говорить, как пещерный человек, убирать артикли, говорить коротко и думать лаконично. На первых строках README обещается экономия до 75%. При этом без потери качества!

Но работает ли все это на самом деле? Ведь 75 000 звёзд на репозитории не могут ошибаться?