Командний рядок

З термінала ставлять питання двох видів, і gitcito відповідає на обидва.

Перше — «покажи мені це»: ви в клоні, на щось треба подивитися, і застосунок — слушне для цього місце. Такі виклики відкривають вікно якнайближче до того, про що ви запитали.

Друге — «скажи зараз»: гачок, завдання CI або ви самі посеред конвеєра, кому потрібна відповідь і код виходу, а не вікно. Такі виклики взагалі не запускають застосунок: вони пишуть у stdout і сходять з дороги.

gitcito .                        # відкрити цю теку
gitcito blame src/api.ts -l 84   # …на blame цього рядка
gitcito doctor                   # без вікна: перевіряє репозиторій, код 1 при провалі

Встановлення

Палітра команд (⌘K) → Встановити команду 'gitcito' у PATH. У macOS створюється символічне посилання на невеликий shim у /usr/local/bin або /opt/homebrew/bin, а права адміністратора питають лише тоді, коли жоден із них вам не доступний на запис. У Linux він потрапляє до ~/.local/bin, де прав не треба взагалі. Та сама команда видаляє його. Windows поки не підтримується.

Далі, за бажанням:

gitcito completions zsh >> ~/.zshrc     # або bash, або fish

Що можна відкрити

Команда	Відкриває
`gitcito [шлях]`	Репозиторій (типово — поточний каталог)
`gitcito open <назва>`	Репозиторій за назвою вкладки — `gitcito open api`
`gitcito diff`	Незакомічені зміни
`gitcito graph`	Граф комітів
`gitcito show <ref>`	Один коміт — `HEAD~2`, теґ, короткий хеш
`gitcito blame <файл>`	Blame файлу; з `-l 84` — одразу на рядок
`gitcito search <запит>`	Пошук по коду з уже введеним запитом
`gitcito stack`, `stash`, `reflog`, `conflicts`, `todos`, `chat`, `settings`	Відповідну панель
`gitcito ci`, `clean`, `bisect`, `absorb`, `snapshots`, `insights`, `terminal`	…і так далі

gitcito help verbs друкує повний перелік. Три опції діють для всіх: -n <назва> задає показувану назву вкладки, -g <група> кладе її у вкладку групи (створюючи групу за потреби), а -l <n> обирає рядок.

Gitcito працює в єдиному екземплярі: запуск gitcito при відкритому застосунку передає запит цьому вікну, а не запускає другу копію. Уже відкритий шлях — вкладкою чи всередині групи — отримує фокус, а не дублікат. Каталог, який ще не є репозиторієм, усе одно відкриється, пропонуючи «ініціалізувати репозиторій тут».

Відповідь у терміналі

Ці команди друкують результат і завершуються. Вікно не відкривається, і застосунок навіть не мусить бути запущеним.

`gitcito status`

Гілка, відстеження, попереду/позаду, робоче дерево, схованки й — якщо репозиторій її містить — контрольний список перед push із .gitcito.json. Завершується кодом 1, коли в робочому дереві є конфлікти, тож gitcito status || echo заблоковано працює.

`gitcito doctor [--fix]`

Виконує ті самі перевірки, що й панель конфігурації репозиторію: версію Node, підмодулі, LFS, core.hooksPath, обов’язкові файли. Завершується кодом 1, якщо якась перевірка провалилась — у цьому вся суть: правила, які оголошує репозиторій, мало чого варті, якщо їх бачить лише той, у кого відкритий інтерфейс:

- run: gitcito doctor          # у CI, перед усім дорогим

--fix застосовує полагодження, які доктор уміє робити (ініціалізувати підмодулі, lfs pull, задати core.hooksPath, скопіювати файл з його прикладу), і перевіряє знову. Він ніколи не виконує команду, що надійшла з конфігурації, — набір полагоджень замкнений.

Попередження не валять запуск. Попередження означає, що доктор чогось не зміг визначити, а не що щось не так; валити на них збірки зробило б цей файл надто дорогим для впровадження.

`gitcito commit-check [файл]`

Перевіряє повідомлення коміту. Без аргументу читає .git/COMMIT_EDITMSG; -m "…" перевіряє рядок. Він знає, що оголосив репозиторій: невідома область — помилка, коли .gitcito.json перелічує області, і лише порада щодо стилю, коли ні. Підключіть до гачка:

# .husky/commit-msg
gitcito commit-check "$1"

`gitcito config init | show | check`

init читає репозиторій і пропонує .gitcito.json із того, що вже є, — .nvmrc, .gitmodules, .env.example без .env, області комітів, які використовує історія. --dry-run друкує замість запису. show виводить поточний файл; check перевіряє його й перелічує кожне поле, яке було б відкинуте.

`gitcito repos [фільтр]`

Кожен репозиторій, який знає Gitcito, — спершу відкриті вкладки, потім недавні — разом із групою. --paths друкує самі шляхи, по одному в рядку, для скриптів:

cd "$(gitcito repos --paths api | head -1)"

Gitcito як редактор git

gitcito editor install

задає core.editor і sequence.editor рівними gitcito --wait. Відтоді git commit (без -m), git commit --amend, git tag -a і git rebase -i відкривають свій файл у Gitcito замість vim — із лічильником символів і тими самими підказками до повідомлення, що показує композитор.

Редактор, який Gitcito відкриває на запит git

Ключове слово тут — чекає: git заблокований на цьому діалозі. Тому

Зберегти й продовжити записує файл назад, і git іде далі.
Скасувати записує порожній файл, що git читає як перервати.
Закрити діалог у будь-який інший спосіб — Escape, тло, вихід із Gitcito — означає скасувати. Термінал, що чекає вічно, був би значно гіршим за повідомлення, яке доведеться набрати заново.

Додайте --local, щоб обмежитись одним репозиторієм, і скасуйте через gitcito editor uninstall.

Чого він не робитиме

Жодне термінальне дієслово не змінює репозиторій. doctor --fix — єдиний виняток, і його полагодження — фіксований перелік, який файл конфігурації не може розширити.
repos лише читає. Запущений застосунок володіє своїм файлом налаштувань; CLI читає його й ніколи не пише.
Дієслово, невідоме встановленому застосунку, ігнорується, а не відхиляється: новіший shim зі старішим застосунком усе одно відкриє репозиторій.
Для Windows shim іще не зроблено. Усі дієслова реалізовані; бракує лише шляху встановлення.

Див. також: Робочі простори, вкладки та групи · Конфігурація репозиторію · Коміти