Пятнадцать лет назад я стал пользователем Evernote. Счастливое время, когда мысли были только о стартапах, Кремниевой долине и технологиях. И хоть сейчас евангелисты Obsidian абсолютно точно уверены, что они впервые создают второй мозг, позволю себе сказать: я создавал second brain в 2010-х с помощью Evernote и Moleskine. А OCR поиск Evernote по картинкам и документам был абсолютно магическим. Не зря, видимо, до этого инженеры работали над решениями OCR для правительства США.

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

Чем был для меня Evernote

Конечно, как и сейчас, за довольно простым, но хорошим продуктом должно стоять что-то большее. Идея или дистрибьюшен. Ведь это же только лишь сервис для написания заметок и ничего больше. Для меня это была идея о том, что за океаном русский бородатый мужик Степан Пачиков, технарь, взял, сделал и заработал на этом какие-то сумасшедшие деньги. Я им пользовался, советовал друзьям, участвовал в его хакатонах и даже там получал призовые. Помню отсыпали довольно много кредитов на AWS.

Из всего набора фичей Evernote самыми ценными были всего три на мой взгляд. Но именно они удерживали меня как пользователя вплоть до 2022 года — года, когда я отказался от SaaS сервисов крупных компаний. Больше десяти лет подписки...

Итак, что это были за якорные фичи:

1. Поиск по документам, картинкам и фото

   Чертовски полезная вещь. Понятно, что при правильной организации меток и папок можно находить любую, даже самую старую заметку или документ, просто двигаясь по какой-то системе. Но если к системе добавить ещё и очень точный поиск, то процесс будет куда приятнее. У меня было много медицинских документов, которые было очень просто находить по ключевым словам, присутствующим на картинке или скане. И мне не надо было руками проводить предварительную индексацию и организацию ради самой организации. Просто добавление одной метки — и OCR-поиск делал своё дело. Да, поиск на тот момент был именно что OCR. Но к этому мы ещё вернёмся.

2. Будильник на заметки

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

3. Skitch (аннотатор скриншотов)

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

Недавно пробегая по скриншотам в поиске одного нужного на своем пк, подумал, как было бы прикольно если был бы поиск из Evernote. И да я знаю, что подобных решений было и есть множество. Причём речь может идти не только о коммерческих продуктах, но и open source, просто поищите на GitHub. Но все это как это всегда и бывает "не то" "было лучше". Хотя конечно лучше то и не было, поиск на Evernote работал по принципу OCR, очевидно раз компания все еще существует, то смею предположить, что он был улучшен до гибридного поиска. То есть совмещения OCR (поиска по тексту распознаному из картинки) и семантического поиска, то есть поиска по embedding'ам, которые были получены из картинки с помощью какой-то модели. Речь пойдет о небольших моделях, которые можно запустить на обычном пользовательском железе и они имеют очень ограниченный фокус на то что они делают.

Что я хочу от поиска по картинкам?

Если на картинке изображена кошка или металический люк, то я бы мог так и написать свой запрос и получить подобные картинки. Очень хотелось бы искать картинки по цветовой гамме. Скажете зачем, но это невероятно удобно, в моих кейсах когда я точно помню дизайн какого-то сервиса и поиск по запросу это profile form, может и не помочь, а вот фиолетовый цвет + profile form, результат будет найден. Хочется искать используя не только английский текст, но и русский в запросах. Чтобы я мог написать metal grate или металлический люк и получил бы схожий результат. Конечно чтобы поиск учитывал текст на картинке, если текста там много, но и смысл этого текста. К примеру я сделал скриншот с YouTube рецепта теста для пиццы, он был написан маркером на доске. Текст на картинке содержит слова вода, мука и соль. Желательно бы его искать по запросу "рецепт пиццы" или просто "рецепт". Также поиск должен быть быстрым. Ок, я готов ждать долгой индексации и предварительного анализа базы картинок, но сам поиск должен быть около мгновенным. Итак, возможно ли это сделать с использованием современных моделей, не используя внешних сервисов и API.

Шаг 1. Семантический поиск.

Или поиск по embedding'ам картинок и embedding'у полученному из текстового запроса пользователя. Для решения нам нужна мультимодальная модель эмбеддингов и желательно с лицензией MIT/Apache. И такая есть это Nomic Embed Vision, как и любая трендовая модель на основе трансформером и BERT-архитектуры. Прелесть модели для нашей инженерной задачи в том, что текст и картинки на входе, дают вектора из одного пространства. И мы можем искать текст по картинке, картинку по картинке или картинку по тексту. Из минусов, русский язык работает не самым лучшим образом в запросах, это конечно решим тоже, но позже.

Давайте разберемся как я буду проверять качество принятых моделей в пайплайне поиска. А буду качественным методом нравится или не нравится на моей локальной папке со скриншотами. Их всего порядка 500. Глобальная задача скормить всю мою базу знаний, заметок, скриншотов, рефов, но пока ограничимся примером поиска по скриншотам. У меня был список картинок, которые я хотел найти из своей папки скриншотов. И поиск должен их найти. Никаких сложных бенчей и методологии, я просто должен кайфануть от поиска. Итак берем rust, берем onnx модели nomic vision и смотрим что получается.

Первый же результат отработал идеально, это конечно было сопадением, но удачным. У меня был скриншот с YouTube ролика, как можно сварить люк на паркинге, чтобы в нем УК могла бы похоронить насос. И поиск этой картинки был мгновенным, имея на руках лишь Semantic search с использованием одной единственной модели. Сами вектора embeddings можно хранить в любой бд с поддержкой векторов и поиска по ним. У SQLite есть плагин, есть еще LanceDB. Они подходят идеально потому что не имеют избыточной сложности в поддержке и работе с ними. Помним что SQLite установлен вообще на всех смартфонах в мире и абсолютно булетпруфная база данных.

Проблема была только с запросами на русском языке, решать проблему я взялся в лоб. А именно переводом запросов с русского на английский язык и подобрал маленькую модель для пары языков c русского на английский. https://huggingface.co/Teradata/opus-mt_tiny_rus-eng Запросы стали работать значительно лучше. Конечно мы на каждом таком шаге теряем в качестве, если бы модель уже была мультиязычная, было бы лучше, но идем простым путем. Для обучения аналогичной модели нужен не только стек из 16+ H100/H200, но и длительная работа с датасетами, что неприемлемо для моей задачи. Но небольшими силами (увеличением цепочки из моделей) целевой результат вырос и вообще стало возможным искать металлический объект, словом "метал", а не только "metal".

Шаг 2. Поиск по цветам.

Это моя давняя мечта о том, как я бы хотел искать в своей библиотеке референсов с изображениями. И цвета абсолютно идеально укладываются в векторном виде. И чтобы сделать такой поиск надо сделать две вещи. Первое это вытащить доминантные цвета или своего рода палитру из картинки. Второе уложить палитру цветов в виде вектора. И дальше можно просто искать близкие вектора, абсолютно как я сделал до этого с embeddings от nomic vision модели. Чтобы вытащить палитру можно использовать разные алгоритмы, но как я люблю подходить к таким задачам, будет брать самое простое решение. Главное чтобы оно могло дать значимо хороший результат. Есть k-means clustering, его и возьмем. Существует несколько хороших библиотек для Rust, я взял https://crates.io/crates/kmeans_colors Для каждого изображения k-means извлекает 5 доминирующих цветов в цветовом пространстве Lab, которые склеиваются в один плоский вектор и индексируются в LanceDB. Когда пользователь ищет одновременно по тексту и цвету, система сначала выполняет семантический поиск (векторный или гибридный), а затем переранжирует результаты с учетом поиска по цвету. В этой оценке семантическая релевантность первична, а цветовая близость — уточняющий фактор.

Бам! Это работает конечно же в совокупности с семантическим поиском. К примеру я хочу поискать login UX скриншоты. И помню что нужный мне сайт оранжевый или красный.

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

С момента того, как над Evernote начали работать прошло уже больше 20 лет. И если в начале пути этого SaaS технология поиска по картинкам была действительно заградительным оружием против конкурентов, то со временем технология стала очень дешевой в разработке и внедрении. Да, конечно, Tesseract OCR стал open source уже тоже десятилетия назад. Но это абсолютная земля и небо, что мы можем запускать сейчас и тогда локально на машине пользователя и с каким уровнем качества.

Мы вроде бы должны войти в эпоху тысяч и тысяч новых приложений и сервисов, которые могут решать старые проблемы значительно проще, быстрее и лучше. LLM вроде как решили проблему софта и оставили лишь проблему идеи. Но где же эти тысячи новых стартапов?

P.S.

Результат работы можно попробовать скачав приложение по ссылке. Приложение доступно только для macOS, Linux и Windows. Протестирован пока только на Linux. Я продолжаю над ним работу прямо сейчас и не вижу еще то, что из него получится. Пока появилась рабочая идея, сделать свой Skitch. Только абсолютно с локальными моделями для поиска и для обработки изображений. Если интересно можете подписаться на https://zatsepin.dev/subscribe или на YouTube https://www.youtube.com/@yurizatsepin

Работал я как‑то над fine‑tuning для одной модели. Потенциала моих GPU в домашней лаборатории (home lab) для такой задачи было недостаточно. Сам fine‑tuning VLM это вообще отдельный разговор, и вопрос его целесообразности стоит обсудить отдельно, но для него мне потребовалась внешняя видеокарта.

Я расскажу ниже, как подключить GPU от стороннего провайдера себе в Google Collab.

На рынке сейчас есть три вида игроков:

• облака (в РФ это, например, компания‑такси, банк и социальная сеть);
• специализированные хостинг‑провайдеры;
• P2P‑маркетплейсы, где любой владелец видеокарты может сдать её в аренду.

Облака - очень дорогое решение и уже давно совсем не недружелюбны с точки зрения UX. Любой специализированный хостинг‑провайдер для GPU, каким бы посредственным дизайном он ни обладал, всегда будет более удобен в использовании. Облака давно создали целый зверинец сервисов, разных правил и усложнений. И хотя они во многом похожи, зачем‑то соревнуются в том, у кого будет более интересный UI. Помимо перегруженности интерфейса, облака имеют абсолютно оборзевшие тарифы на услуги.

Маркетеплейсов p2p в РФ нету. Ждем когда Дуров уже запустит сервис Cocoon, вроде собирался.

Поэтому мой выбор обычно падает на один иностранный p2p (hyperbolic) или на пару наших хостинг провайдеров (к примеру, immers.cloud — но это не важно для данной статьи и не является рекомендацией).

Кстати нормальная цена для H100 2$ и для H200 2.5$ на февраль 2026 года. Это как бы говорит о том, что, если вдруг решите обучить свою LLM, которая попала бы в топ‑100 по бенчмаркам, потребуется порядка 2 миллионов долларов.

Моя цель — запустить Jupyter Notebook на такой машине и пробросить порт Jupyter‑сервера на мой localhost:8888 (или на другой порт). Затем, когда мы сможем работать в этом Jupyter через http://localhost:8888, останется в интерфейсе Google Colab в настройках runtime (там, где кнопка Connect) указать Connect to a local Runtime и прописать путь к Jupyter с нужным токеном. В процессе будет несколько нюансов, но концепция проще некуда.

Через UI хостинг провайдера GPU нам нужно получить:

• ip
• username
• .pem / private key

Для работы на удалённой машине мы даже не будем заходить на неё вручную — я буду использовать OpenTofu. Это инструмент, который полноценно заменяет Terraform от HashiCorp.

Для установки OpenTofu, я использую mise и вам советую.

mise use --global opentofu

А в моем коде, который можно скачать по ссылке, opentofu будет прописан в mise.toml и при установленном mise, вам даже запускать эту команду не надо будет, а tofu будет доступен при переходе в папку с кодом. Нужно выполнить mise trust в папке, чтобы файл mise.toml стал доверенным.

resource "random_password" "jupyter_token" {
    length  = 32
    special = false
    override_special = ""
  }

resource "null_resource" "jupyter" {
  connection {
    type        = "ssh"
    host        = var.server_ip
    user        = var.username
    private_key = file(var.ssh_key_path)
    timeout     = "5m"
  }

  provisioner "file" {
    content = <<-EOF
      [Unit]
      Description=Jupyter Notebook Service
      After=network.target

      [Service]
      Type=simple
      User=${var.username}
      WorkingDirectory=/home/${var.username}/notebooks
      ExecStart=/home/${var.username}/.jupyter-env/bin/jupyter-notebook --no-browser --ip=0.0.0.0 --port=${var.jupyter_port} --notebook-dir=/home/${var.username}/notebooks --NotebookApp.token=${random_password.jupyter_token.result} --ServerApp.allow_origin='https://colab.research.google.com' --ServerApp.port_retries=0
      Restart=always
      RestartSec=10

      [Install]
      WantedBy=multi-user.target
    EOF
    destination = "/tmp/jupyter.service"
  }

  provisioner "remote-exec" {
    inline = [
      "curl -LsSf https://astral.sh/uv/install.sh | sh",
      "export PATH=\"$HOME/.local/bin:$PATH\"",
      "mkdir -p ~/.jupyter ~/notebooks",
      "uv venv --clear ~/.jupyter-env",
      "uv pip install --python ~/.jupyter-env/bin/python notebook torch numpy",
      
      "sudo mv /tmp/jupyter.service /etc/systemd/system/jupyter.service",
      "sudo systemctl daemon-reload",
      "sudo systemctl enable jupyter",
      "sudo systemctl restart jupyter",
      "sudo systemctl status jupyter --no-pager",
    ]
  }
}

resource "null_resource" "configure_firewall" {
  depends_on = [null_resource.jupyter]

  triggers = {
    jupyter_port = var.jupyter_port
  }

  connection {
    type        = "ssh"
    host        = var.server_ip
    user        = var.username
    private_key = file(var.ssh_key_path)
    timeout     = "5m"
  }

  provisioner "remote-exec" {
    inline = [
      "sudo apt-get update -qq",
      "sudo apt-get install -y ufw fail2ban",
      "sudo ufw --force reset",
      "sudo ufw allow 22/tcp",
      "sudo ufw default deny incoming",
      "sudo ufw default allow outgoing",
      "sudo ufw --force enable",
      "sudo ufw status verbose",
      "sudo systemctl enable fail2ban",
      "sudo systemctl restart fail2ban"
    ]
  }
}

output "jupyter_instruction" {
  description = """
    You should do port forwarding:
    ssh -i ${var.ssh_key_path} ${var.username}@${var.server_ip} -L ${var.jupyter_port}:localhost:${var.jupyter_port}"""
  value = nonsensitive("http://${var.server_ip}:${var.jupyter_port}/?token=${random_password.jupyter_token.result}")
}

Важно для нашей задачи — скрипт запуска Jupyter:

/home/${var.username}/.jupyter-env/bin/jupyter-notebook --no-browser --ip=0.0.0.0 --port=${var.jupyter_port} --notebook-dir=/home/${var.username}/notebooks --NotebookApp.token=${random_password.jupyter_token.result} --ServerApp.allow_origin='https://colab.research.google.com' --ServerApp.port_retries=0

Мы должны прописать allow_origin для google collab. В остальном скрипт не претендует на что‑то большее, чем просто запуск сервиса Jupyter на Debian. Мы открываем только SSH‑порт и блокируем попытки подключения по SSH с неправильным ключом по IP. Вся прелесть в том, что один раз написанный скрипт OpenTofu даёт возможность поднять runtime для Google Colab в любой момент — быстро и без заморочек.

Либо от нашего оператора такси, либо от банка:

provider_installation {
  network_mirror {
	# https://terraform.cloud.ru/
    url = "https://terraform-mirror.yandexcloud.net/"
    include = ["registry.terraform.io/*/*"]
  }
  direct {
    exclude = ["registry.terraform.io/*/*"]
  }
}

Запускаем GPU Runtime

Как проходит запуск инфраструктуры:

• Перешли в папку с кодом инфраструктуры
  • Благодаря mise инструмент tofu автоматически подвязывается в PATH — то есть команда tofu становится доступна в консоли.
• Обновим terraform.tfvars или создадим его

server_ip      = "ip address"
username       = "ubuntu"
ssh_key_path   = "private.pem"
jupyter_port   = 8899

• Смотрим доступные команды: mise tasks
• Инициализируем tofu mise run init
• Применяем конфигурацию на удалённом GPU‑сервере: mise run apply

Ждем...

В ответе получим строчку c localhost и token, которая если бы мы были на машине с нашей GPU, то она открыла бы Jupyter Notebook. Но мы у себя на машине, а GPU сервер имеет только один открытый порт и это ssh.

Нам осталось пробросить порт на локальную машину:

ssh -i private.pem ubuntu@xxx.xxx.xxx.xxx -L 8888:localhost:8888

Копируем строку с токеном и пробуем открыть в браузере: sh http://${var.server_ip}:${var.jupyter_port}/?token=${random_password.jupyter_token.result

Обе строки — для проброски порта и для доступа к Jupyter Notebook — должны быть в ответе на команду apply, так что вручную их редактировать не нужно.

Если в браузере всё открывается, прописываем этот сервер как local runtime в интерфейсе Google Colab:

Попробуйте выполнить простой Python‑скрипт в Google Collab:

import torch
print(torch.cuda.get_device_name(0))

Да, я запустил платный Tesla T4, хотя Google Colab предоставляет его бесплатно — но это сделано исключительно для скриншота. Стоимость использования Tesla T4 — около десяти рублей в час.

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

Представьте: ваш Claude Code или Cursor AI-агент удаляет файл или начинает переписывать его заново. Содержимое файла еще не было сохранено в git commit—оно все еще находится в unstaged состоянии. Все потеряно! Стоит только надеяться, что AI-агент сможет что-то восстановить из памяти и контрольных точек, но это костыль, может и не восстановит, а может вы пропустили этот момент.

Когда я переключился с чистого Git на JJ поверх Git, таких проблем и возникнуть не может. Я стал намного спокойнее относиться к своему коду при работе с AI-агентами. Позвольте мне показать, почему JJ улучшит вашу жизнь как программиста и как интегрировать его в вашу практику, не нарушая процессы в команде.

Почему Git не справляется с параллельной разработкой с ИИ

Git фундаментально устарел для систем, в которых код пишется параллельно с вами на вашем ПК.

Парадигма Git проста: вы собираете какие-то изменения локально, кладете их в ящик, ставите на этот ящик хеш-идентификатор и отправляете через конвейер ящиков. Этот ящик вам кажется неизменяемым—лучше его больше не трогать, разве что читать, что в нем сделано. Если что-то произошло, пока вы не собрали ящик, ну напишите еще раз. Обычно вы не ушли далеко, и что может произойти?

В терминах видеоигр, git commit это такие сохранения, которые вы делаете руками. Но вот автосохранений у вас нет.

Годы эта концепция была практически идеальной. Хотя надо признать, интерфейс всех возможностей Git всегда был довольно сложным. Борьба с тем, как выглядит история коммитов в разных компаниях и по сей день говорит, что в этой системе что-то не совсем хорошо.

JJ (Jujutsu) призвана исправить проблемы удобства Git (UX), сохраняя полную совместимость с существующими репозиториями и рабочими процессами.

JJ—это система управления версиями, которая находится поверх Git и предоставляет гораздо более интуитивный интерфейс и богатые возможности для управления историей вашего кода, особенно при работе с AI-агентами.

Позвольте мне показать вам три ключевые концепции, которые делают JJ мощным инструментом:

• JJ log операции: undo и redo
• Рабочая копия как коммит
• Продвинутые операции: squash, split, edit

Часть 1: Операции JJ с Undo/Redo

Поехали, создадим ваш первый JJ-проект:

mkdir jj-step-0 && cd jj-step-0 && jj git init
touch README.md
echo "first try" >> README.md
jj diff

Если выполнить команду jj log, то будет видно, что у вас уже есть Change ID и Commit ID. Слева — Change ID, а справа — Commit ID.

Change ID — это постоянный идентификатор логической задачи, над которой вы работаете. В отличие от Git-хеша (который в jj называется Commit ID), Change ID не меняется, когда вы редактируете файлы, меняете описание и т.п. Change ID никогда не меняется — даже если вы делаете amend, rebase или редактируете сообщение коммита. Основные команды jj edit, jj describe выполняются для выбранной Change ID.

Change ID это случайное число длиной 16 байт, которое представлено цепочкой из 12 символов от z-k. Это делает его вид уникальным и позволяет легко читать.

В jj рабочая директория — это всегда «живой» коммит. Любое изменение в файлах мгновенно становится частью текущей ревизии. Рабочая копия помечается символом @ в выводе jj log. Hash коммита будет меняться при каждом внесении правок в проекте. По этому он не так интересен в процессе работы.

jj commit -m "First"
jj

Наш первый коммит. 🎉🎉🎉 И на данный момент нет никаких изменений в новом рабочем, пора начать писать фичу с помощью AI-агента.

echo "Cool staff" >> README.md
touch new-file.md && echo "One more thing" >> new-file.md
jj diff

Случается страшное: ваш AI-агент решает переписать new-file.md с нуля и удаляет оригинальное содержимое, заменяя его чем-то странным.

Давайте сымитируем то, что сделал AI:

rm new-file.md
touch new-file.md
echo "Bad staff" >> new-file.md

Что делать!?? Точно не будем унижаться перед ИИ и просить его восстановить нашу работу. Вместо этого давайте посмотрим, что сохранил JJ:

jj evolog --color=always -p

Отлично! JJ сохраняет историю всех изменений в рабочем коммите (тут нету unstaged), а также историю всех операций, которые вы совершили. Каждое изменение, удаление или добавление—это отдельная операция с собственным хешем. Теперь давайте откатим то, что сделал AI:

jj undo
jj diff

Дело сделано. 🎉🎉🎉 И наш "Cool staff" на месте. Если мы вдруг осознаем, что AI был прав, мы можем вернуться с помощью:

jj redo

Важно: undo и redo работают с операциями, а не с изменениями файлов. Если вы сделали коммит и поняли, что нужно добавить еще что-то, просто используйте jj undo.

Ключевые команды JJ для операций

Часть 2: Управление коммитами и историей

Теперь давайте разберем, как JJ упрощает управление историей коммитов и их описаниями. Начнем с нового проекта:

cd .. && mkdir jj-step-1 && cd jj-step-1 && jj git init

Будем работать над тремя фичами в проекте:

touch file.md
echo "Feat 1" >> file.md
echo "Feature 2" >> file.md
jj commit -m "Feat 1 & 2"

touch file2.md
echo "Feature 3" >> file2.md
jj commit -m "Feat 3"

Погодите, вы понимаете, что везде нужно писать "Feature", а не "Feat" в вашем коде. Так гласят новые правила в компании, вы что пропустили?. Нам надо вернуться и исправить первый коммит. С JJ это будет невероятно просто.

jj edit r

Обратите внимание, что мы используем только первую букву r вместо полного значения change ID. JJ использует "минимально достаточные" ссылки на коммиты—ровно столько символов, чтобы однозначно идентифицировать ревизию без коллизий в вашем текущем проекте. По мере роста вашего проекта потребуется больше символов.

Теперь мы "внутри" первого коммита. Мы можем изменить file.md как нужно, а потом изменить сообщение коммита с помощью:

Теперь мы "внутри" первого коммита. Мы можем изменить file.md как нужно, а потом изменить сообщение коммита с помощью:

jj describe

Разделение коммитов

Раз уж мы здесь, давайте разделим первый коммит на два отдельных коммита—по одному для каждой фичи. Ну правдо же, не хорошо делать разные задачи в одном коммите. Это также невероятно просто с помощью:

jj split

Нажмите 'F', чтобы развернуть все изменения, выберите "Feature 1" и подтвердите с 'c'. Установите сообщение коммита "Feature 1", сохраните и установите другое сообщение для второго коммита. Теперь у вас должна быть чистая история.

Вернемся к нашему последнему коммиту с третьей фичей:

jj edit u

И начнем работать над четвертой фичей:

jj new -m "WIP 4 feat"
touch README.md && echo "Blazing fast project" >> README.md

В JJ есть концепция, по которой можно не использовать команду commit. Можно начинать работу с того, что сохраняется старый коммит с описанием и вы начинаете работу над чем то новым с описанием "WIP 4 feat". Потом в любой момент можно переназначить описание коммита и начать новый. Это концепция явно говорит вам, над чем вы начали работу и что вы сейчас делаете.

Погодите—README.md файл, который мы только что добавили, должен быть частью первого коммита. Непорядок! Но никакой проблемы, просто объедините вашу текущую работу с первым коммитом и продолжайте:

jj squash --to r

Отредактируйте сообщение коммита и все готово!

Заключение

Мы попрактиковались с JJ и изучили его мощный и удобный интерфейс для Git. Красота в том, что вы можете использовать его, не изменяя процессы вашей команды—JJ работает поверх обычного Git.

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

Конечно, я не могу обещать бесшовный переход. Уверенное владение такими инструментами, как JJ, занимает больше времени, и вы можете столкнуться с моментами, когда лучше бы у вас был чистый git. Честно говоря, я принял JJ только со второй попытки использования. Как попробовать первый раз оливки, это может вам не понравиться, но если будете продолжать, то все совсем неплохо.

Я не затронул всё, что может делать JJ, но надеюсь, это было полезно и что вы почувствуете вдохновение попробовать его и сделать вашу работу ещё лучше.

Подписывайтесь

Подписывайтесь на мой канал на https://zatsepin.dev/subscribe, чтобы получить доступ к моему закрытому контенту, исходному коду проектов.

Референсы

• https://docs.jj-vcs.dev/
• https://jj-for-everyone.github.io/
• https://steveklabnik.github.io/jujutsu-tutorial