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

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

Существует прекрасная общепринятая схема работы с контролем версий — у каждого разработчика своя копия проекта, коммиты в ветки, мерж, test‑сервер, pre‑prod, CI/CD.
Ещё несколько лет назад разговоры об iPad как полноценном инструменте разработчика воспринимались скептически. Машинка для Netflix, блокнот для набросков, планшет для презентаций — но только не рабочая среда для написания и деплоя кода. У этого скептицизма были основания: iPadOS долго не имела нормальной многозадачности, инструментов для работы с серверами почти не существовало, а необходимость постоянно переключаться между приложениями делала любой серьёзный рабочий процесс мучительным.
Сегодня картина изменилась кардинально, и сразу по двум причинам, которые усиливают друг друга.
Несколько месяцев назад я делал плановую проверку кодовой базы на одном из проектов и нашёл обфусцированный код в файле vite.config.js. Он был на той же строке что и закрывающий };, но сдвинут вправо на несколько сотен пробелов — туда, куда ни один diff-вьюер не прокрутит и ни один редактор не покажет без горизонтального скролла.
Я пошёл смотреть через git log — какой коммит это принёс. Оказался merge-коммит. Не обычный коммит в ветке — именно merge. И вот тут началось интересное.
Эпоха комфортного программирования подходит к концу. Пока программисты ваших конкурентов потягивают тыквенный латте и вяло ждут окончания медленных пайплайнов, GitCrab превращает ваш репозиторий в суровую экосистему, где выживает только сильнейший.
Большинство CI/CD инструментов помогают вам деплоить. GitCrab заставляет вас бороться.
Git стал таким же привычным явлением, как электричество в розетке. Его можно использовать совершенно по-разному — он либо сделает вашу жизнь удобнее, либо причинит боль и доставит кучу проблем.

Я веду несколько проектов параллельно. Как и многие, прошёл путь от Trello через Notion к Linear. Каждый раз одна и та же история: первую неделю всё красиво, потом доска превращается в кладбище карточек, которые никто не двигает. Потому что переключаться между кодом и трекером — это отдельная работа, на которую нет ни времени, ни желания.
В какой-то момент я понял: проблема не в инструменте. Проблема в том, что трекер — это отдельное окно. Отдельный контекст. Отдельное усилие.
В вашем ядре сейчас есть баги, которые не найдут в течение многих лет. Я знаю это, потому что проанализировала 125 183 из них, каждая в 20-летней git-истории ядра Linux помечена прослеживаемым тегом Fixes:.
Средний баг ядра существует 2,1 года. А некоторые подсистемы намного хуже: драйверы CAN‑шины [шины сети контроллеров] — в среднем 4,2 года, работа с сетью SCTP — 4,0 года. Самый долгоживущий баг в моём наборе данных — переполнение буфера в ethtool — сохранялся в ядре Читать полностью »