【新機能】Databricks の Git folders で Git CLI コマンドがPublic Previewになったので試してみた
かわばたです。
Databricks の Git folders では、従来から UI の Git ダイアログでコミット・プッシュ・プル・ブランチ操作・rebase・reset などを実行できました。一方で、git stash、git rebase -i、git commit --amend、任意のオプションを指定した git push --force といった細かな Git 操作は、Databricks の外(ローカル環境など)に持ち出して行う必要がありました。ノートブック開発の途中で「一時的に変更を退避したい」「コミットを整理してから push したい」と思ったことがある方は多いのではないでしょうか。
2026年7月24日、Git folders 内で Git CLI コマンドを直接実行できる機能が Public Preview になりました。本記事では、web terminal からの基本操作一周と、UI 操作との使い分け、制限事項を検証します。
機能の概要
Git CLI アクセスが有効な Git folder では、web terminal、ノートブック、または Genie Code から標準の Git コマンドをそのまま実行できます(Databricks compute へ SSH トンネルで接続した IDE / ターミナルからも利用できます)。本記事では web terminal を中心に扱います。公式ドキュメントでは次のユースケースが挙げられています。
git stash、git push --force、git rebase -iを含む任意の Git コマンドの実行- pre-commit hooks によるリント・コードスキャンの統合
- Git folders の従来制限(メモリ 2GB / ディスク 4GB)を超えるリポジトリの操作
- Git submodules と Git LFS(Large File Storage)のサポート
- ローカルで複数コミットを積んでからまとめて push
認証は、リモート URL から Git プロバイダを判定し、そのプロバイダに設定されたデフォルトの Git credential(認証情報)を自動利用します。そのため通常は、ターミナル上でトークンを入力する必要はありません。ただし、同一プロバイダに複数の credential が登録されていて 1 つに特定できない場合は選択を求められます。その場合は環境変数 DB_GIT_CREDENTIAL_NAME で使用する credential 名を明示でき、一度選択した credential はリポジトリごとに記憶されます。
UI 操作との関係
従来の Git folders の UI(コミット・プッシュダイアログや、UI が提供する rebase・hard reset)は引き続き利用でき、CLI と併用できます。使い分けの観点は「試してみた」で確認します。
前提条件
- Databricks ワークスペース(本記事では AWS)
- ワークスペース管理者が Previews ページで「Git CLI support for Git folders」を有効化していること
- コンピュート要件:
- Git folder の作成(CLI アクセス付き)と UI からの Git 操作: サーバーレスコンピュート
- web terminal / ノートブック / Genie Code からの CLI コマンド実行: サーバーレスコンピュート(サーバーレス環境バージョン 5 以上)または Databricks Runtime(DBR)17.0 以上
- Git プロバイダ(本記事では GitHub)の credential をワークスペースに登録済みであること
- Git folder を作成する親フォルダに対する
CAN MANAGE権限 - 検証用の GitHub リポジトリ(新規作成)
検証環境
- 検証日: 2026年7月29日
- クラウド: AWS
- リージョン:
- コンピュート: サーバーレスコンピュート(環境バージョン )
- Git プロバイダ: GitHub(credential: )
事前準備
検証用 GitHub リポジトリの作成
GitHub 側で検証用のリポジトリを新規作成します。
- GitHub にログインし、New repository をクリックします
- Repository name に任意の名前(例:
databricks-git-cli-test)を入力します - 可視性は Private を選択し、Add a README file にチェックを入れて Create repository をクリックします(README を入れておくと初期コミットが作られ、クローン後の
git log確認がしやすくなります)
Git credential の登録
ワークスペースに GitHub の認証情報(credential)を登録します。
- 画面右上のユーザー名をクリックし、Settings を選択します
- Linked accounts をクリックします
3. Git provider で GitHub を選択します
4. 認証方式を選択します。Link Git account(OAuth)を選ぶと GitHub の認可フローを経て自動的に連携されます。personal access token(PAT)を使う場合は、GitHub 側で発行したトークンを貼り付けます
5. 保存します
注意: GitHub 組織で SAML SSO を有効にしている場合、PAT には SSO の authorize が必要です。
Git folder の作成
ワークスペースで Git folder を作成し、検証用リポジトリをクローンします。
- サイドバーの Workspace を開き、自分のユーザーフォルダ(
Users/<your-email>)に移動します - Create > Git folder をクリックします
- Git repository URL に検証用リポジトリの URL(
https://github.com/<your-org>/<your-repo>.git)を入力します。Git provider は URL から自動判定されます - Create Git folder をクリックします
以下の条件をすべて満たす場合、UI から作成した Git folder には Git CLI アクセスが自動的に付与されます。
- Git CLI support for Git folders の Preview が有効である
- ワークスペースでサーバーレスコンピュートが利用可能である
- サーバーレスコンピュートから Git プロバイダへ接続できる
- Public Preview 時点では、リポジトリのファイル数が 10,000 以下である(超えるリポジトリは通常の Git folder として作成されます)
UI からの作成に加えて、web terminal から /Workspace 配下に git clone する方法もあります。この方法でクローンしたリポジトリは常に Git CLI アクセス付きの Git folder になり、クローン後にブラウザをリフレッシュするとワークスペースのファイルブラウザに表示されます。
cd /Workspace/Users/<your-email>
git clone https://github.com/<your-org>/<your-repo>.git
web terminal を開く
Git CLI コマンドの実行には web terminal を使います。
- Git folder 内でノートブックを新規作成する(または任意のノートブックを開く)
- ノートブックをサーバーレスコンピュートにアタッチし、環境パネルでサーバーレス環境バージョンを 5 以上に設定します(クラシックコンピュートの場合は Databricks Runtime 17.0 以上)
- 右サイドバー下部のターミナルアイコンをクリックする(または接続中のコンピュートのドロップダウンから Web Terminal を選択する)と、画面下部にターミナルが開きます
ターミナルの画面
注意: web terminal 自体もワークスペース管理者による有効化が必要な場合があります。開けない場合は管理者設定(Workspace admin settings)で web terminal が有効になっているか確認してください。
試してみた
基本操作を一周する
web terminal で Git folder のパスに移動し、基本操作を一通り実行します。
cd /Workspace/Users/<your-email>/<git-folder-name>
# 状態確認
git status
git log --oneline -5
# ブランチ作成
git checkout -b feature/git-cli-test
ファイルを変更してコミット・プッシュします。
echo "# git cli test" >> README.md
git add README.md
git commit -m "Test commit from Databricks web terminal"
git push origin feature/git-cli-test
なお、初回の push を git push -u origin feature/git-cli-test のように -u 付きで実行して upstream を設定しておくと、以後は git push / git pull だけで実行できます。
GitHub 側でブランチとコミットが反映されていることを確認します。
UI ではできなかった操作を試す
UI の Git ダイアログでは提供されていない操作を実行してみます。
# 変更の一時退避と復元
echo "temporary change" >> README.md
git stash
git status
git stash pop
# 直前のコミットメッセージを修正する
git commit --amend -m "Amended commit message"
ここでの git commit --amend は、git stash pop で復元した変更を git add していないため、直前のコミットのメッセージだけを書き換える操作になります。復元した変更も直前のコミットに取り込みたい場合は、git add README.md を実行してから amend します。
補足: 通常の
git stashは未追跡(untracked)ファイルを退避しません。未追跡ファイルも含めて退避する場合はgit stash -uを使います。
続いて対話的リベースです。編集対象のコミットが 2 件以上必要なため、先にコミットを 2 件作成してから実行します。
# rebase -i 用にコミットを 2 件作成する
echo "commit 1" >> README.md
git add README.md
git commit -m "Add commit 1"
echo "commit 2" >> README.md
git add README.md
git commit -m "Add commit 2"
# 直近 2 コミットを対話的に編集する(コミットの整理)
git rebase -i HEAD~2
編集モード
エディタが開いたら、2 件目のコミットの行頭にある pick を squash(または s)へ変更して保存・終了します。これで 2 件のコミットを 1 件にまとめられます。
pick <commit-1> Add commit 1
squash <commit-2> Add commit 2
続いてコミットメッセージの編集画面が開くので、まとめた後のメッセージを整えて保存・終了すると rebase が完了します。結果は git log で確認できます。
git log --oneline -5
履歴を書き換えたブランチを push する
git commit --amend や git rebase -i で履歴を書き換えたブランチは、リモートのブランチと分岐した状態になるため、通常の git push は拒否されます。
git push origin feature/git-cli-test
このようなケースで使うのが force push です。git push --force はリモートの状態を無条件に上書きしますが、--force-with-lease はリモートブランチが自分の把握していない状態に更新されていた場合に push を拒否してくれるため、共同開発での誤上書きを抑制できます。
git push --force-with-lease origin feature/git-cli-test
注意: Git プロバイダ側でブランチ保護ルールにより force push が禁止されている場合は、
--force-with-leaseを指定しても push は拒否されます。共有ブランチでは保護ルールを有効にし、履歴の書き換えは個人の作業ブランチに限定することを推奨します。
UI でも rebase 後には git push --force が実行され、reset は git reset --hard と git push --force の組み合わせに相当します。ただし、任意のタイミング・任意のオプションで force push を実行できるのは Git CLI ならではの操作です。
UI 操作との使い分け
| 操作 | UI(Git ダイアログ) | Git CLI |
|---|---|---|
| クローン(Git folder 作成) | ○ | ○(web terminal で git clone) |
| コミット・プッシュ・プル | ○ | ○ |
| ブランチ作成・切り替え | ○ | ○ |
| merge / rebase / hard reset | ○(UI が提供する操作に限定) | ○ |
git stash / git commit --amend |
- | ○ |
git rebase -i(対話的リベース) |
- | ○ |
任意の git push --force / --force-with-lease |
- | ○ |
| pre-commit hooks / submodules / Git LFS | - | ○ |
| 複数コミットを積んでからまとめて push | - | ○ |
| Databricks の監査ログにおける個人単位の attribution | ○ | △(raw Git commit は Databricks が個別ユーザーに attribution しない) |
注意: UI の rebase / reset は履歴を書き換えたうえでリモートへ force push する動作です(reset は
git reset --hard+git push --force相当)。CLI で履歴を書き換えたブランチを push する場合も、git push --forceよりgit push --force-with-leaseを優先し、共有ブランチには直接 push せず Pull Request を経由する運用を推奨します。
制限事項・注意点
制限事項・注意点
- 本機能は 2026年7月24日時点で Public Preview です。仕様は変更される可能性があります
- セキュリティ上の注意: Git URL の allowlist は UI 経由の Git 操作には適用されますが、Git CLI で直接実行するコマンドには適用されません。allowlist を接続先制御として利用している場合は、CLI 利用を許可する前に、ネットワーク出口制御、Git credential の最小権限化、リポジトリ側の権限・監査ログを含めた代替統制を確認してください
- UI から作成した Git folder に CLI アクセスが自動付与されるのは、Public Preview 時点でリポジトリのファイル数が 10,000 以下の場合です。超えるリポジトリは通常の Git folder としてクローンされます
- Git CLI アクセスが有効な Git folder は List Repos API のレスポンスに含まれません
- Git CLI で作成した raw Git commit は、Databricks の監査ログ上では個別ユーザーに attribution されません。Git プロバイダ側で表示される author / committer は、Git の設定および使用する credential に依存します
- CLI コマンドの実行にはサーバーレスコンピュート(サーバーレス環境バージョン 5 以上)または Databricks Runtime 17.0 以上が必要です
- Git プロバイダへの接続にプライベートネットワーク接続が必要な場合は、別途ネットワーク設定が必要です
- credential の選択を求められる場合は、環境変数
DB_GIT_CREDENTIAL_NAMEで使用する credential を明示できます
最後に
Git folders 内で Git CLI が使えるようになったことで、これまでローカルに持ち出していた stash・rebase・amend などの操作が Databricks 内で完結するようになりました。一方で、URL allowlist が CLI に適用されない点や raw コミットの attribution がない点など、ガバナンス面では UI 操作と異なる特性があるため、チームでの運用ルールとあわせて導入するのがよさそうです。
この記事が何かの参考になれば幸いです！
