Data Driven Knowledgebase

Databricks での開発では、ワークスペース上にノートブックやファイルが増えるにつれて、最新版の所在が分かりにくくなったり、変更の経緯を追いづらくなったりすることがあります。

このような課題に対して有効なのが、Databricks に用意されている 「Git folder（Git 統合機能）」を前提とした運用です。

Git folder を利用すると、ノートブック・コード・設定ファイル等を Git 管理下に置き、一般的なソフトウェア開発と同様にブランチ運用や Pull Request（PR）ベースのレビューを行えるようになります。

本稿では、Git folder の概要、利点、用語の整理、ならびに Databricks 上での実行手順を、丁寧に説明する形式でまとめます。

Databricks の Git folder は、Databricks ワークスペース内に Git リポジトリを取り込み（クローンし）、その配下でノートブックやファイルを編集・コミット・プッシュできる仕組みです。

この仕組みにより、Databricks 上での作業が「ワークスペースに散在するノートブック管理」から、「Git を基盤にしたソースコード管理」へ移行し、構成や変更履歴が明確になります。

• 公式ドキュメント（日本語）：

docs.databricks.com

Databricks Git フォルダーで Git 操作を実行する | Databricks on AWS

https://docs.databricks.com/aws/ja/repos/git-operations-with-repos

Databricks Git フォルダー (Repos) で一般的な Git 操作 (クローン、コミット、プッシュなど) を使用する方法について説明します。

Git folder を導入する主な利点は、次のとおりです。

1. ブランチ運用が可能になる


2. 変更は feature ブランチで行い、PR を通じて main に取り込む、という一般的な運用が可能です。


3. 変更履歴を追跡しやすくなる
   
   いつ・誰が・何を変更したかが履歴として残り、後追い・監査・原因調査が容易になります。


4. ディレクトリ構造を固定できる
   
   リポジトリ構造を基準に管理できるため、ファイルの置き場所や命名規則が安定し、運用上の混乱が減ります


5. ローカル（例：VS Code）との整合が取りやすい
   
   同一リポジトリをローカルでも扱えるため、開発体験が統一されます。

Git を扱う上で、混乱しやすい用語を整理します。

• 
  

  ・ローカルリポジトリ：個人（自分）の環境にあるリポジトリ

  
  


• 
  

  ・リモートリポジトリ：共有元（例：GitHub 上）のリポジトリ

  
  


• 
  

  ・clone：リモートのリポジトリをローカルへ複製すること

  
  


• 
  

  ・pull：リモートの変更をローカルへ取り込むこと

  
  


• 
  

  ・commit：変更を履歴としてローカルへ保存すること

  
  


• 
  

  ・push：ローカルの履歴（コミット）をリモートへ反映すること

  
  


• 
  

  ・merge：ブランチの変更を別ブランチ（例：main）へ統合すること

  
  


• 
  

  ・feature ブランチ：開発単位ごとに作成する作業用ブランチ

  
  

補足（運用上の注意点）

• 
  

  ローカルの main は自動でリモートの main と同期されません。

  
  

  そのため、必要なタイミングで pull を行う必要があります。

  
  


• 
  

  原則として main に直接コミットしない運用が安全です。

  
  

  PR を通すことでレビュー・履歴・ロールバックの容易さが確保されます。

  
  

feature ブランチは「1 ブランチ = 1 変更単位」とすることが推奨されます。

この方針には次の利点があります。

• ・PR が小さくなり、レビューが容易になる


• ・問題が発生した場合に、対象変更のみを切り戻ししやすい


• ・作業単位が混ざりにくく、コンフリクトを抑えやすい


• ・「この変更だけ先に適用する」といった判断がしやすい

Git folder を利用する場合の基本的な流れを、処理順に示します。



Databricks Git folder（作業）                GitHub（共有）

----------------------------------------------------------------------

(main) で開始

   |

   |-- feature/xxx を作成

   v

[編集] -> [commit] -> [push(feature)]  --->  feature ブランチが更新

                                       |

                                       |-- Pull Request 作成

                                       |-- main に merge

                                       v

                                main が最新化

                                       |

Databricks 側

   |

   |-- ブランチを main に切り替え

   |-- pull(main) を実行

   v

(main の最新コードが Git folder に反映)

   |

   |-- Deploy again（Apps）

   v

Apps が main の最新で動作

特に重要な点

• 
  

  PR を main に merge しただけでは、Databricks 側は自動で更新されません。

  
  

  Databricks 側で main に切り替えた上で pull を行う必要があります。

  
  


• 
  

  Databricks 側が feature ブランチのままになると、意図しないコードが動作する原因となります。

  
  

  運用上は「作業は feature、実行・デプロイは main」を基本にするのが安全です。

  
  

6.1 Databricks と GitHub アカウントのリンク

1. Databricks にログインします


2. 右上のアイコン → 「Setting（設定）」を開きます


3. 「Linked accounts（リンク済みアカウント）」から GitHub を選択します


4. 認証画面で Databricks アプリを承認します


5. リンクが完了します

6.2 GitHub アプリ（Databricks）のインストール

2. 次の URL を開きます

GitHub

Build software better, together

https://github.com/apps/databricks/installations/new

GitHub is where people build software. More than 150 million people use GitHub to discover, fork, and contribute to over 420 million projects.

2. 表示に従い Install を実行します

6.3 GitHub リポジトリの作成（未作成の場合）

1. GitHub 右上のアイコン → Repositories


2. New をクリックします


3. Owner / Repository name / Choose Visibility を設定します


4. Create repository をクリックします
   
   
   
   
   • このページの URL が後で指定する Git repository URL になります
   
   
   
   

6.4 Databricks 側で Git folder を作成（クローン）

1. Databricks の Workspace を開きます


2. 右上の Create → Git folder を選択します


3. 次を入力します
   
   
   
   
   • Git repository URL：GitHub リポジトリの URL
   
   
   • Git provider：GitHub
   
   
   • Git folder name：任意
   
   
   
   


4. Create Git folder をクリックします

6.5 変更作業（Pull → ブランチ作成 → 編集 → Commit & Push）

1. 対象の Git folder を開き、Git… をクリックします


2. 最新状態を取得するため Pull を実行します


3. Create Branch で feature ブランチを作成します


4. コードを編集します


5. Commit message を記入し、Commit します


6. Push を行い、GitHub 側へ feature ブランチの変更を反映します

6.6 Pull Request → レビュー → main へ merge

1. GitHub 上で Pull Request を作成します


2. 必要に応じてレビューを実施します


3. Merge pull request により main に統合します

6.7 Databricks 側で main を最新化（pull）

1. Databricks 側でブランチを main に切り替えます


2. Pull を実行し、main の最新を Git folder に反映します

6.8 Apps を更新（Deploy again）

1. main の最新が反映された状態で 「Deploy again（Apps）」を実施します


2. Apps が main の最新コードで稼働します

PR 画面では、次の観点で変更を確認できます。

• Commits：マージ前のコミット一覧


• Files changed：差分（変更内容）


• Conversation：レビューのやり取りや議論の記録

Databricks での開発が辛くなる原因の多くは「ワークスペースが最終成果物置き場になってしまう」ことです。

Git folder を前提にすると、

• ・置き場所（ディレクトリ）が固定され


• ・ブランチと PR で変更が追跡でき


• ・main を基準にデプロイできる

ので、チーム開発の地盤ができます。

まずは 「main に直接コミットしない」と「PR マージ後は Databricks で main に戻して pull」の2点だけでも徹底すると、体感で事故が減ります。