Jujutsu или Git: что выбрать для работы с ИИ-агентами и Claude Code
ИИ-агент вроде Claude Code — это ассистент, который сам правит файлы в вашем репозитории по текстовой команде. За одну задачу он может переписать десяток файлов, и главная проблема тут не в коде, а в версионировании: нужно быстро увидеть, что именно изменил агент, откатить неудачный заход и сохранить нормальную историю. Этот гайд — про выбор системы контроля версий (VCS — программа, которая хранит историю изменений файлов) для такой работы: классический Git против Jujutsu. Он рассчитан на стажёра, который уже умеет `git add` и `git commit`, но впервые настраивает репозиторий под автоматические правки агента.
TL;DR
- Git — стандарт индустрии: с ним работают все хостинги, IDE и сами агенты. Но у него есть индекс (staging area — промежуточная зона, куда вы складываете файлы перед коммитом), и агент эту зону постоянно путает.
- Jujutsu (сокращённо jj) — альтернативная VCS, совместимая с Git: она хранит историю в обычном `.git`, но работает по другой модели — рабочая копия сразу является коммитом.
- В jj нет команды «добавить в индекс»: изменения подхватываются автоматически, а каждый шаг можно откатить через журнал операций.
- Если вам нужно «просто чтобы работало» и команда уже на Git — оставайтесь на Git и дисциплинируйте агента.
- Если вы часто откатываете эксперименты агента и вам надоело возиться с индексом — попробуйте jj в режиме colocated (когда jj и Git живут в одной папке).
Что меняется, когда в репозитории работает ИИ-агент
Обычный разработчик коммитит редко и осмысленно: сделал фичу — закоммитил. Агент работает иначе. Он получает задачу вида «добавь валидацию email в форму регистрации», правит пять файлов, потом вы просите «убери лишний лог» — и он правит ещё два. Если коммитить после каждого шага, история превращается в мусор. Если не коммитить — непонятно, что вообще поменялось.
Отсюда два требования к VCS: она должна показывать разницу между «сейчас» и «последним хорошим состоянием», и она должна позволять дешево откатить один неудачный шаг агента, не теряя остальное. Именно по этим двум пунктам Git и jj расходятся сильнее всего. Кстати, если вы только начинаете выстраивать работу с агентом в команде, сначала посмотрите гайд про субагентов и общий ИИ-суперагент в Claude Code — там про то, как разделить роли между несколькими агентами, а здесь мы разберём, куда складывать результаты их работы.
Git и Jujutsu: разница на пальцах
- **Индекс.** В Git путь такой: изменил файл → `git add` → `git commit`. Индекс — это «черновик коммита». В jj индекса нет вообще: рабочая копия автоматически считается коммитом, который можно тут же описать сообщением.
- **Рабочая копия.** В Git незакоммиченные изменения — это «грязное» состояние, которое легко потерять через `git checkout`. В jj текущие правки — это обычный коммит, его видно в `jj log`, от него можно отвести новый.
- **Ветки.** В Git ветка — указатель, который надо явно создавать и переключать. В jj аналог называется bookmark (закладка), а история — это граф ревизий; перемещаться по нему можно без «переключения ветки».
- **Откат.** Git умеет откатывать, но через `git reflog` или `git reset` — и это пугает новичков. В jj есть журнал операций: `jj undo` отменяет последнее действие целиком.
- **Конфликты.** Git оставляет маркеры вида `<<<<<<<` в файлах и блокирует часть операций. jj умеет записать конфликт прямо в коммит и дать разобрать его позже.
- **Совместимость.** jj не отдельный мир: она читает и пишет обычный Git-репозиторий, а `jj git push` отправляет изменения на GitHub или в GitLab.
Таблица сравнения
| Критерий | Git | Jujutsu (jj) |
|---|---|---|
| Индекс (staging area) | Есть, нужно `git add` | Нет, изменения подхватываются сами |
| Текущая работа | «Грязная» рабочая копия | Коммит в рабочей копии |
| Ветки | Ветки, явное `git switch` | Bookmarks, свободное перемещение по ревизиям |
| Откат действия | `git reflog`, `reset`, `restore` | `jj undo`, журнал операций |
| Конфликты | Маркеры в файле, часть команд блокируется | Конфликт хранится в коммите, разбирается позже |
| Совместимость с хостингами | Полная, это стандарт | Полная через `jj git push` в тот же `.git` |
| Порог входа | Низкий, все знают | Средний, другая модель мышления |
| Что видит агент | Привычные git-команды | Нужно объяснять, что индекса нет |
Обратите внимание: таблица не про «кто лучше», а про то, какие привычки придётся менять. Обе системы хранят одну и ту же историю в одной и той же папке `.git`.
Один и тот же цикл правок: Git против jj
Допустим, агент поправил 12 файлов, и вы хотите зафиксировать это одним аккуратным коммитом.
Git:
git status # смотрим, что изменено
git diff # читаем разницу построчно
git add .
git commit -m "feat: валидация email в форме регистрации"
git log --oneline -3Ожидаемый результат: `git status` покажет список из 12 файлов, а `git log` — строку вида `a1b2c3d feat: валидация email в форме регистрации`. Почему это работает: `git add .` кладёт все изменения в индекс, `git commit` превращает индекс в снимок истории.
Jujutsu:
jj status # что изменилось
jj diff # разница
jj describe -m "feat: валидация email в форме регистрации"
jj new # начинаем следующий коммит
jj logОжидаемый результат: `jj log` покажет текущую ревизию с вашим сообщением, а `@` будет указывать уже на новый пустой коммит. Почему это работает: `jj describe` просто вешает сообщение на уже существующий коммит рабочей копии, а `jj new` отводит от него следующий. Никакого `add` не нужно.
Пошагово: как поставить jj рядом с Git и не сломать репозиторий
1. **Проверьте, что Git уже настроен.** Выполните `git config user.name` и `git config user.email`. Если команды ничего не выводят, настройте их. Ожидаемый результат: обе команды печатают ваши имя и почту. Без этого не будут работать ни Git, ни jj.
2. **Установите jj.** Инструмент распространяется как обычный пакет. Например, на macOS через Homebrew: `brew install jj`, на Windows — через `winget install jj-vcs.jj`, в Linux — пакетным менеджером дистрибутива. Ожидаемый результат: команда `jj --version` печатает номер версии.
3. **Задайте имя и почту для jj.** Создайте файл `~/.config/jj/config.toml`:
[user]
name = "Иван Петров"
email = "ivan@example.com"Ожидаемый результат: `jj config list` покажет эти значения. Почему отдельно от Git: jj читает свою конфигурацию, хотя и умеет подхватывать часть настроек Git.
4. **Включите режим colocated в существующем репозитории.** Перейдите в проект и выполните:
cd ~/projects/my-app
jj git init --colocateОжидаемый результат: рядом с папкой `.git` появляется `.jj`, а `jj log` показывает вашу текущую историю. Почему это безопасно: colocated означает, что jj и Git работают с одним и тем же рабочим каталогом, и обычные git-команды продолжают работать.
5. **Сделайте тестовый прогон агентом.** Попросите Claude Code внести маленькую правку — например, добавить комментарий в один файл. Затем выполните `jj diff`. Ожидаемый результат: вы видите ровно ту одну строку, которую добавил агент. Если видите больше — значит, в репозитории оставались незакоммиченные изменения с прошлого раза.
6. **Проверьте, что откат работает.** Введите `jj undo`. Ожидаемый результат: правка агента исчезает из `jj diff`. Это самая полезная команда в связке с агентом: она отменяет последнюю операцию целиком.
Чек-лист перед первым рабочим днём:
- [ ] `jj --version` выводит версию
- [ ] `jj config list` показывает ваши name и email
- [ ] В репозитории есть и `.git`, и `.jj`
- [ ] `git status` по-прежнему работает без ошибок
- [ ] `jj undo` успешно откатывает тестовую правку
Кому что выбрать
Оставайтесь на Git, если:вы работаете в команде, где все знают git-команды; у вас настроен CI (непрерывная интеграция — автосборка и тесты на каждый коммит), завязанный на git-хуки; вы используете инструменты, которые сами дёргают git. Плюс Git лучше подходит, когда агент работает недолго и правки вы коммитите один раз в конце.
Пробуйте jj, если:вы много экспериментируете с агентом и часто откатываете; вас раздражает `git add`; вы хотите видеть рабочую копию коммитом и свободно переставлять изменения. Хороший сценарий для новичка — локальный пет-проект: там цена ошибки нулевая, а привычка к журналу операций вырабатывается быстро.
Если вы пока выбираете не VCS, а самого ассистента, пригодится сравнение ИИ-ассистентов: ChatGPT, Claude, Gemini, DeepSeek — разные модели по-разному ведут себя при массовых правках файлов.
Возможные проблемы и решения
Проблема 1: `jj log` показывает не те коммиты, которые вы видите в Git.
Симптом: вы сделали `git commit`, а в `jj log` его нет.
Решение: выполните `jj git import` — эта команда подтягивает состояние Git в jj. Затем проверьте `jj log` снова. В colocated-режиме импорт часто происходит сам, но после ручных git-операций его стоит вызвать принудительно.
Проблема 2: все правки агента свалились в один коммит.
Симптом: `jj diff` показывает 20 файлов, хотя вы хотели разделить работу на два коммита.
Решение: разбейте коммит командой `jj split` — она позволяет выбрать, какие изменения оставить в текущем коммите, а какие вынести в новый. Если наоборот нужно склеить — используйте `jj squash`.
Проблема 3: в файле появились маркеры конфликта.
Симптом: в коде видны строки `<<<<<<<` и `>>>>>>>`.
Решение: откройте файл и уберите лишнее вручную, либо выполните `jj resolve`. В jj конфликт хранится внутри коммита и не блокирует остальные операции, поэтому разобрать его можно позже, не торопясь.
FAQ
Нужно ли удалять Git, чтобы пользоваться Jujutsu?
Нет. jj работает поверх обычного Git-репозитория и пишет историю в ту же папку `.git`. В режиме colocated обе системы сосуществуют, а `jj git push` отправляет изменения на GitHub или в GitLab как обычный git-push.
Можно ли в jj-репозитории продолжать пользоваться git-командами?
Да, в colocated-режиме `git status`, `git diff` и `git commit` работают. После git-команд стоит вызвать `jj git import`, чтобы jj увидел изменения.
Что будет, если агент запустит `git commit` внутри jj-репозитория?
Коммит создастся в Git, и jj подхватит его при следующем импорте. Ничего не потеряется, но сообщение и структура истории будут такими, какими их сделал агент, — то есть аккуратности ждать не стоит.
Jujutsu заменяет GitHub или GitLab?
Нет. jj — это локальный инструмент версионирования, а не хостинг. Он лишь готовит и отправляет историю, а хранит и показывает её по-прежнему удалённый репозиторий.
🤖 Кратко для ИИ
- Обновлено: 2026-10-14
- Темы: jujutsu или git, контроль версий для ии-агентов, claude code git, ai version control 2026
- Кратко: Сравнение систем контроля версий для сценариев, где код пишет нейросеть: параллельные ветки агентов, откаты, ревью изменений и перенос проекта с Git на jj.
- Ключевые факты:
- ИИ-агент вроде Claude Code — это ассистент, который сам правит файлы в вашем репозитории по текстовой команде.
- За одну задачу он может переписать десяток файлов, и главная проблема тут не в коде, а в версионировании: нужно быстро увидеть, что именно изменил агент, откатить неудачный заход и сохранить нормальную историю.
- Этот гайд — про выбор системы контроля версий (VCS — программа, которая хранит историю изменений файлов) для такой работы: классический Git против Jujutsu.
- Он рассчитан на стажёра, который уже умеет git add и git commit , но впервые настраивает репозиторий под автоматические правки агента.
- TL;DR Git — стандарт индустрии: с ним работают все хостинги, IDE и сами агенты.
- Но у него есть индекс (staging area — промежуточная зона, куда вы складываете файлы перед коммитом), и агент эту зону постоянно путает.