Setting up Snowflake to use Git¶
When you connect your Snowflake account to a remote Git repository, Snowflake creates a Git repository clone and stores metadata about the location of the remote repository, credentials (if needed), and configuration details about how Snowflake should interact with the Git repository API.
Setting up requires two decisions: which network path to use (public or private) and which authentication method to use.
Choose your use case¶
The following use cases can help you pick the right authentication method:
Interactive development (pulling, pushing, and creating files): configure OAuth authentication to simplify sign-in for Workspaces users.
Automated pipelines or ML projects: configure token-based authentication so that scripted processes can access the repository without manual sign-in.
Quick start with a public repository (including Snowflake Labs): use no authentication to clone a public repository and run SQL scripts, notebook files, or Python files in Workspaces.
Choose your network path¶
After you know which authentication method you need, choose how Snowflake connects to your Git server:
Access over a public network |
Access over a private network |
|---|---|
Access over a public network allows you to authenticate to your remote Git repository server over the public internet. If your Git server uses IP-based allowlisting, Snowflake can route Git traffic through stable egress IP addresses on supported cloud providers. For details, see Securing ingress of Snowflake requests with egress IP addresses.
|
Access over a private network routes Git traffic through a dedicated outbound private link connection instead of the public internet. Use this when your organization requires full network isolation between Snowflake and your Git server.
|