SCMに世代交代の風?Meta社謹製のSaplingを検証してみた

アソビューAdvent Calendar 2022の11日目です。 こんにちは、アソビューでエンジニアリングマネージャーをしている服部です。

2022年11月にMeta社からソースコード管理システム「Sapling」がオープンソースとして公開されました。

Saplingは、ユーザビリティとスケーラビリティに重点を置いてMeta社で開発・利用されているソースコード管理システムです。数千万のファイル、コミットおよびブランチを持つ大規模なリポジトリにも対応しているそうです。Sapling CLIはGitリポジトリのcloneもサポートしており、開発者がGitHubなどと連携して使用することも可能。*1

とのことなので、今回Saplingをローカルマシンにインストールし、GitHubのリモートリポジトリにPRを出すまでを触ってみながら、gitの代わりに使えるか検証してみます。

※ Saplingはversion 0.1.20221118-210929-cfbb68aaを利用しています。

Saplingのインストールと初期設定

インストールと初期設定を実施し、Saplingを利用できるようにします。

インストール

今回はmac(Apple silicon)とHomebrewを利用してSaplingをインストールします。 実行する環境によってインストール手順は変わりますので、詳細に関しては公式の説明をご確認ください。

パッケージの取得

$ curl -L -O https://github.com/facebook/sapling/releases/download/0.1.20221201-095354-r360873f1/sapling_0.1.20221201-095354-r360873f1.arm64_monterey.bottle.tar.gz

brewでinstall

$ brew install ./sapling_0.1.20221201-095354-r360873f1.arm64_monterey.bottle.tar.gz

ulimitの変更(オプション)

巨大なリポジトリを利用している場合、cloneに失敗することがあるそうなので必要な場合は実施します。

$ echo "ulimit -n 1048576 1048576" >> ~/.bash_profile
$ echo "ulimit -n 1048576 1048576" >> ~/.zshrc

初期設定

インストール手順通りにやれば、この時点でslコマンドが使用できるようになります。 Saplingの初期設定を実施し、GitHubをremoteリポジトリとして利用できるようにします。

Sapling初期設定

ユーザー設定を行います。下記はsampleですので名前やメールアドレスは変更してください。

$ sl config --user ui.username "asoview sample <asoview-sample@example.com>"

GitHub認証実施

GitHub CLIが必要なので、もしインストールされていない場合はこちらを参考にしてください。 ghコマンドを実行し認証を進めます。下記コマンド実行後、対話形式で認証処理が進みます。

$ gh auth login --git-protocol https

リポジトリ作成

ローカルにリポジトリ作成をし、今回はGitHubのリモートリポジトリと連携します。 リポジトリの作成は、initコマンドを実行するパターンとcloneコマンドで既存のリモートリポジトリを引っ張ってくるパターンがあります。

先に書いておくと、initコマンドでローカルリポジトリを作成することはできるものの、gitのようにremoteコマンドが用意されていないためリモートリポジトリと連携する手順が煩雑です。(同等のものがもしある場合、コメントいただけますと幸いです)

そのため、GitHub等のリモートリポジトリと連携する場合は、cloneコマンドを利用し既存のリモートリポジトリを引っ張ってくることをオススメします。

initコマンドを利用したリポジトリの作成(個人的に非推奨)

initコマンドは引数にリポジトリ名を指定すれば、空のリポジトリ作成。引数を指定しない場合はカレントディレクトリをリポジトリ化してくれるようです

失敗例

空のディレクトリを作成し、initコマンドを実施します。

$ mkdir sapling-demo
$ cd sapling-demo

initコマンドを実施

$ sl init
abort: please use 'sl init --git .' for a better experience

し、失敗する。。。指示された通りのコマンドを実行してみます。

$ sl init --git .
destination '.' already exists

新規ディレクトリ内でのinitは私が利用しているバージョンでは上手くいかないようですね。。。

成功例

上記で作成したディレクトリを削除して、initコマンドの引数にリポジトリ名指定して実行してみます。

$ sl init sapling-demo

エラーも表示されずうまく行きました。念の為 .sl ファイルが作成されているか確認します。 .slディレクトリは.gitディレクトリと同様にリポジトリ化すると作成されるファイルです。

$ ls -a1
.
..
.sl

すでにsapling-demoリポジトリをローカルに作成しているので、リモートリポジトリと連携します。 gh repo createコマンドですでに存在しているディレクトリからリモートリポジトリは作成できますが、.gitファイルがないためエラーになります。 煩雑ですがgit init実行してから gh repo createを実行します。

$ git init
$ gh repo create

gh repo createコマンドを実行すると対話形式でGitHubにリモートリポジトリを作成してくれます。 What would you like to do?が表示されたら、Push an existing local repository to GitHub を選択し、その後はご自身の設定を入力してください。

リモートリポジトリ作成後、gitコマンドは利用できるもののslコマンドは利用できないので、利用できるようにします。 .sl/config内に下記を追記してください。

[paths]
default = https://github.com/{your repository root name}/sapling-demo.git

初回コミットを作成し、mainにpushします。

$ touch README.md
$ sl add .
$ sl commit -m 'first commit'
$ sl push --to main

これでローカルリポジトリとリモートリポジトリが連携できました。

cloneコマンドを利用したリポジトリの作成(個人的に推奨)

GitHubのリモートリポジトリの作成

下記コマンド実行後、対話形式でGitHubにリモートリポジトリを作成します。 こちらではsapling-testという名前でリポジトリをGitHubに作成します。

$ gh repo create
# 下記新規作成時の設定
What would you like to do? Create a new repository on GitHub from scratch
Repository name sapling-test
Description sapling-test
Visibility Private
Would you like to add a README file? No
Would you like to add a .gitignore? No
Would you like to add a license? No

上記で作成したリポジトリをGitHubよりcloneします。

sl clone https://github.com/{your root repository name}/sapling-test.git

初回コミットを作成し、mainにpushします。

$ touch README.md
$ sl add .
$ sl commit -m 'first commit'
$ sl push --to main

これでリモートリポジトリを作成し、ローカルリポジトリへのcloneが完了しました。

SaplingでPRを出してみる

gitと互換性があるので、ほとんどのコマンドはgitと似通っています。 Sapling公式のCommandsページでも確認できますが、sl gitコマンドという便利なコマンドが用意されているので、 gitと互換性のあるコマンドを知りたい場合はこちらを利用することをオススメします。

例えば、mainブランチをcheckoutするgit checkout mainコマンドと互換性があるslコマンドを知りたい場合は、

$ sl git checkout main
sl goto main

とSaplingで利用するためのコマンドが表示されるようになっています。

話はそれましたが、README.mdファイルを修正しコミットするところまでやってみます。

sl prコマンドを利用してPRを作成

$ echo 'test' > README.md
$ sl add .
$ sl commit -m 'PR test'

gitとコマンドは一緒なので、通常の修正であれば迷いなく進められますね。 現在の状態をslコマンドを実行して見てみましょう。

$ sl
@  2408ec542  2 minutes ago  takayasu.hattori
│  PR test
│
o  de14c61f8  21 minutes ago  takayasu.hattori  remote/main
   first commit

コミット成功してるのがわかります。

SaplingにはローカルからリモートリポジトリにPRを出すsl prコマンドコマンドが用意されています。こちらを利用してPRを作成してみます。

$sl pr
pushing 1 to https://github.com/{your root repository name}/sapling-test.git
created new pull request: https://github.com/{your root repository name}/sapling-test/pull/1
updated body for https://github.com/{your root repository name}/sapling-test/pull/1

作成されたようなので、実際にGitHubを確認してみます。 最新のコミットコメントがPRのタイトルとして作成されています。

slコマンドで確認するとPRのナンバーが表示され、ローカルのコミットとPRがリンクされていることを確認できます。

$ sl
@  2408ec542  21 minutes ago  takayasu.hattori  #1
│  PR test
│
o  de14c61f8  40 minutes ago  takayasu.hattori  remote/main
   first commit

sl prでPRを作成すると、ローカルのコミットとPRがリンクされるので便利ですが、GitHub側にブランチが2つ作成されてしまうので注意が必要です。

これはSaplingにブランチという概念がないため、PRを作成するためのブランチとコミットをアーカイブしておくためのブランチを作成するからのようです。

ブランチを明示的にpushしてPRを作成

ブランチを複数作らずにPRを作成するには、明示的にブランチをpushし、GitHubのGUIもしくはCLIコマンドから作成するのが良さそうです。 下記、testブランチを作成しpushする例。

$ echo 'test-push' > README.md
$ sl add .
$ sl commit -m 'push test'
$ sl push --to test

Saplingを触ってみて...

良かったところ

Sapling CLIの標準コマンドでGUIが表示できる

sl webコマンドを実行することで、SourceTreeのようなGUIを表示できる。 CLIが苦手な人でも簡単に触れるようになっています。

smartlogが見やすい

slコマンドやsl sslコマンドを実行した際のログがgit log --graphにさらにオプション付けたものよりも見やすく使いやすい。

gitと同じ様に使える

sl git {コマンド}が準備されているくらい、gitと互換性が高くスムースに移行できます。

branch作らなくていいのは意外と便利

最初はなれないですが、git checkout {branch_name}が必要ないのは意外とストレスがなく便利です。 ただし、オプションなしでsl pushしてしまうと origin/mainにpushされてしまうので、注意が必要です。

検証できなかったところ

大規模なリポジトリに対する検証

.gitファイルを抜いた容量が3Gほどのリポジトリを、gitとSaplingでそれぞれcloneしたところ

  • git : 3G + .git 2.6G = 計5.6G
  • Sapling : 3G + .sl 2.5G = 計5.5G

と初回cloneした段階では、ほぼ容量に関しては差異はありませんでした。

初回cloneに関して差異はほぼなかったものの、使っていくうちに容量や使用感が変わる可能性はあるので、こちらは今後検証したいと思います。

まとめ

gitと互換性があるため導入ハードルは高くないです。GUIも標準で用意されていたりと個人開発にはおすすめできます。

ただし、細かいところを見ていくとgitと仕様の違いが多いです。すでにgitで開発が進んでいるプロジェクトにSaplingを適用するには、ブランチ運用等の開発ルールの変更等が発生することが想定されます。そのため、大規模リポジトリでgit運用に困っていない場合は無理に導入することはしなくていいと思います。

アソビューでは一緒に働くメンバーを募集しています! カジュアル面談もありますので、少しでも興味があればご応募いただければと思います。 www.asoview.com