Русский
Русский
English
Статистика
Реклама

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 операции:

  1. переключается на ветку dev

  2. скачивает последние изменения ветки dev

  3. переключается обратно на ветку, на которой мы находились до ветки dev

  4. вливает ветку dev в нынешнюю ветку

Оператор && устроен таким образом, что если одна из команд остановится из-за ошибки, то выполнение всех остальных команд не начнется. Это суперудобно, но я не видел ни одного git GUI клиента, который бы умел склеивать команды в последовательность (если вы такой знаете, то укажите это в комментариях). И я придумал как в моем потенциальном абстрактном идеальном git GUI приложении моей мечты это будет выполнено.

Для того, чтобы указать команду и добавить после нее другую команду нужно сделать то же самое, что и для указания обычной команды, но помимо кнопки tab нужно еще зажать alt (или shift, тут нужно еще подумать). То есть, в привычном уже круговом селекторе мы выбираем команду checkout, указываем ветку dev, жмем ok в окошке, где мы указывали ветку. Однако из-за того, что в момент появления окошка помимо клавиши tab была зажата еще и клавиша alt, команда checkout не начинает выполняться сразу после нажатия ok, а добавится в список, который появляется в верхнем левом углу, а селектор продолжит отображаться в ожидании новой команды (tab держать уже не нужно - селектор остается открытым после указания первой команды с зажатым alt). Также указываем другие команды левой или правой кнопкой мыши как обычно - они пополняют список команд. Когда мы завершили этот список жмем еще раз tab (или esc если передумали), селектор закрывается, команды начинают выполняться, их статус виден на верхней панели статуса. Признаться честно, на эту идею меня подтолкнул смелая фича в игре Red Alert 2. Там можно зажать клавишу z и указать последовательность точек куда следует идти юниту. Я считаю, что это гениальная фича, которой очень не хватает в других популярных стратегиях.

Отдельная фича, которая сделает использование истории гита удобнее, это хэширование хэша (да, именно так) коммита в виде эмоджи. Объясню на примере. Когда я смотрю историю коммитов, я вижу список труднозапоминаемых длинных хэшей типа такого

3a962a4a5979b338e4bfce1333b3009529c0ad08

d8def5c1b13a83a1df8797fab3d34760596df692

cffcf32979526f2e2d26c06fe0b73666a7ca0e87

2757ed191106b51b729c5437334d9d19b0d081b8

0fef00c89e8d60e41a452ffc31a8300b551116be

5e4fe2033549b89ef86834e2fcba350fa5099443

886602d02ec39f853c9b708957f27c3fbb51e66c

250ce1cd7b0b6ec415898e0a26cda49a2d326bd3

4a4a5e0f6257bb6c179981c4fb69011be7bbe53d

В этом ничего нет плохого пока не нужно запомнить хэш и сверить его с другим хэшем. Даже сокращенный вариант запомнить не так легко. Потому у меня появилась идея сделать хэши коммитов более запоминаемыми - по каждому хэшу вычисляем хэш в виде эмоджи. Тогда это будет выглядеть примерно так.

3a962a4a5979b338e4bfce1333b3009529c0ad08

d8def5c1b13a83a1df8797fab3d34760596df692

cffcf32979526f2e2d26c06fe0b73666a7ca0e87

2757ed191106b51b729c5437334d9d19b0d081b8

0fef00c89e8d60e41a452ffc31a8300b551116be

5 5e4fe2033549b89ef86834e2fcba350fa5099443

886602d02ec39f853c9b708957f27c3fbb51e66c

250ce1cd7b0b6ec415898e0a26cda49a2d326bd3

4a4a5e0f6257bb6c179981c4fb69011be7bbe53d

Эмоджи намного лучше запоминаются человеком, чем безымянные шестнадцатеричные хэши. Если везде, где мы ни показывали хэши коммитов (история или статус pullа), показывать их эмоджи хэши, то пользователь лучше будет помнить на каком он коммите работает прям сейчас, и меньше будет ошибок когда он забыл влить другую ветку, запушить или запулить изменения. Вообще было бы здорово если бы эмоджи-хэш использовался везде: на github, bitbucket, teamcity. Это позволило бы проще сверять коммиты билдов с коммитами в истории.

Заключение

Это все. Буду рад любой критике и предложениям в комментариях. Отвечу на вопрос зачем я делюсь идеей тут, а просто не начну реализовывать это сам. Я сам занимаюсь разработкой игр, на данный момент работаю в компании Playtika, а в свободное время разрабатываю приложение для работы с SQLite https://sqliteman.dev. Я бы сам с радостью занялся разработкой данного git GUI клиента, но у меня нет времени. Я буду очень рад если бы кто-то другой это сделал, при этом мне совершенно не жалко если кто-то это сделает без упоминания источника идеи. Я уверен, что идея не стоит ничего в отличие от реализации. И буду очень счастлив если у меня будет git GUI приложение моей мечты.

Источник: habr.com
К списку статей
Опубликовано: 27.09.2020 18:10:26
0

Сейчас читают

Комментариев (0)
Имя
Электронная почта

Git

Version control

Gui

Идея

Идея проекта

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru