Git GUI моей мечты
Я разработчик игр и мобильных приложений. Я написал немало кода на C++ и Swift. И, как и многие из вас, я пользуюсь системами контроля версий, в частности, гитом.
Гит имеет максимально функциональный command-line интерфейс и десятки если не сотни приложений для работы с ним локально при помощи графического интерфейса, которые умеют выполнять только часть функционала гита. Беда в том, что я пишу код уже 10 лет, но никак не нашел идеальный (подходящий для меня) git GUI клиент. Пример: недавно вышел Github Desktop. Я его использовал до тех пор, пока мне не понадобилось сделать checkout на конкретный коммит. И я испытал уже привычную боль от того, что данное приложение так делать не умеет. И вновь вернулся в терминал (с автодополнением для гита). И такие вещи есть в каждом GUI приложении для гита. Однако, я сюда пришел не критиковать их. Уверен, что вы и без меня имеете много претензий к этим приложениям. Я долго думал о том каким должно быть идеальное git GUI приложение. Это были мимолетные обрывки желаний, из которых трудно собрать что-то цельное. И совсем недавно эти обрывки мыслей у меня собрались в единую картину. Ниже я опишу это в формате ТЗ (технического задания) в максимально понятной форме.
Идеальный Git GUI клиент
Важно чтобы интерфейс не был суперусложнен. Если юзер откроет прилажку и увидит больше 20 кнопок, то идея отстой. Бóльшая часть пользователей переключаясь на консоль для работы с гитом пишут команду git status чтобы узнать список файлов с измененным статусом. Потому наше приложение должно почти на весь экран показывать список файлов в виде иерархии, которые имеют измененный статус (примерно как проводник/finder). Туда будет входить все, что мы можем увидеть командой git status : измененные файлы, untracked файлы, добавленные и удаленные (возможно, какой-то статус я забыл). Каждый файл должен как и в консоли отображаться либо красным цветом, либо зеленым, что показывает его добавленность в коммит. На любой файл можно кликнуть правой кнопкой мыши или нажать на три точки в правой части строки чтобы вызвать контекстное меню. В контекстном меню можно добавить файл если он не добавлен ( git add команда в терминале), сделать reset если он добавлен, удалить если он не находится в индексе (clean). Еще можно кликнуть на папку правой кнопкой и добавить всю папку ( git add folder ). Аналогично работает reset. Еще можно добавить в индекс все маленькой кнопкой в верхнем левом углу дерева файлов. Можно кликнуть по строчке с файлом чтобы открыть дифф по нему на весь экран.
Сверху окна есть отдельный заголовочный блок примерно как в Xcode с названием ветки и статусом того, что сейчас происходит (pulling, pushing, idle). Это все. То есть, окно по-умолчанию только показывает статус: нынешнюю ветку и статус файлов.
Когда пользователь намерен сделать какое-либо действие ( git log — посмотреть историю, git branch — операция с ветками, git commit — осуществление коммита, git push — загрузка в remote, git pull — загрузка из remote, git remote — управление списком remote и т.д.) он должен зажать tab чтобы вызвать селектор действий (прям как селектор оружия в GTA 5).
Далее пользователь наводит указатель мыши на нужную команду и кликает на нее. После этого происходит вызов команды если это команда без аргументов (например, pull, push, fetch). Если нужно указать аргументы, то пользователь кликает правой кнопкой на название команды (например, push) и появляется соответствующее модальное диалоговое окно с вводом аргументов (цель remote и имя ветки, а также галочка force), которые указываются мышью или горячими клавишами. К этом моменту изначально зажатый tab можно уже отпустить. Если кликнуть за пределами модального окна или нажать esc, то модальное окно закроется и вызов команды будет отменен. Если же в этом модальном окне указать аргументы и нажать кнопку push, то начнется выполнение команды. Процесс выполнения команды будет отображен на верхней панели под названием ветки.
Еще одно важное преимущество терминала над остальными git GUI приложениями это возможность склеивать команды последовательно при помощи операторов && и ||. Например, я лично в работе часто использую такую последовательность для подлития в свою ветку той ветки, от которой моя ветка была срезана:
git checkout dev && git pull && git checkout — && git merge —
Данная последовательность выполняет 4 операции:
- переключается на ветку dev
- скачивает последние изменения ветки dev
- переключается обратно на ветку, на которой мы находились до ветки dev
- вливает ветку dev в нынешнюю ветку
Оператор && устроен таким образом, что если одна из команд остановится из-за ошибки, то выполнение всех остальных команд не начнется. Это суперудобно, но я не видел ни одного git GUI клиента, который бы умел склеивать команды в последовательность (если вы такой знаете, то укажите это в комментариях). И я придумал как в моем потенциальном абстрактном идеальном git GUI приложении моей мечты это будет выполнено.
Для того, чтобы указать команду и добавить после нее другую команду нужно сделать то же самое, что и для указания обычной команды, но помимо кнопки tab нужно еще зажать alt (или shift, тут нужно еще подумать). То есть, в привычном уже круговом селекторе мы выбираем команду checkout, указываем ветку dev, жмем ok в окошке, где мы указывали ветку. Однако из-за того, что в момент появления окошка помимо клавиши tab была зажата еще и клавиша alt, команда checkout не начинает выполняться сразу после нажатия ok, а добавится в список, который появляется в верхнем левом углу, а селектор продолжит отображаться в ожидании новой команды (tab держать уже не нужно — селектор остается открытым после указания первой команды с зажатым alt). Также указываем другие команды левой или правой кнопкой мыши как обычно — они пополняют список команд. Когда мы завершили этот список жмем еще раз tab (или esc если передумали), селектор закрывается, команды начинают выполняться, их статус виден на верхней панели статуса. Признаться честно, на эту идею меня подтолкнул смелая фича в игре Red Alert 2. Там можно зажать клавишу z и указать последовательность точек куда следует идти юниту. Я считаю, что это гениальная фича, которой очень не хватает в других популярных стратегиях.
Отдельная фича, которая сделает использование истории гита удобнее, это хэширование хэша (да, именно так) коммита в виде эмоджи. Объясню на примере. Когда я смотрю историю коммитов, я вижу список труднозапоминаемых длинных хэшей типа такого
В этом ничего нет плохого пока не нужно запомнить хэш и сверить его с другим хэшем. Даже сокращенный вариант запомнить не так легко. Потому у меня появилась идея сделать хэши коммитов более запоминаемыми — по каждому хэшу вычисляем хэш в виде эмоджи. Тогда это будет выглядеть примерно так.
Эмоджи намного лучше запоминаются человеком, чем безымянные шестнадцатеричные хэши. Если везде, где мы ни показывали хэши коммитов (история или статус pull’а), показывать их эмоджи хэши, то пользователь лучше будет помнить на каком он коммите работает прям сейчас, и меньше будет ошибок когда он забыл влить другую ветку, запушить или запулить изменения. Вообще было бы здорово если бы эмоджи-хэш использовался везде: на github, bitbucket, teamcity. Это позволило бы проще сверять коммиты билдов с коммитами в истории.