00:00:00Всем привет, это Скотт, генеральный директор GitButler.
00:00:02Сегодня я расскажу о некоторых крутых функциях GitButler и дам
00:00:05общий обзор возможностей этого Git-клиента.
00:00:07У меня тут есть пример проекта. Это небольшой клон Twitter или X. Я назвал его Y.
00:00:12Сейчас я добавлю правки, которые уже подготовил, и мы разберем,
00:00:16как создавать коммиты, ветки, параллельные ветки и как
00:00:20создавать стековые ветки. Если я изменю файлы, вы увидите нечто,
00:00:25похожее на вывод команды git status: список измененных файлов в рабочей директории.
00:00:30Что с ними делать? Как их закоммитить? Здесь мы можем их осмотреть.
00:00:34Я могу заглянуть в CSS приложения, в боковую панель, в индекс... Видите, я внес пару мелких правок.
00:00:39И теперь я хочу создать новую ветку и закоммитить эти изменения туда.
00:00:45Есть несколько способов это сделать. Можно нажать «commit to new branch»
00:00:49или явно создать новую ветку здесь. Я создам независимую ветку,
00:00:54а не зависимую. К стекингу мы перейдем через секунду.
00:00:57Даем название, создаем ветку, и теперь доступно несколько действий. Можно
00:01:03просто что-то закоммитить, верно? Например, только файл application.css,
00:01:08либо перетащив его в рабочую область (lane) и создав коммит, либо начав коммит прямо отсюда.
00:01:15Можно написать короткое сообщение в маленьком поле или развернуть его
00:01:19и составить подробное описание коммита. Пока сделаем попроще.
00:01:27Также я могу выбрать, что именно войдет в этот коммит. У меня сбоку три файла.
00:01:34Я могу не только исключить файл целиком, но и зайти в него и выбрать конкретные строки.
00:01:39Но сейчас давайте закоммитим все изменения. Или даже сделаем два
00:01:44разных коммита. Не будем включать правки боковой панели в этот. Назовем «front-end fixes»,
00:01:48а затем сделаем второй коммит — «sidebar fixes». Теперь в новой ветке два коммита.
00:01:55Я немного ленив, поэтому использую Claude code, чтобы сделать работу за меня.
00:01:59Я изменю тему с синей на красную, и мы попробуем добавить новую отдельную ветку
00:02:04независимо от моих фронтенд-правок. Похоже, готово. Так сайт выглядел раньше.
00:02:09Такая синяя штука в стиле Twitter. Применяю изменения — и вуаля: теперь все красное,
00:02:14и мои фронтенд-правки здесь. Заметьте, это независимые
00:02:18ветки. Если я «отменю применение» (unapply) фронтенд-правок, тема останется красной.
00:02:25Вот что я сделал. И я могу вернуть их обратно. Или наоборот —
00:02:34отменить красную тему, и она исчезнет. Давайте вернем её.
00:02:43Теперь у нас две разные ветки. Самое крутое, что если я, например, отправлю это на GitHub,
00:02:48эти изменения будут отделены друг от друга, но применены одновременно.
00:02:52Это как обычные ветки Git, но вы можете работать над несколькими сразу.
00:02:57Если я продолжу работу над боковой панелью, изменения появятся здесь.
00:03:04Я могу сделать разное: перетащить файл сюда и дополнить (amend) текущий коммит,
00:03:10либо создать новый коммит в этой ветке. Теперь у нас две параллельные ветки.
00:03:14Давайте посмотрим на другой способ. Представим,
00:03:18что красная тема зависит от изменений, сделанных во фронтенде.
00:03:24И я хочу сначала вмержить фронтенд, а уже потом красную тему, или всё вместе.
00:03:29Давайте отменим этот коммит. Сделаем uncommit и оформим это как стековую ветку.
00:03:37Отменяем коммит, убираем стек. Теперь добавим новую зависимую ветку.
00:03:42Нажимаем «создать ветку», выбираем «dependent branch». Другой способ —
00:03:47нажать «создать зависимую ветку» здесь и добавить её поверх «front-end fixes».
00:03:51Назовем sc_red_theme. Видите, теперь эти ветки в стеке (одна над другой).
00:03:58И теперь я могу закоммитить изменения в неё. Такие стековые ветки легко пушить в GitHub.
00:04:06С интеграцией GitHub это очень просто. Также можно
00:04:11создать Pull Request. И если я создам PR для «red theme», но это
00:04:16стековая ветка, система автоматически добавит в описание PR футер о том,
00:04:20что эта ветка зависит от другой целевой ветки. И вам придется
00:04:25либо мержить их вместе, либо сначала «front-end fixes», а потом «red theme».
00:04:30Это очень удобный способ работы со стеками. Если открыть этот PR сейчас, он ссылается
00:04:34на обе ветки в стеке: это часть два, а это часть один, и они зависят друг от друга.
00:04:39Есть еще одна классная фишка — назначение изменений веткам (assigning to branches).
00:04:43Сейчас у меня две области (lanes) и три ветки. Две в стеке, одна независимая.
00:04:48Когда я начинаю вносить правки, я могу назначать
00:04:54фрагменты (hunks) или целые файлы конкретной ветке и продолжать работу.
00:05:00Это как если бы у каждой области был свой независимый индекс (staging area).
00:05:05В обычном Git у вас один индекс для git add, а здесь их может быть несколько.
00:05:09Давайте попробуем. Я добавлю новую функцию — раздел на странице админки.
00:05:14Я помещу это в отдельную ветку, работая в той же директории.
00:05:19Это будет независимая ветка, и я смогу открыть PR только с этими изменениями.
00:05:24Итак, вот панель админа «до». Я внес изменения, добавил список регистраций.
00:05:31Теперь я хочу назначить эти два изменения
00:05:37этой ветке. Если я внесу еще правки, они попадут в «неназначенные» (unassigned), если система не поймет, куда их деть.
00:05:43Но если правки в тех же фрагментах кода, они автоматически останутся в назначенной ветке.
00:05:47Давайте добавим комментарий в контроллер админки.
00:05:55Посмотрим. Так как контроллер админки уже был назначен этой ветке,
00:06:00мне не нужно снова его индексировать. Система понимает: «Ага, это часть того же изменения»,
00:06:05и сама кладет его туда. Давайте создадим коммит. Снова
00:06:10запускаю процесс. Могу развернуть окно для полноценного сообщения. А еще можно использовать ИИ,
00:06:15чтобы сгенерировать текст коммита, взять его за основу и отредактировать.
00:06:19ИИ проанализирует разницу в коде и даст черновик. Готово.
00:06:23Теперь у нас есть коммит в ветке новой страницы регистраций. Сбоку у нас
00:06:27стековая ветка, и я снова могу запушить и создать PR независимо. И если
00:06:31я это сделаю и проверю PR, мы увидим, что хотя все изменения
00:06:37находятся в моей рабочей директории одновременно, они разделены на разные
00:06:42ветки. Я могу зайти и увидеть только правки админки. Очевидно,
00:06:48что затронуты только страницы админа; это живет в своей ветке и своем коммите,
00:06:55не перемешиваясь с остальной работой в директории. Всё в разных ветках.
00:06:58В этом и прелесть работы с параллельными и стековыми ветками в GitButler.
00:07:02Есть много вещей, которые в обычном Git сделать сложно. Покажу пару примеров.
00:07:06Во-первых, мы можем переносить коммиты из ветки в ветку.
00:07:11Если я хочу перенести коммит с регистрациями в ветку
00:07:15красной темы, я просто перетаскиваю его мышкой и удаляю старый стек. Готово.
00:07:20Если нужно объединить (squash) коммиты, я могу перетащить один коммит
00:07:26не только на соседний, но и на любой другой в стеке.
00:07:30Я могу взять этот коммит админки и перенести его вниз, в «sidebar fixes».
00:07:36Могу переместить его ниже по стеку или влить в другой коммит. Теперь
00:07:41изменения админки находятся внутри коммита «sidebar fixes».
00:07:47Можно и наоборот: разделить коммит. Для этого мы добавляем
00:07:52пустой коммит и переносим в него изменения. Добавим
00:07:58пустой коммит в любое место стека, например, вниз. Можно сразу написать текст или сначала перенести файлы.
00:08:02Посмотрим на файлы: тут контроллер админки и боковая панель. Возьмем
00:08:08индекс админки и перетащим в средний коммит. Теперь в этом коммите только индекс админки,
00:08:13а в «sidebar fixes» остались остальные файлы: контроллер и панель. Можно
00:08:20переносить даже отдельные фрагменты кода (hunks). Теперь в одном коммите
00:08:30одна часть правок панели, в другом — вторая. И теперь я могу
00:08:34спокойно изменить текст сообщения коммита.
00:08:41Кстати, редактировать сообщения очень просто. Кроме
00:08:46изменения порядка, склеивания или разделения, я могу просто зайти и
00:08:53написать «часть два». Система автоматически перебазирует (rebase) все верхние коммиты.
00:08:57Еще интересно то, что коммиты можно редактировать прямо на месте. Есть пара быстрых способов.
00:09:01Допустим, мне прилетел отзыв: вместо отступа 0px нужно сделать 10px.
00:09:06Как отредактировать коммит, который не только на четыре позиции ниже, но еще и в другом стеке?
00:09:13С GitButler это проще простого. Давайте внесем изменение.
00:09:16Меняем на 10 пикселей. Инлайновые стили — это «лучшее». Вот наше изменение.
00:09:23Оно заблокировано (locked), потому что мы правим фрагмент кода, который уже был изменен,
00:09:28поэтому оно должно попасть именно в эту ветку. В параллельную ветку его не вынести.
00:09:32Но как его применить? Проще всего взять этот файл
00:09:39и перетащить прямо в нужный коммит. Теперь, если заглянуть в коммит, там
00:09:46уже 10 пикселей, а все последующие коммиты автоматически перебазированы сверху.
00:09:51Другой способ, который мы уже видели: закоммитить это во временный коммит,
00:09:55а затем просто влить его (squash) в целевой. Результат
00:10:02будет таким же: проверяем — отступ стал 10 пикселей.
00:10:07И последний интересный способ — «режим редактирования». Представим, что мы ничего не делали.
00:10:12Там всё еще 0 пикселей. Мы можем зайти в сам коммит
00:10:20и нажать «edit commit». Происходит интересная вещь.
00:10:25Это похоже на то, как Git делает detached head checkout, если вы знакомы с этим.
00:10:30Система переключается на состояние этого конкретного коммита. Вы правите, что хотите,
00:10:36а когда выходите из режима, всё остальное перебазируется поверх. Снова меняем значение.
00:10:39Система видит изменения в файле, мы сохраняем и выходим. И снова —
00:10:46автоматический ребейс. Проверяем — изменение на месте. То есть
00:10:52можно редактировать коммит напрямую, можно через amend, а можно
00:10:57через squash. Есть масса способов манипулировать историей в GitButler.
00:11:01И последнее, что я покажу — это история операций (operations history).
00:11:05В обычном Git это делать очень трудно (вспомните reflog).
00:11:10Многие боятся reflog, но в GitButler абсолютно каждое действие
00:11:15сохраняется в логе операций. Вы можете просмотреть таймлайн и вернуться в любой момент прошлого.
00:11:21Вот эта кнопка. Здесь видна вся история операций за сессию.
00:11:26И я могу переместиться в любую точку времени.
00:11:30Например, хочу вернуться в момент до того, как начал
00:11:37возиться с этими 10 пикселями. Перехожу туда и вижу
00:11:42состояние проекта в тот самый миг. Можно даже вернуться
00:11:47в самое начало нашей сессии. Единственное, что нельзя отменить —
00:11:52это то, что уже ушло на GitHub. Вот эти коммиты уже там, они помечены
00:11:56как upstream, но я вернулся в состояние, когда у меня вообще ничего не было закоммичено.
00:12:01Я могу даже удалить эту ветку и начать заново. Но неважно, что вы сделаете,
00:12:05даже эту отмену можно отменить! Я иду в лог и восстанавливаю (revert) снимок
00:12:11до отмены, и мы снова там, где были. Можно всегда перемещаться
00:12:16во времени. Это очень круто — больше не нужно бояться никаких действий.
00:12:22Если что-то пошло не так или вы просто хотите вернуть всё, как было 10 минут назад,
00:12:26просто откройте таймлайн, выберите момент и нажмите revert. Вот и всё.
00:12:32Это был краткий обзор GitButler: ребейзер, редактор коммитов, параллельные и стековые ветки —
00:12:36всё это делается легко и без сторонних инструментов. Скачивайте, делитесь мнением
00:12:41в Discord и пользуйтесь с удовольствием.