What you will be able to do
- Explain how Workspaces, the default Snowsight editor, organises code, and which role governs which action
- Describe what Snowflake Notebooks in Workspaces add for Python and Jupyter-style development
- Create a Git-synced workspace and work through branches, commits, pushes and conflicts
- Explain what a Git repository clone in Snowflake is and what you can do with it
Key concept
Git repository clone — A Snowflake object that mirrors a remote Git repository, with all its branches, tags and commits. Snowflake acts as one more client of the repository, so code that is versioned in Git can be browsed, executed and imported inside Snowflake without changing how developers already work.
1.Workspaces: the development environment in Snowsight
In Snowsight, development happens in Workspaces. It is a single editor where you create, organise and manage code in several file types, and you use it to analyse data, develop models and build pipelines. It is not optional. Workspaces has replaced Legacy Worksheets in every account, including reader accounts, and an account cannot switch back. To get started, go to Projects » Workspaces, add a SQL file to My Workspace, pick a role and a warehouse in the file's editor, and run a statement with command + return (macOS) or CTRL + Enter (Windows).
A workspace holds files and folders. Every user gets a default workspace called My Workspace. It is private, and it cannot be deleted or renamed. When a team needs to work together, it uses shared workspaces. The first time someone opens Workspaces, Snowflake creates a personal database for that user to store their workspaces. It cannot hold tables or views, and it grants no extra privileges. This is why administrators may see users holding OWNERSHIP, USAGE and CREATE SCHEMA on it.
| Pane | What it is for |
|---|---|
| Workspaces | All files and folders. Drag files between nested folders |
| Worksheets | Open legacy worksheets. Drag one into a workspace folder to convert it |
| Database Explorer | Hierarchical view of databases, schemas and objects |
| Editor | Edit and split files side by side, with inline Copilot |
| Results | Split results side by side or pin them for comparison |
| Query History | Queries for the current file or across all files |
Roles work at two levels. Your current role, set in the Snowsight user menu, decides which workspaces you see and which resources you can reach, for example the API integrations and secrets offered when you create a Git workspace. The role selector inside a SQL file controls only that file's statements. Ownership also works differently for the two kinds of workspace. A private workspace belongs to you as a user, not to a role. A shared workspace gets an owner role when you create it, and that defaults to your current role. Workspaces can also run two queries at the same time from one SQL file.
Checkpoint 1 of 6· Check yourself
A developer created a private workspace while using role ANALYST and later switches to role ENGINEER. Who owns the private workspace?
A private workspace is owned by the user, not by the role that was active when it was created. Owner roles apply only to shared workspaces.
“Private workspaces belong to you, rather than to the role used to create them.”Source: docs.snowflake.com
Sources1
2.Snowflake Notebooks inside Workspaces
Notebooks now live in the same environment as SQL files. Notebooks in Workspaces replaces the Legacy Notebooks experience. Snowflake says it will roll out importing legacy notebooks into Workspaces starting in March 2026. A notebook is just another file in the workspace. It opens in a tab where you can edit and run it, next to folders and uploaded project files.
The new experience is built around Jupyter compatibility. It gives you a Jupyter notebook environment with direct access to governed Snowflake data, plus IDE features such as file management and a terminal. Notebooks run in a pre-built container environment with managed access to CPUs and GPUs, so ML work can scale without anyone configuring distributed compute. For development workflow, two capabilities matter most. Collaboration uses role-based access and version history through Git-integrated workspaces or shared workspaces. For production, you can schedule notebooks with the native scheduler or call them from orchestration scripts. Plain .py files also run interactively in the same environment through notebook services.
Checkpoint 2 of 6· Check yourself
A team wants several data engineers to work on the same notebooks with version history. Which approach do the Workspaces docs describe?
Governed collaboration in Notebooks comes from Git-integrated or shared workspaces. My Workspace is private, and Legacy Notebooks are being replaced.
“Allows multiple users to work in the same workspace with role-based access controls and version history through Git-integrated workspaces or Shared workspaces.”Source: docs.snowflake.com
Sources2
3.Git-synced workspaces: branch, commit, push, resolve
A workspace can live only in Snowflake, or it can be synced with a branch of a Git repository. To create one, go to Projects » Workspaces, choose From Git repository, paste the repository URL and pick an API integration. That integration must allow the repository URL. Creating one needs the CREATE API INTEGRATION privilege, which is often limited to admins, so most developers only need USAGE on an integration someone else made. The repository must have at least one branch and must be no larger than 2 GB.
| Method | What it needs | Can you push? |
|---|---|---|
| OAuth2 | API integration configured for OAuth with your Git provider. Authorize the snowflakedb app | Yes, with read and write access to code |
| Personal access token | A secret in a database and schema that the API integration allows | Yes |
| Public repository | No authentication | No |
After the workspace exists, you do day-to-day Git work from the Changes tab. You can create a branch from your current branch, switch branches, and use Fetch All to bring in branches created in your Git provider. Pull brings in the latest changes. Changed files are marked M (modified), A (added) or D (deleted), and selecting a file shows a visual diff. Commits use your Snowflake email and username unless you change them under Edit credentials. To publish, write a commit message and select Push. If Snowflake detects conflicts, it asks you to pull first. Files with conflicts are shown with a red M, and you resolve them inline by accepting the current change, the incoming change, or both.
Checkpoint 3 of 6· Put it in order
A push was rejected because of a conflict. Put the resolution steps in order.
- 1.Select a conflicted file to see the differences highlighted inline
- 2.Write a commit message and select Push
- 3.Accept the current change, the incoming change, or both
- 4.In Workspaces, select Changes and find the files marked with a red M
You review the conflict in the Changes view, resolve it in the editor, and then commit and push again.
“After you resolve the conflicts, select Push.”Source: docs.snowflake.com
Checkpoint 4 of 6· Check yourself
A colleague created branch feature/orders in GitHub. It does not appear in your Git-synced workspace's branch menu. What do you do?
Fetch All updates the list of remote branches, so branches created outside Snowsight become available to check out.
“you can fetch it into your Git-synced workspace using the Fetch All option”Source: docs.snowflake.com
Sources3
4.The Git repository clone behind it all
Underneath Git-synced editing is a general integration. Files from a remote repository are synchronised to a Git repository clone in Snowflake, which holds every branch, tag and commit from the remote. Supported platforms are GitHub, GitLab, BitBucket, Azure DevOps and AWS CodeCommit. Repositories based on these platforms are also supported at custom URLs, so a GitHub-based repository does not have to be on github.com. Developers keep their local tools and local repository. Snowflake simply becomes another client.
CREATE [ OR REPLACE ] GIT REPOSITORY [ IF NOT EXISTS ] <name>
ORIGIN = '<repository_url>'
API_INTEGRATION = <integration_name>
[ GIT_CREDENTIALS = <secret_name> ]
[ COMMENT = '<string_literal>' ]With the clone in place, version-controlled code becomes deployable code. You can fetch the latest branches, tags and commits. You can browse folders and copy file paths to use as handler code for functions, tasks or procedures. You can run EXECUTE IMMEDIATE FROM against .sql files, and import repository files into procedures and UDFs. You can also commit and push back to the remote from Workspaces, Streamlit apps and Snowflake notebooks. This is the base for the deployment pipelines covered in the dbt and CI/CD material.
Checkpoint 5 of 6· Check yourself
Which statement about a Git repository clone in Snowflake is accurate?
The clone mirrors the whole remote, including branches, tags and commits. Local tools keep working as before, and ORIGIN must use HTTPS.
“The clone includes all branches, tags, and commits from the remote repository.”Source: docs.snowflake.com
Checkpoint 6 of 6· Exam question
A data engineering team wants to replace ad hoc SQL worksheets with a collaborative, version-controlled editing surface inside Snowsight, so multiple engineers can create branches, review changes, and sync with the team's remote repository without leaving the browser. Which capability should they adopt?
Correct answer: C — Configure a Snowsight Workspace connected to the Git repository so engineers can switch branches and push or pull file changes in the browser.
- A. Manually copying finished statements into a branch happens after the fact and loses the real-time diffing, review, and sync that a version-controlled workflow needs.
- B. A scheduled notebook run tracks execution results, not source code changes, so it does not substitute for a version-controlled editing surface for general SQL development.
- C. A Git-connected Workspace is a file-based development surface in Snowsight where engineers switch branches and push or pull changes, matching the collaborative, browser-based requirement.
- D. A named CLI target configures a connection profile for deployments; it does not provide a browser-based collaborative editing or branching surface for day-to-day SQL work.
Exam traps
Each one states something that sounds right. Open it to see what is actually true.
1.An administrator can turn Workspaces off and send users back to Legacy Worksheets.Why is that wrong?
Workspaces has replaced Legacy Worksheets, including in reader accounts, and an account cannot disable it or revert.
Covered in Workspaces: the development environment in Snowsight
2.Changing the role selector in an open SQL file changes which API integrations and secrets you can use when you create a Git workspace.Why is that wrong?
Access in the creation dialog follows your current role from the Snowsight user menu. The in-file selector affects only that file's SQL.
Covered in Workspaces: the development environment in Snowsight
3.A workspace connected to a public repository without authentication can push commits like any other Git workspace.Why is that wrong?
Choosing the public repository option means no authentication, so you cannot commit and push back to that repository.
Covered in Git-synced workspaces: branch, commit, push, resolve
Sources
Every claim above is drawn from one of these pages, quoted as it was written on the date shown.
- 1.
“Workspaces has replaced Legacy Worksheets in Snowsight, including in reader accounts.”
↩︎ Workspaces: the development environment in Snowsight“This database is used to store workspaces and cannot contain standard objects such as tables or views.”
↩︎ Workspaces: the development environment in Snowsight“Workspaces is a new editor composed of six sections, or panes:”
↩︎ Workspaces: the development environment in Snowsight“You can’t disable Workspaces or switch back to Legacy Worksheets.”
↩︎ Exam trap 1“The role selector inside an open SQL file controls only the SQL statements run in that file.”
↩︎ Exam trap 2“The role selector inside an open SQL file controls only the SQL statements run in that file.”
↩︎ Prediction“Private workspaces belong to you, rather than to the role used to create them.”
↩︎ Checkpoint - 2.https://docs.snowflake.com/en/user-guide/ui-snowsight/notebooks-in-workspaces/notebooks-in-workspaces-overviewOfficial docs
“Notebooks in Workspaces replaces the Legacy Notebooks experience.”
↩︎ Snowflake Notebooks inside Workspaces“Use the native scheduler or incorporate notebooks into orchestration scripts for production pipelines.”
↩︎ Snowflake Notebooks inside Workspaces“Allows multiple users to work in the same workspace with role-based access controls and version history through Git-integrated workspaces or Shared workspaces.”
↩︎ Checkpoint - 3.
“Workspaces can be local to Snowflake, or you can sync workspaces in development with a branch in a Git repository.”
↩︎ Git-synced workspaces: branch, commit, push, resolve“Creating an API integration requires the CREATE API INTEGRATION privilege, which is often restricted to admin roles in many accounts.”
↩︎ Git-synced workspaces: branch, commit, push, resolve“If conflicts are detected, you are prompted to pull first.”
↩︎ Git-synced workspaces: branch, commit, push, resolve“Note that it isn’t possible to commit and push any changes from your workspace to this public repository.”
↩︎ Exam trap 3“After you resolve the conflicts, select Push.”
↩︎ Checkpoint“you can fetch it into your Git-synced workspace using the Fetch All option”
↩︎ Checkpoint - 4.
“files from the remote repository are synchronized to a Git repository clone in Snowflake”
↩︎ The Git repository clone behind it all“Import files from the repository clone into code you run in Snowflake, such as procedures and UDFs.”
↩︎ The Git repository clone behind it all“Through the Git repository clone, Snowflake becomes another client of your repository separate from your local repository.”
↩︎ Key concept“The clone includes all branches, tags, and commits from the remote repository.”
↩︎ Checkpoint - 5.
“Creates a Snowflake Git repository clone in the schema or replaces an existing Git repository clone.”
↩︎ The Git repository clone behind it all