Главный релиз GitHub за последние годы. Стекированные PR.
BBetter Stack
Computing/SoftwareInternet Technology
Transcript
00:00:00GitHub только что выпустила своё крупнейшее обновление за последние годы — стекируемые PR, совершенно новый способ разбивать
00:00:05огромные PR на более управляемые части. В этом видео мы подробно разберем, что это такое
00:00:10и зачем они нужны. Стекируемые PR — это мощная, но довольно простая концепция. Разделение больших изменений кода
00:00:21на цепочку более мелких зависимых запросов на слияние. Их можно рецензировать и объединять независимо.
00:00:26Чтобы создать стек, вам нужно два или более пулл-реквеста в одном репозитории, где первый
00:00:31или нижний пулл-реквест направлен в trunk, обычно это ветка по умолчанию вашего репозитория, такая как main,
00:00:37а каждый последующий пулл-реквест нацелен на предыдущий. Это образует цепочку зависимостей, где
00:00:42каждая ветка строится на основе нижележащей. Базовые изменения, такие как общие типы или схемы баз данных,
00:00:48помещаются в нижние ветки, а зависящий от них код, например маршруты API и компоненты пользовательского интерфейса,
00:00:53помещается в верхние ветки. И вы можете подумать: «Ну, я же всегда мог так делать, верно?
00:00:58Я мог создать PR в main, затем создать второй PR к этому PR и связывать их в цепочки сколько угодно».
00:01:04И это абсолютно верно, потому что в контексте самого Git понятия стекируемых PR не существует,
00:01:09и вы бы просто связывали PR цепочкой друг за другом. И только внутри самого GitHub стекируемые PR
00:01:16действительно обретают смысл. Но они дают огромные преимущества. И если вы хотите оставаться в курсе
00:01:22технологий и ИИ, подписывайтесь на Better Stack. Итак, чтобы использовать стекируемые PR, лучше всего иметь
00:01:27установленный интерфейс командной строки GitHub. С его помощью вы можете запустить `gh stack init` и объявить свой новый стек.
00:01:33Итак, давайте перейдем в наш текстовый редактор и рассмотрим пример стекирования нескольких PR.
00:01:38Первое, что мы сделаем — запустим `gh stack init setup database`. В данном случае
00:01:44PR или ветка будут называться `setup database`. Это будет базовый PR, который теперь
00:01:50будет указывать на main. Затем мы можем внести изменения. Для этого демо я просто внесу
00:01:54изменения в файл README. Я указал, что реализовал базу данных, а затем вы можете просто сделать `git add`,
00:01:59`git commit`. Все здесь — это стандартный git. И когда вы будете готовы перейти к следующему набору
00:02:04изменений, вы можете выполнить `gh stack add` и указать вашу следующую ветку. Затем я могу внести новые изменения,
00:02:10создать эндпоинты API. Возможно, я захочу добавить здесь еще кое-что. Поэтому я закоммичу это изменение.
00:02:16Затем мы можем добавить второе изменение. И после этого снова закоммитить его. Как и следовало ожидать,
00:02:20вы можете делать несколько коммитов на ветку. И в конце мы выполняем `gh stack add setup front end`,
00:02:25и вносим здесь еще одно изменение. После чего снова делаем `git add` и `git commit`. Теперь, когда мы довольны
00:02:31всеми нашими изменениями и хотим отправить все эти ветки на GitHub одновременно,
00:02:36мы можем запустить всего одну команду: `gh stack submit`. Она откроет мини-интерфейс командной строки, где мы сможем
00:02:42пройтись по каждому PR в стеке и при желании добавить название и описание. Либо мы можем
00:02:48просто нажимать “далее” для каждого из них и отправить три PR за один раз. Как вы видите, все три этих PR —
00:02:55`setup database`, `API` и `front end` — были отправлены на GitHub как стек с помощью одной команды.
00:03:02И на самом деле вы можете сделать все это без интерфейса командной строки GitHub. Просто следуйте старому методу:
00:03:07связывайте PR вручную от main к PR1, а затем к PR2. После этого GitHub все равно распознает их как стек,
00:03:14как только вы все их отправите. CLI просто значительно упрощает управление. Помните, что в самом Git
00:03:20ничего не изменилось. Если вы хотите переключиться на совершенно другую ветку, которая не входит в стек,
00:03:24с которым вы работаете, вы можете это сделать, а затем вернуться к ветке в стеке позже.
00:03:29Если мы перейдем на сам GitHub, то увидим все три наших PR, созданных
00:03:34здесь в виде пулл-реквестов. Вы также заметите небольшой значок стека, который говорит о том, что эти
00:03:39PR связаны со стеком. Если мы откроем конечный PR (тот, который находится на вершине стека), вы увидите,
00:03:45что здесь можно нажать “Merge stack”, и перед вами появится интерфейс, где отображен каждый
00:03:49отдельный PR из состава стека. Мы можем просмотреть их и одобрить по очереди. Но как только мы будем довольны
00:03:54всем этим, вы можете просто нажать “Merge stack”, и абсолютно каждый из этих PR будет объединен
00:03:59с main одновременно. Вы также заметите, что упоминания стеков теперь интегрированы
00:04:03по всему GitHub. Вы можете увидеть их на странице пулл-реквеста, на странице списка пулл-реквестов,
00:04:09в GitHub Actions и вообще во всем приложении.
00:04:14Так что, если вы работаете с огромными PR и вам нужен простой способ разбить их
00:04:18на отдельные части, вам больше не нужно ждать объединения отдельных PR в main
00:04:23и самостоятельно выполнять все операции ребейза и слияния. Вы можете просто создать один длинный стек, и GitHub
00:04:28теперь отлично подготовлен для управления всем этим прямо в интерфейсе. А CLI — это отличный способ
00:04:33управлять всем этим автоматически. Это нововведение встретили
00:04:38крайне положительно. И особенно в сочетании с ИИ, я считаю, это мощная функция,
00:04:43когда вы создаете агентские циклы и позволяете агенту работать часами. Теперь он может создавать
00:04:48стекируемые PR и связывать всю эту работу воедино, вместо того чтобы создавать либо огромный PR, либо множество
00:04:54совершенно изолированных PR. Надеюсь, это видео было вам полезно, друзья. Расскажите в комментариях,
00:04:58что вы думаете о стекируемых PR, и подписывайтесь на Better Stack, чтобы быть в курсе последних
00:05:02новостей из мира технологий и ИИ. Спасибо за просмотр, и до встречи в следующем видео!