Эксперименты с Sapling, новым клиентом Git от Meta

Sapling – это новая система контроля версий, разработанная компанией Meta. Недавно он получил возможность работать с GitHub. Мне любопытно, как это работает, поэтому я решил попробовать и в конечном итоге использовать его ежедневно в репозиториях моей компании. Если вы хотите попробовать его, ознакомьтесь с их документацией.

Сложенные PR

При разработке я обычно создаю один коммит для каждого PR и складываю их вместе.

Для примера предположим, что мы разрабатываем функцию регистрации: пользователь вводит свой адрес электронной почты, пароль, и мы отправляем ему приятное приветственное письмо. С точки зрения серверной части нам нужно создать нового пользователя, убедиться, что он не существует, и отправить электронное письмо. Нам нужно коснуться реализации пакета кеша, добавить пакет электронной почты, а затем, наконец, реализовать логику регистрации. Это можно представить в виде стека PR:

1. Обновите пакет кеша, чтобы добавить новый метод.
2. Добавьте систему отправки электронной почты. Он использует пакет cache для предотвращения отправки повторяющихся сообщений электронной почты.
3. Внедрите логику регистрации. Это зависит от двух указанных выше изменений.

Преимущество: это помогает рецензентам разделять проблемы. Небольшие изолированные изменения легче проверить. Они могут проверять PR один за другим, причем каждый PR содержит независимую логику. Конечно, система электронной почты по-прежнему требует обновления пакета кеша, но мы все же можем проверить систему электронной почты отдельно.

Когда источник будет обновлен, мы извлечем изменения и перебазируем PR поверх источника, отправим изменения, проверим и объединим.

* Недостаток: * Требуется дисциплина, чтобы PR были небольшими и изолированными. Обычно при разработке верхних PR нам необходимо внести некоторые изменения в нижние PR. Это может раздражать, так как мы должны отслеживать, что изменяется в каком PR, или постоянно переключаться между PR для внесения изменений, а затем перебазировать верхние. п

git checkout mybranch/signup   # checkout sign up branch
vim features/signup/signup.go  # make changes to signup
vim lib/email/email.go         # make changes to email package

git add features/signup        # commit the signup changes        
git commit --amend             
git stash                      # stash the cache changes
git checkout mybranch/email    # checkout email branch
git stash pop                  # apply the cache changes
git add lib/email              # commit the email changes
git commit --amend
git checkout mybranch/signup   # checkout sign up branch again
git rebase mybranch/email      # rebase the signup branch on top of email branch

Слишком много переключений и слишком много команд для ввода. Это не весело.

Введите саженец

Sapling — это новый клиент git. Это поощряет использование сложенного PR. Он автоматически перебазирует PR друг на друга, поэтому нам не нужно делать это вручную.

Учитывая следующую структуру коммита, представленную вызовом команды sl:

sl
  @  00f1749f6  30 minutes ago  oliver
  │  implement user signup
  │
  @  e0dbbc80e  50 minutes ago  oliver
  │  implement email package
  │
  o  4f6928029  Yesterday at   oliver
╭─╯  update cache package
│
o  876f46044  Today at 07:45  remote/main

Рабочий процесс с саженцем будет следующим:

sl goto 00f1749f6              # checkout the sign up code
vim features/signup/signup.go  # make changes to signup
vim lib/email/email.go         # make changes to email package

sl absorb                      # magic 👻

Всего одной командой slsorb саженец будет:

• Внесите изменения email.go в фиксацию электронной почты.
• Внесите изменения signup.go в фиксацию регистрации.
• Перебазируйте фиксацию регистрации поверх фиксации электронной почты.

Ваши изменения будут включены в PR, а PR будут переназначены друг на друга. Вам не нужно делать это вручную, как раньше. Всего одной командой. Отличная работа! 👻

Мой опыт выращивания саженцев

Я использую саженец уже несколько недель. Это новый инструмент, поэтому есть некоторые проблемы, но в целом впечатления отличные.

Часто используемые команды

Просмотреть статус репозитория:

• sl: показать график коммитов (или смарт-журнал)
• sl status: показать статус текущей ветки

Перемещение между фиксациями:

• sl goto <commit>: проверка фиксации.
• sl next, sl prev: проверить следующую/предыдущую фиксацию.

Работа с коммитами:

• sl добавить, sl удалить, sl забыть: добавить/удалить/отменить отслеживание файлов.
• sl commit: зафиксируйте изменения как новую фиксацию.
• sl metaedit: отредактируйте сообщение фиксации.
• sl Absorb: впитать изменения в PR и перебазировать PR друг на друга.
• sl rebase: перебазируйте PR друг на друга.

Пока git add добавляет все изменения в промежуточную область, включая новые файлы, удаленные файлы; соответствующая команда sl add только добавит новые файлы в промежуточную область. Чтобы удалить файлы, мы должны использовать sl remove. Это будет немного раздражать при фиксации файлов поставщика, поскольку нам нужно перечислить все удаленные файлы, чтобы удалить их. Я не уверен, что есть лучший способ:

$ sl status

? vendor/github.com/sample/cache/v2/caching.go
? vendor/github.com/sample/cache/v2/stripe.go
! vendor/github.com/sample/cache/v1/deprecated.go
! vendor/github.com/sample/cache/v1/formatter.go

$ sl add vendor

A vendor/github.com/sample/cache/v2/caching.go
A vendor/github.com/sample/cache/v2/stripe.go
! vendor/github.com/sample/cache/v1/deprecated.go
! vendor/github.com/sample/cache/v1/formatter.go

# Have to list all deleted files to remove, is there a better way? 😞
$ sl remove vendor/github.com/sample/cache/v1/deprecated.go 
            vendor/github.com/sample/cache/v1/formatter.go

A vendor/github.com/sample/cache/v2/caching.go
A vendor/github.com/sample/cache/v2/stripe.go
R vendor/github.com/sample/cache/v1/deprecated.go
R vendor/github.com/sample/cache/v1/formatter.go  

Отправка PR на GitHub

Sapling предоставляет 2 способа отправки PR на GitHub: sl pr и sl ghstack. У каждого есть разные компромиссы. Я предпочитаю использовать команду sl pr:

• Он создает PR для каждой фиксации.
• Он отправляет PR на GitHub в порядке коммитов.
• Это легче понять, так как коммиты хорошо накладываются друг на друга.
• Он работает хорошо, и его можно проверить с помощью пользовательского интерфейса GitHub.
• Еще одно преимущество: не требуется разрешение на запись в репозиторий на случай, если вы сделаете ответвление.

Команда sl ghstack создает более сложную сеть PR. И есть много случаев, когда ему не удается продвигать PR. Повторить попытку не получится. Нет доступных исправлений. Приходится снова дублировать эти PR и рисковать спамом в репозиториях моей компании. Я не рекомендую это.

Просмотр PR

Sapling рекомендует использовать для рецензирования reviewstack. Но я нахожу его медленным, менее отзывчивым и иногда дает неправильные изменения файлов. Я предпочитаю использовать пользовательский интерфейс GitHub. При отправке PR с помощью sl pr создается отдельная фиксация для каждого PR. Таким образом, рецензент может открыть последний коммит и просмотреть изменения. Еще один дополнительный клик по сравнению с обычным процессом проверки:

• Перейдите на вкладку "Коммиты".
• Выберите последнюю фиксацию.
• Просмотрите и добавьте комментарии. Эти комментарии будут отображаться в PR как обычно.

Другое

Для этого требуется клонировать новый репозиторий, поэтому вы не сможете использовать знакомые команды git. Он не будет работать с вашими существующими инструментами, IDE и т. д. Для просмотра изменений необходимо использовать пользовательский интерфейс sl web.

Попробуйте!

Саженец отличный. Хотя есть несколько проблем, и это требует небольшой кривой обучения, в конце концов, это окупается. Складывать, продвигать и просматривать PR намного проще. Попробуйте!

__

:::информация Также опубликовано здесь.

:::