Надоело воевать с Git? Попробуй Jujutsu (jj), и вот почему он круче, чем кажется

Вступление

Если ты здесь, ты наверняка знаешь, что такое git. И да, не спорю — это офигенная штука. Деды знали, что писали.

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

И тут началось: я стал тратить кучу ресурсов на постоянные вопросы:

• Нужна ли отдельная ветка или нет?

• Merge или Rebase?

• Какой revert использовать?

• В каком статусе сейчас файл?

• Где вообще находится header?

А ещё каждый коммитил как хотел. В итоге история проекта — это каша: понять, что, когда и зачем сделал человек, просто невозможно.

Я начал гуглить best practices, читать про git flow, пытался навести порядок. Но всё равно слишком много времени уходило не на код, а на борьбу с системой контроля версий.

И вот я наткнулся на Jujutsu (jj). И хочу рассказать тебе, чем он меня зацепил.

О сути jj

Основная идея jj — «У нас нет веток. У нас есть изменения«.
Погоди, сейчас поясню.

Сразу скажу: всё это полностью совместимо с git. Так что можно просто взять и начать использовать jj прямо сейчас.

Пример боли

Предположим, мы работаем по классике: feature-branch.
Надо её как-то назвать. Начинаю в ней работать.
После каждого осмысленного шага — коммит. Ещё один. И ещё.

# Работаем над фичей 'new-feature' git checkout -b new-feature  # Первый коммит # ... код ... git add . git commit -m "feat: Add initial user authentication"  # Второй коммит # ... код ... git add . git commit -m "refactor: Improve auth validation"  # Третий коммит # ... код ... git add . git commit -m "fix: Fix minor typo in error message" 

А потом замечаем: ошибка была в самом первом коммите. В feat: Add initial user authentication.

Что делать?
Создавать новый? Делать rebase -i?
Переключаться, править, переносить руками.

# Как исправить ошибку в первом коммите, не затрагивая последующие? # Вариант 1: rebase -i git rebase -i HEAD~3 # Ищем коммит, меняем 'pick' на 'edit', правим, continue  # Вариант 2: revert первого коммита, потом новый коммит с исправлением git revert <hash_первого_коммита> # Создает новый коммит, отменяющий изменения # ... потом fix ... git commit -m "fix: Actually fix initial user auth"  # Вариант 3: reset до первого коммита, теряя все последующие git reset --soft <hash_первого_коммита> # ... потом все изменения из второго и третьего коммита в staging ... # ... а потом перекоммичивать все заново ... 

О, а тут ещё начальник прибегает с криком: «hotfix срочно!»
А я не могу у меня лапки конфликт.

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

А теперь jj

Пишешь код, коммит за коммитом.

# Никаких веток  # Первый коммит # ... код ... # никаких `add` jj commit -m "feat: Add initial user authentication"  # Второй коммит # ... код ... jj commit -m "refactor: Improve auth validation"  # Третий коммит # ... код ... jj commit -m "fix: Fix minor typo in error message" 

Ой, ошибка в первом? Просто переходишь к нему, правишь, возвращаешься — готово.

jj edit <rev> # перходим на нужный commit # ... правим ... jj edit <rev> # возвращаемся к работе обратно  

История переписалась, текущие изменения не потерялись.
Всё.

Я реально сижу и думаю: «А точно всё? Я что-то, слишком мало команд ввёл?»

Ты не думаешь:
«А какую merge-стратегию выбрать?..»
Ты думаешь:
«Как сделать код лучше?»

Конфликт? Hotfix? — без паники

Окей, допустим, случился конфликт.
Начальник снова кричит: «Фикс срочно!»

Без проблем — просто переключаюсь на старую версию, делаю hotfix.

jj edit <rev> # перходим на нужный commit # ... hotfix ... jj edit <rev> # возвращаемся к работе обратно  

Конфликты? Потом разберёмся. jj позволяет не тормозить разработку.
Никаких stash, rebase, checkout -b, «а где HEAD?».

Где же ветки?

В jj вместо веток — закладки (bookmarks).

Представь, что ты ведёшь дневник.
Вот ты пишешь, тебе нравится, как получилось — ставишь закладку prod.
Пишешь дальше. Получилось неплохо, но не уверен — ставишь dev.
Думаю, суть вы уловили.

# Создаем закладку на текущем коммите jj bookmark prod  # Работаем дальше, создаем новые коммиты jj commit -m "feat: More features"  # Создаем еще одну закладку jj bookmark dev  # Смотрим закладки jj bookmark list  # Переносим закладку на последний commit jj bookmark move prod --to=@- 

---

Основные понятия

Модель репозитория

Репозиторий Jujutsu — это направленный ацикличный граф (DAG), в котором каждый узел — это изменение(change), содержащее:

• Снимок файловой системы в директории репозитория.

• Конфликты файлов (локальны, не блокируют работу, в отличие от Git).

• Один или несколько родительских изменений (корневое не имеет родителей).

• Описание изменения (commit message).

Дополнительно:

• «Изменение» в JJ — это аналог «коммита» в Git (но с более стабильным ID).

• Одно из изменений — рабочее (@), аналогично HEAD в Git.

• Закладки (bookmarks) — уникальные строки, ссылающиеся на изменения, для Git это branch.

• Поддержка удалённого репозитория — закладки синхронизируются как BOOKMARK@REMOTE.

---

Основные правила

• При перемещении @ рабочая директория обновляется.

• Если удалить изменение, на которое указывает @, создаётся новое пустое изменение.

• Изменения без файлов, описания и ссылок исчезают.

• Изменение — это diff. Перемещение может вызвать конфликты.

• Почти все команды действуют на @ по умолчанию, но могут принимать --revision.

---

Конфликты файлов

• Чтобы разрешить конфликт, достаточно отредактировать файл и убрать маркеры (<<<<<<<, =======, >>>>>>>).

• Для бинарных файлов — замените файл нужной версией.

• Используйте jj restore, если нужно откатить изменения.

---

Работа с удалённым репозиторием

jj git fetch

• Получает изменения из удалённого репозитория.

• Несовместимые закладки создают конфликт закладок (аналог merge conflict).

Как разрешить:

1. Слить изменения: jj new CHANGE-ID-1 CHANGE-ID-2, затем jj bookmark move BOOKMARK-NAME.

2. Выбрать одно: jj bookmark move BOOKMARK -r CHANGE-ID.

3. Сделать rebase: jj rebase -b CHANGE-ID-2 -d CHANGE-ID-1, затем jj bookmark move.

jj git push

• Отправляет изменения в удалённый репозиторий.

• Изменённые изменения создаются заново (аналог --force).

• Основная ветка защищена — изменения нужно явно пушить с --ignore-immutable.

• jj git push -c @ создает новую временную закладку (git автоматически предложит создать MR)

Про закладки:

• Локальные закладки копируются в удалённый репозиторий.

• Если закладка не синхронизирована — push выдаёт ошибку, нужно сначала сделать jj git fetch.

jj bookmark track

• Связывает локальную закладку с удалённой веткой.

• Отслеживать изменения из удалённого репозитория при jj git fetch, упрощать push и автоматически разрешать конфликты закладок.

• Синтаксис:

  • jj bookmark track <локальная_закладка> <удалённая_ветка@удалённый_репозиторий>

  • jj bookmark track <имя_ветки> (если локальная и удалённая ветки совпадают)

• Пример:

  • jj bookmark track develop develop@origin

• Просмотр:

  • jj bookmark list --tracked (показать только отслеживаемые)

---

Команды настройки

jj config set --user user.name  МОЁ_ИМЯ jj config set --user user.email МОЙ_EMAIL jj config set --user ui.editor  МОЙ_РЕДАКТОР jj config edit --user           # Открыть конфиг 

Вместо --user можно использовать --repo для конфигурации внутри конкретного репозитория.

---

Команды репозитория

jj git init              # Инициализация репозитория jj git clone URL [DEST]  # Клонирование репозитория jj git init --colocate   # Добавление JJ в существующий git-репозиторий 

---

Редактирование локального репозитория

Более подробно читаем в документации

---

Примеры живой работы с jj

Давайте посмотрим, как jj справляется с типичными задачами, используя только свои команды и концепции.

Тут я решил показать возможности revsets
jj log -r "@ | bookmarks() & author('Ads')":

jj log показывает историю изменений в репозитории. Каждый блок соответствует одному изменению (коммиту) и содержит несколько ключевых элементов:

• Рабочая копия — на нее указывает @

• ○ (локальное изменение) — это то, что вы можете свободно менять.

• ◆ (неизменяемое) — это коммит, который вы уже отправили на удалённый сервер и трогать его не стоит (хотя jj позволяет и это с флагом -ignore-immutable).

• ID изменения — уникальный короткий идентификатор, например szqumyoy, szq — alias для данного изменения.

• Автор и email — кто сделал изменение.

• Дата и время — когда было сделано изменение.

• Закладки (bookmarks) и/или ветки — метки, указывающие на изменение, например master или master@origin.

• Локальная закладка — те, что ещё не синхронизирована с удалённым репозиторием имеют символ *

• ID Git-коммита — хэш коммита в Git (для совместимости). Например, 59d9790f.

• Сообщение коммита — описание сделанных изменений.

• ~ (elided revisions)— Это пропущенные изменения. jj иногда скрывает их в данном случае из-за «фильтров».

jj status (alias st):

• Здесь мы видим какие изменения сейчас есть в нашей рабочей копии.

• Буквы A, M означают тип изменения файла.

• Тут же мы видим ссылку на: @ — это изменение и @- — родителя.

Из скриншота видно, что тут явно 2 вида изменений. Я хочу чтобы было красиво.

jj split:

Открывается diff-editor — это мощный инструмент, который позволяет работать с изменениями, а не с файлами. Он помогает поддерживать чистую и понятную историю, не прибегая к сложным манипуляциям.

Выбираем нужные нам изменения и жмем c (Это тут такое управление, если что можно все делать мышкой)

И попадаем в интерфейс jj commit, для ввода description

jj split автоматически разбил изменения на 2 коммита и выстроил их в линейку, посмотрим на jj.

Перенесем закладку на новые изменения. Переносить на @ нельзя там пусто, так что --to=@-

Workflow: «Черновики» и их «уборка»

Лично мне очень нравится workflow, когда я пишу код, быстро сохраняю свои наработки и пишу дальше. В моей голове это «чек-поинты», к которым я в любой момент могу вернуться.

Затем, когда функционал реализован, я привожу историю в порядок:

1. jj squash — объединяю все «черновые» коммиты в один.

2. jj split — разделяю одно большое изменение на несколько логичных. В итоге история становится чистой и понятной.

Можно заметить что id vxzxpzxm, ktvwvoqs не поменялись, а их git-hash изменился.

Push и автоматический MR

jj умеет работать с удалёнными репозиториями очень элегантно. Например, jj git push -c @ не просто отправляет изменения, но создает отдельную новую ветку и сразу предлагает ссылку на создание Merge Request, если ваша система это поддерживает. Но можно и просто:

И вновь jj удивляет и сразу предлагает ссылку на MR

Финал

Jujutsu — это не замена Git, а его улучшенная оболочка. Он решает многие проблемы, которые так раздражают в классическом Git:

• Грязная история и мучительный rebase -i.

• Сложности с git add и git stash.

• Страх «сломать» репозиторий, ведь у jj есть jj undo.

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