Командная строка

Из терминала задают вопросы двух видов, и 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 ещё не сделан. Все глаголы реализованы; не хватает лишь пути установки.

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