#инструмент дня

Разобраться в концепциях Git просто не только лишь всем. Кто-то схватывает на лету, кто-то продирается сквозь ветки и листья документации. Кто-то забивает на всё, использует UI любимой IDE и ничего сложнее git pull origin master не разруливает.

Но насколько проще было бы, если появился бы симулятор происходящего под капотом. И ведь такой есть!

И называется он git-sim, вот так вот буквально.

Нужно разрулить конфликтный cherry-pick? Слить несколько веток вместе? Посмотреть последствия reset, stash, rebase? Да запросто! Просто вместо git команда пишете git-sim команда и наслаждаетесь.

Ах да, ссылки на примеры от авторов (много видео и иллюстраций): https://initialcommit.com/tools/git-sim

И на GitHub проекта: https://github.com/initialcommit-com/git-sim

Очень уютная штука. Надо бы процесс релиза в нашей команде в нём визуализировать к грядущей презентации.

#git #sim #tool #бородач

#расширение дня

А что, если история гита может быть представлена не в виде вертикального списка?

А что, если можно правильно использовать анимации, акцентируя внимание на изменениях?

А что, если можно не открывать интерфейс git blame на каждый чих?

Именно так подумал Родриго Помбо и нафигачил прекрасное расширение для Visual Studio Code: Git File History.

Принцип действия понятен по виде, устанавливайте: https://marketplace.visualstudio.com/items?itemName=pomber.git-file-history

Всем git, котаны!

P. S. вы же в курсе, что устанавливать расширения можно из консоли?

Как-то так:

code --install-extension pomber.git-file-history

Если команда code недоступна, решение тут.

#git #history #vscode

#инструмент дня

Разобраться в концепциях Git просто не только лишь всем. Кто-то схватывает на лету, кто-то продирается сквозь ветки и листья документации. Кто-то забивает на всё, использует UI любимой IDE и ничего сложнее git pull origin master не разруливает.

Но насколько проще было бы, если появился бы симулятор происходящего под капотом. И ведь такой есть!

И называется он git-sim, вот так вот буквально.

Нужно разрулить конфликтный cherry-pick? Слить несколько веток вместе? Посмотреть последствия reset, stash, rebase? Да запросто! Просто вместо git команда пишете git-sim команда и наслаждаетесь.

Ах да, ссылки на примеры от авторов (много видео и иллюстраций): https://initialcommit.com/tools/git-sim

И на GitHub проекта: https://github.com/initialcommit-com/git-sim

Очень уютная штука. Надо бы процесс релиза в нашей команде в нём визуализировать к грядущей презентации.

#git #sim #tool #бородач

#инструмент дня

Вот как ты, котан, ищешь недавний баг в проекте?

Выкатываешься куда-нибудь, тестируешь, откатываешь последний коммит, да?

А что если баг оказался хитрее, обошел тесты и уже сидит на проде, ножками качает?

Тут в дело вступает встроенный в git инструмент бинарного поиска: git bisect. Принцип прост: помечаем заведомо плохой коммит или тег (последний) и заведомо хороший (ну, за сутки до бага):

$ git bisect start
$ git bisect bad # Current is bad
$ git bisect good v2.6.13-rc2

После чего bisect выберет средний коммит из этих двух. Теперь нужно собрать проект и протестировать.

Если эта версия работает хорошо, сообщаем bisect об этом: git bisect good. Ну или bad, если нет. И продолжаем; снова случится checkout коммита посередине.

Можно искать не только баги, но и любое изменение в коде. Так что вместо меток good и bad есть ещё old и new.

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

#git #bisect #бородач

#фишка дня

Продолбался весь день с подготовкой релиза. С cherry-pick-ами нужных коммитов. Шутки про черрипики точёны оставьте себе.

В чём же проблема?

А в том, что наша команда работает по trunk-модели. Всё сливается в мастер, мастер автоматически релизится как Latest-версия продукта и отправляется в тестирование.

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

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

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

Для этого реализуются различные feature-флаги и прочие условные условности для разделения потоков пользователей продукта по фичам.

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

Плохо когда вы забыли о гигиене и смешали коммиты от двух фичей — свободной к релизу и нестабильной. Или когда не засквошили PR-коммит (мой случай).

Тогда выборка черри-пиков может быть не самым приятным занятием. А грязные черри-пики штука очень неприятная.

Так вот, про что же фишка дня? А вот про то, что в процессе я выяснил: совсем не обязательно делать checkout коммита по его хэшу, можно по сообщению! Буквально:

git checkout ':/add multiselect to ui kit'

Причём, сообщение не надо вспоминать полностью!

В итоге, git выберет ближайший к вам такой коммит. Уютно!

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

#git #til #commit

#заметка дня

Чуть выше я описывал процесс подготовки релиза из транка и мучения с черрипиками: https://t.me/htmlshit/2318

Но что делать, если git cherry-pick прошёл успешно, а тесты падают? В рабочем пылу можно успеть выбрать не один десяток коммитов (не надо так, к слову) и какой-нибудь окажется зависим от другого. Например, импортов нужных ещё нет.

Очень просто! Используем git revert и указываем нужный коммит. В случае конфликтов команды те же, что и у черрипиков.

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

#git #release #trunk #cherrypick

#расширение дня

А что, если история гита может быть представлена не в виде вертикального списка?

А что, если можно правильно использовать анимации, акцентируя внимание на изменениях?

А что, если можно не открывать интерфейс git blame на каждый чих?

Именно так подумал Родриго Помбо и нафигачил прекрасное расширение для Visual Studio Code: Git File History.

Принцип действия понятен по виде, устанавливайте: https://marketplace.visualstudio.com/items?itemName=pomber.git-file-history

Всем git, котаны!

P. S. вы же в курсе, что устанавливать расширения можно из консоли?

Как-то так:

code --install-extension pomber.git-file-history

Если команда code недоступна, решение тут.

#git #history #vscode #бородач

#фишка дня

Продолбался весь день с подготовкой релиза. С cherry-pick-ами нужных коммитов. Шутки про черрипики точёны оставьте себе.

В чём же проблема?

А в том, что наша команда работает по trunk-модели. Всё сливается в мастер, мастер автоматически релизится как Latest-версия продукта и отправляется в тестирование.

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

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

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

Для этого реализуются различные feature-флаги и прочие условные условности для разделения потоков пользователей продукта по фичам.

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

Плохо когда вы забыли о гигиене и смешали коммиты от двух фичей — свободной к релизу и нестабильной. Или когда не засквошили PR-коммит (мой случай).

Тогда выборка черри-пиков может быть не самым приятным занятием. А грязные черри-пики штука очень неприятная.

Так вот, про что же фишка дня? А вот про то, что в процессе я выяснил: совсем не обязательно делать checkout коммита по его хэшу, можно по сообщению! Буквально:

git checkout ':/add multiselect to ui kit'

Причём, сообщение не надо вспоминать полностью!

В итоге, git выберет ближайший к вам такой коммит. Уютно!

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

#git #til #commit #бородач

#заметка дня

Ну что, воспользовался git reset --hard и грохнул половину репозитория, потому что не до конца понимаешь, как оно работает?

«Присаживайся поудобнее и не паникуй», — сказал себе я вчера, грохнув два дня работы моей жены.

Всё, что нам нужно знать в данный момент — что Git писали не идиоты.

Итак, в моём случае я сделал git add :/, чтобы добавить все файлы из каталога. Потом понял, что ошибся, что мне нужны не все, и бахнул git reset --hard.

...и обнаружил, что пара каталогов того. Пропали.

Хороший вопрос, конечно, какого хера Git это делает, но если подумать, то с точки зрения системы контроля версий-то всё ок. Потому проблема на стороне пользователя.

К счастью, Git на каждый чих строит индекс. И обладает средствами работы с этим самым индексом. Включая работу с файлами.

Для этого встроена утилита, название которой удивительно знакомо линуксоидам: git fsck. Что буквально расшифровывается как git file system check.

И вот она-то нам и нужна. Пишем git fsck --lost-found и все наши файлы из предыдущей версии индекса, которые не попали в текущее состояние Git, оказываются в каталоге .git/lost-found/

Да, они там лежат проименованные как хэши, но кого это когда останавливало.

Дальше дело за малым: просмотреть файлы и восстановить.

Мы восстановили все HTML/CSS/JS и даже картинки (с картинками просто: обращайте внимание на бинарные заголовки, там пишется формат).

Но, конечно, используйте мозг почаще. И делайте резервные копии. Тоже почаще.

#git #lost #recover

#инструмент дня

Всё ещё испытываете проблемы с ветками в Git?

Not anymore!

Только сейчас открывая ссылку https://learngitbranching.js.org/ на вашем компьютере, вы получаете уникальную возможность научиться ветвлениям и слияниям в любимой системе контроля кода.

Или вы любите Mercurial? 🤔

#git #education #бородач

#инструмент дня

Как часто вы произносите “ой”, работая с Git? Или, того хуже, “упс”? Не говорю уж про “бля”…

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

Так вот, если Git это бесконечный undo для ваших проектов, то ugit — это undo для Git!

Ссылка: https://github.com/Bhupesh-V/ugit

КДПВ говорит сама за себя.

#git #бородач

#инструмент дня

Разобраться в концепциях Git просто не только лишь всем. Кто-то схватывает на лету, кто-то продирается сквозь ветки и листья документации. Кто-то забивает на всё, использует UI любимой IDE и ничего сложнее git pull origin master не разруливает.

Но насколько проще было бы, если появился бы симулятор происходящего под капотом. И ведь такой есть!

И называется он git-sim, вот так вот буквально.

Нужно разрулить конфликтный cherry-pick? Слить несколько веток вместе? Посмотреть последствия reset, stash, rebase? Да запросто! Просто вместо git команда пишете git-sim команда и наслаждаетесь.

Ах да, ссылки на примеры от авторов (много видео и иллюстраций): https://initialcommit.com/tools/git-sim

И на GitHub проекта: https://github.com/initialcommit-com/git-sim

Очень уютная штука. Надо бы процесс релиза в нашей команде в нём визуализировать к грядущей презентации.

#git #sim #tool #бородач

#инструмент дня

Вот как ты, котан, ищешь недавний баг в проекте?

Выкатываешься куда-нибудь, тестируешь, откатываешь последний коммит, да?

А что если баг оказался хитрее, обошел тесты и уже сидит на проде, ножками качает?

Тут в дело вступает встроенный в git инструмент бинарного поиска: git bisect. Принцип прост: помечаем заведомо плохой коммит или тег (последний) и заведомо хороший (ну, за сутки до бага):

$ git bisect start
$ git bisect bad # Current is bad
$ git bisect good v2.6.13-rc2

После чего bisect выберет средний коммит из этих двух. Теперь нужно собрать проект и протестировать.

Если эта версия работает хорошо, сообщаем bisect об этом: git bisect good. Ну или bad, если нет. И продолжаем; снова случится checkout коммита посередине.

Можно искать не только баги, но и любое изменение в коде. Так что вместо меток good и bad есть ещё old и new.

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

#git #bisect #бородач

#расширение дня

А что, если история гита может быть представлена не в виде вертикального списка?

А что, если можно правильно использовать анимации, акцентируя внимание на изменениях?

А что, если можно не открывать интерфейс git blame на каждый чих?

Именно так подумал Родриго Помбо и нафигачил прекрасное расширение для Visual Studio Code: Git File History.

Принцип действия понятен по виде, устанавливайте: https://marketplace.visualstudio.com/items?itemName=pomber.git-file-history

Всем git, котаны!

P. S. вы же в курсе, что устанавливать расширения можно из консоли?

Как-то так:

code --install-extension pomber.git-file-history

Если команда code недоступна, решение тут.

#git #history #vscode #бородач

#фишка дня

Надоело читать это: «To push the current branch and set the remote as upstream, use
git push --set-upstream origin fix/bug-1359»?

А всё потому что git на сервере не знает ничего о ветках на вашей машине. Нужно явно указать: «Хочу создать ветку на удаленном сервере с указанным названием и связать её с локальной». Названия даже могут отличаться, но чаще всего — совпадают. Ну, у меня, во всяком случае.

Поэтому, глядите чо: https://git-scm.com/docs/git-config#Documentation/git-config.txt-pushautoSetupRemote

Ну или просто взгляните на КДПВ.

Завезли с версии 2.37.0, так что проверьте сначала. Спасибо за уточнение подписчику :)

#git #remote #бородач

#фишка дня

Надоело искать гит-бранчи в бесконечном их списке в консоли?

Это всё потому что они сортируются по алфавиту. Что вообще далеко не всегда удобно. Точнее, это удобно только когда название ветки начинается с номера тикета.

Но, опять же, а если проектов несколько?..

Решение очевидно: сортировать бранчи по дате изменения!

Для чего нужен вот этот конфиг:

git config --global branch.sort -committerdate

И всё, бранчи отсортируются по дате последнего коммита. Сильно удобнее, кмк.

Автор видео с примером — Бен Холмс.

P. S. сейчас евангелисты GUI для Git придут мне напихивать :)

#git #feature

#такое дня

Итак, что же произошло?

Жена изучает Wordpress и React. Вот вы знали, почему Gutenberg — конструктор блоков в Wordpress — так боготворят? Вот я раньше не знал, пока, собственно, жена в колледже не начала его изучать.

Если коротко, каждый блок в Gutenberg можно описать в React. А потом рендерить WYSIWYG в конструкторе и PHP-версию для сайта. Исконный SSR как он есть :) На самом деле, я был почти в восторге.

И для этого процесса имеется кодогенератор.

Он сгенерирует JSON-схему блока, стили и начальные скрипты для редактора и клиентской части сайта, package.json с нужными скриптами, PHP-обвязку, readme... В общем, с десяток файлов.

Но вы не за этим тут собрались, верно?

Итак, нагенерировали 9 блоков, три из них практически полностью закончили, остальные — оставили в виде кодгена. И попросила жена меня помочь уложить всё в git. Последить, что все сделано правильно.

Как показали события, нашла, конечно, кого просить.

Ну, первый раз чтоле:
git init
touch .gitignore
git add .
git status
...так, index.php же не нужен...
git reset --hard
echo "index.php" >> .gitignore
...блять

89 файлов исчезли, осталось лишь то, что было открыто в файлах.

Зачем я сказал сделать хард-ресет — я сам не очень понимаю, если честно. Даже не спрашивайте. Я привык работать инкрементально: и добавлять файлы с самого начала, и ветки на каждый чих и так далее. Потому ресет для меня был инструментом простой подчистки мусора.

Теперь-то понятно, что от этой привычки надо избавляться.

К счастью, в git ничего не пропадает бесследно. Есть возможность вытащить «подвисшие» файлы из индекса, пока не произошёл коммит. Как-то так:

git fsck --lost-found

Эта команда вытащит подвисшие файлы в директорию .git/lost-found/.

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

К счастью, мы же помним, что у нас кодогенератор? Содержимое каждого из этих файлов явно говорит, к чему оно относится. Так что, вооружившись списком файлов, который мне ранее дала команда git status, я создал 89 пустых файлов с верными именами и пошёл копировать один за одним. Полчаса из жизни.

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

Да, во многи редакторах присутствует концепция локальной истории, но тот же VS Code реагирует только на открытые файлы.

В общем, было весело. И немного стыдно, да.

P. S. удалять index.php из списка добавленных файлов надо было так:

git reset index.php

Или просто

git reset

...чтобы очистить список файлов к добавлению.

#git #wordpress #fail

#статья дня

7 апреля 2025 года системе контроля версий Git исполнилось 20 лет!

По этому поводу GitHub (а кто же ещё) провели с автором — Линусом Торвальдсом — интервью.

Выдержки:

– Он не хотел писать систему контроля версий — это казалось скучным. Но BitKeeper перестал быть вариантом, и пришлось самому.

– У него не было «плана» или видения. Всё делал на ходу, по мере необходимости. Даже не знал, насколько всё это станет популярным.

– Git задумывался не как «инструмент для всех», а как «инструмент для меня». И, по мнению Линуса, именно в этом причина успеха.

– Его подход: «не делать предсказаний», особенно в open source. Он сам не ожидал, что Git проживёт 20 лет.

– Команду git bisect называет «одной из умных штук», но уклоняется от выбора любимой команды: «это как выбирать любимого ребёнка».

А прочитать целиком рекомендую тут: https://github.blog/open-source/git/git-turns-20-a-qa-with-linus-torvalds/

Кстати, интервью скоро обещают выложить в формате видео!

#git #anniversary

#инструмент дня

Разобраться в концепциях Git просто не только лишь всем. Кто-то схватывает на лету, кто-то продирается сквозь ветки и листья документации. Кто-то забивает на всё, использует UI любимой IDE и ничего сложнее git pull origin master не разруливает.

Но насколько проще было бы, если появился бы симулятор происходящего под капотом. И ведь такой есть!

И называется он git-sim, вот так вот буквально.

Нужно разрулить конфликтный cherry-pick? Слить несколько веток вместе? Посмотреть последствия reset, stash, rebase? Да запросто! Просто вместо git команда пишете git-sim команда и наслаждаетесь.

Ах да, ссылки на примеры от авторов (много видео и иллюстраций): https://initialcommit.com/tools/git-sim

И на GitHub проекта: https://github.com/initialcommit-com/git-sim

Очень уютная штука.

#git #sim #tool #бородач

#расширение дня

А что, если история гита может быть представлена не в виде вертикального списка?

А что, если можно правильно использовать анимации, акцентируя внимание на изменениях?

А что, если можно не открывать интерфейс git blame на каждый чих?

Именно так подумал Родриго Помбо и нафигачил прекрасное расширение для Visual Studio Code: Git File History.

Принцип действия понятен по виде, устанавливайте: https://marketplace.visualstudio.com/items?itemName=pomber.git-file-history

Всем git, котаны!

P. S. вы же в курсе, что устанавливать расширения можно из консоли?

Как-то так:

code --install-extension pomber.git-file-history

Если команда code недоступна, решение тут.

#git #history #vscode #бородач