00:00:00Всем привет! Меня зовут Скотт Чакон, я генеральный директор Git Brother.
00:00:02Я проведу короткую демонстрацию нового интерфейса командной строки Git Brother CLI.
00:00:06Так что, если вы привыкли работать в терминале,
00:00:08и хотите использовать Git Brother программно,
00:00:11новый CLI — это отличный инструмент для таких задач.
00:00:14Давайте приступим. Начнем с репозитория.
00:00:18У меня тут небольшой проект на Rust,
00:00:20на примере которого мы разберем рабочий процесс в Git Brother CLI.
00:00:23По сути, это полноценная замена Git. После установки
00:00:27вам будет доступна команда "but". Она станет основным интерфейсом вместо git.
00:00:32Можно вводить просто "but" или "but status" — это одно и то же.
00:00:35Команда покажет текущее состояние проекта.
00:00:38Вывод очень похож на стандартный "git status".
00:00:41Мы видим, что четыре файла были изменены.
00:00:44Пара файлов не отслеживается, пара — отредактирована.
00:00:47Есть новые и измененные файлы, но в выводе "but"
00:00:50статус просто выводит список из четырех позиций. Это ваши правки, верно?
00:00:55Это то, что вы изменили. И теперь их можно закоммитить
00:00:59любым удобным способом. Можно просто запустить "but commit".
00:01:02Это создаст временную ветку. Давайте попробуем.
00:01:05Если снова ввести "but status", мы увидим, что все правки теперь в одном месте.
00:01:11Также можно ввести "but status -f" или "--files".
00:01:15Это покажет список файлов, вошедших в данный коммит.
00:01:18Но допустим, мы не хотим объединять всё в один коммит.
00:01:21Часть относится к Clod, часть — к Readme,
00:01:24а часть — это правки кода. По логике, это три разные задачи,
00:01:28поэтому нам нужно три отдельных коммита. Давайте отменим действие.
00:01:31Откатить коммит можно командой "uncommit".
00:01:36И вот мы вернулись в исходную точку. Временная ветка всё еще тут.
00:01:40Ее можно удалить, но давайте просто используем ее снова.
00:01:44Я переименую ее в "Clod stuff".
00:01:48Теперь у меня новая ветка, и я могу добавлять в нее файлы,
00:01:53как в "git add". Пишем "but stage G0 H0".
00:01:58Это короткие коды для нужных файлов.
00:02:01Конечно, можно вписать и полный путь,
00:02:04но мы старались сделать работу максимально быстрой. Теперь смотрим:
00:02:08файлы добавлены в ветку "Clod stuff", и я могу сделать коммит с флагом -o.
00:02:12Это значит "only staged" — только то, что подготовлено. Обычный "commit"
00:02:15закоммитит всё: и подготовленное, и неподготовленное.
00:02:18Это станет понятнее, когда у нас будет больше веток,
00:02:20а пока сделаем этот коммит. Теперь у нас есть ветка с одним коммитом
00:02:25и пара оставшихся правок.
00:02:28И вот тут начинается самое интересное. В отличие от Git,
00:02:31если я хочу закоммитить Readme,
00:02:34отправить его на сервер и открыть PR...
00:02:37Находясь в ветке "Clod",
00:02:41мне пришлось бы прятать изменения (stash), переходить, добавлять Readme, коммитить
00:02:44и только потом пушить для пул-реквеста.
00:02:45В Git Brother мы можем работать с параллельными ветками.
00:02:50Я пишу "but branch new read-me", и видите — появляется новая ветка,
00:02:55куда я могу добавить нужный файл.
00:03:00И сразу его закоммитить.
00:03:01Если мы взглянем на список измененных файлов,
00:03:07то увидим коммит с двумя файлами Clod
00:03:09и отдельно ветку с правками Readme. Опять же,
00:03:11я могу сделать то же самое. Ввожу "commit".
00:03:17Флаг "-c" (create) позволяет создать новую ветку прямо при коммите. Так,
00:03:21а что у нас там осталось? Совсем забыл. Ах да,
00:03:25команда "read".
00:03:27CLI возьмет последние незакоммиченные правки,
00:03:32создаст новую ветку и сразу зафиксирует их там.
00:03:35Теперь у нас три ветки.
00:03:38Они полностью независимы друг от друга.
00:03:39Все эти изменения по-прежнему находятся в нашей рабочей директории.
00:03:42Мы физически ничего не переключали в файловой системе.
00:03:44Мы просто создаем коммиты в памяти.
00:03:46Теперь я запускаю "but push", и система спрашивает: что отправить?
00:03:50Хотите отправить всё? В каждой ветке по одному новому коммиту.
00:03:53Или только одну? Давайте отправим только Readme.
00:03:57Допустим, на данный момент готова только она.
00:03:59Выбираем ее, и она уходит на сервер.
00:04:02Проверяем статус снова:
00:04:03по значку в списке видно, что эта ветка отправлена,
00:04:06а остальные пока только локальные.
00:04:08Git Brother очень удобен для одновременной работы с ветками,
00:04:11но он также поддерживает стековые ветки (stacked branches).
00:04:13Давайте создадим новую задачу
00:04:17на базе одного из уже сделанных коммитов,
00:04:19выстроив их в стек.
00:04:20Так мы сможем слить нижний коммит и продолжить работу в верхнем.
00:04:23Допустим, нам нужна стековая ветка.
00:04:26Мы хотим отправить команду "read" на проверку и слияние,
00:04:30но при этом продолжать работу над ней.
00:04:32Здесь лучше использовать стек, а не независимую ветку из-за зависимости кода.
00:04:35Делается это так:
00:04:38пишем "but branch new -a" (anchor — точка привязки),
00:04:42указываем ветку "read command" и называем новую — "read more".
00:04:46Теперь, если посмотреть на структуру,
00:04:48мы увидим, что одна ветка базируется на другой.
00:04:50Давайте внесем правки.
00:04:52Сейчас код берет 10 сообщений для отображения.
00:04:57Сделаем 20. И здесь тоже поменяем.
00:05:02Мы видим изменение и иконку замка. Это потому,
00:05:09что мы меняем файл, который уже был закоммичен в другом месте.
00:05:11Он привязан к конкретному коммиту.
00:05:13Мы можем закоммитить это только поверх, так как меняем внедренный там код.
00:05:16Команда "diff" наглядно показывает,
00:05:20какие именно фрагменты (hunks) изменились. Теперь можно
00:05:25закоммитить это. Готово.
00:05:28Чтобы показать, как легко управлять коммитами,
00:05:32я продемонстрирую следующее:
00:05:33через "status -f" видим все файлы.
00:05:37Давайте поделимся этим. Мы уже видели "push",
00:05:40который отправляет ветки в удаленный репозиторий,
00:05:42но есть еще команда "PR", которая открывает пул-реквесты. Пишем "but PR".
00:05:46Для каких веток нужно создать пул-реквесты?
00:05:48Давайте создадим сразу для всех.
00:05:50Для каждой откроется редактор с вопросом:
00:05:54какое описание сделать для PR? Я напишу что-нибудь простое.
00:05:57И вот наши PR готовы. Теперь,
00:06:01когда они открыты, мы видим номера: первый, второй...
00:06:04Это номера пул-реквестов и их сообщения.
00:06:06Мы просто использовали те же названия.
00:06:08С помощью флага "-v" (verbose — подробно)
00:06:10можно увидеть URL-адреса для каждого из них.
00:06:12Давайте взглянем на один.
00:06:14Вот PR с изменениями Readme: мы видим,
00:06:18что там всего один коммит и правки только в одном файле. Всё изолировано.
00:06:23А вот стековый PR.
00:06:24Если мы его откроем, то увидим,
00:06:28что создана цепочка. Первый,
00:06:30нижний PR, направлен в ветку main.
00:06:35А второй (на который можно перейти отсюда) направлен в первый.
00:06:39То есть стеки веток обрабатываются корректно.
00:06:41Посмотрим, что будет при интеграции кода.
00:06:43Переходим в пул-реквест с Readme. Допустим,
00:06:46всё отлично, я его мержу. Теперь изменения в основной ветке.
00:06:49Запускаем "but pull --check" для проверки.
00:06:55Также можно использовать "but fetch" — это сработает так же.
00:06:57Кстати, CLI периодически делает fetch в фоновом режиме.
00:07:00Вы могли это заметить при вводе других команд.
00:07:02Система сообщает о запуске фонового процесса. Видим, что ветка интегрирована.
00:07:06Она влита в апстрим. И когда мы запускаем "but pull",
00:07:10происходит следующее: CLI получает новые данные,
00:07:13делает ребейс остальных веток и удаляет уже влитую ветку.
00:07:16Мы видим, что локально она исчезла.
00:07:19Итак, с той задачей покончено,
00:07:22остальные ветки обновлены, и при желании их можно снова пушнуть.
00:07:25Если в какой-то момент
00:07:29вы захотите вернуться к обычному Git, введите "but tear-down".
00:07:33Вам предложат выбрать одну из веток.
00:07:36По умолчанию вы окажетесь на той ветке, с которой начинали.
00:07:39При этом все ветки, над которыми мы работали, никуда не денутся.
00:07:43Просто обычный Git может держать активной только одну. Теперь вы снова в обычном режиме.
00:07:47Используйте "setup" и "tear-down" для входа и выхода из режима Git Brother.
00:07:50Это удобно, когда нужно работать с кучей веток или вернуться к стандартным коммитам.
00:07:55Но даже в режиме Git Brother большинство команд git
00:08:00продолжают работать. Можно написать "git show" для любого объекта.
00:08:04Команды "git log" или "git logs" тоже работают без проблем.
00:08:08Все команды чтения данных в порядке.
00:08:13Мы лишь берем на себя управление процессом коммитов.
00:08:16Если вы просто переключитесь (checkout) на ветку средствами git, Git Brother поймет это
00:08:21и автоматически свернет свои надстройки.
00:08:24Всё вернется в привычное русло.
00:08:26И последнее: у всех этих команд есть
00:08:30флаг "--json". Если вам нужен статус в формате JSON,
00:08:34просто добавьте этот флаг. То же самое с просмотром коммита.
00:08:41Практически любая команда
00:08:44поддерживает этот формат (полный список можно глянуть в "but help").
00:08:48Используйте флаги "--json" или "-j".
00:08:52Благодаря этому CLI очень легко автоматизировать скриптами. Даже
00:08:56диффы можно выводить в формате JSON,
00:09:00что, по-моему, очень круто.
00:09:01Это был краткий обзор возможностей Git Brother по сравнению с обычным Git.
00:09:05Напомню: вы можете внедрить его в любой git-репозиторий.
00:09:08Запускаете "but setup" и начинаете работать.
00:09:12Тут вам и JSON-вывод, и управление несколькими ветками одновременно,
00:09:15и работа со стеками.
00:09:17Интеграция с GitHub, управление пул-реквестами —
00:09:20всё это доступно сразу через команды "but".
00:09:24В любой момент можно вернуться к Git,
00:09:26хотя большинство его команд и так доступны в нашей среде.
00:09:29Просто выполните "tear-down" или переключите ветку — система всё почистит.
00:09:33Попробуйте сами уже сегодня.
00:09:35Заходите на [gitbrother.com/cli](https://www.google.com/search?q=https://gitbrother.com/cli), скачивайте и тестируйте.
00:09:39Залетайте в наш Discord и делитесь впечатлениями. Спасибо!