Syntasa provides flexible Git integration to support both day-to-day development and enterprise-level application management. Depending on your workflow, Git repositories can be integrated in two distinct ways: Primary Git, which is one-time configuration at Syntasa application level, and Secondary Git, which is managed as a reusable Connection resource.
Understanding the difference between these two approaches is essential for effectively managing source code, notebooks, and application lifecycles within Syntasa.
Primary Git (Syntasa Infrastructure Level)
Primary Git refers to a Git repository configured at the infrastructure level within Syntasa settings. This repository serves as the default destination for pushing applications directly to the designated primary Git repository.
Purpose
The Primary Git repository in Syntasa serves as the centralized source control integration configured at the infrastructure level. Its purpose is to provide a standardized and consistent destination for version control, enabling teams to push, store, and manage application code, workflows, and configuration changes in a controlled Git environment. By using a Primary Git repository, organizations can support collaboration, maintain version history, enforce governance practices, and streamline deployment and release management processes across projects.
Scope
App Development workflow.
Secondary Git (Git Repo Connection)
Secondary Git refers to a Git repository configured as a Connection Resource under the Resources > Connections menu.
Purpose
Secondary Git acts as a reusable, centralized source of truth for the platform. It is designed for administrative, cross-project, and production-level use cases.
Behavior
The repository is not automatically cloned into a notebook workspace.
Instead, it is accessed by the platform on demand, such as:
During App Import or Export operations
When a Spark or Container processor needs to pull external code or libraries
Supports multiple SCM providers, including GitHub, GitLab, and Bitbucket, with centralized credential management using tokens or SSH keys.
Management
Fully managed through the Resources > Connections interface.
Administrators can:
Test connectivity
Validate repository access
Select a default branch used for platform operations
Scope
Global and shared.
Once created, the Git Connection can be reused by any authorized user across workspaces, pipelines, and environments.
Best Suited For
App Portability: Importing and exporting Syntasa Apps (Dataflows) across environments
Shared Libraries: Referencing common utilities or frameworks in Spark, Container, or BigQuery processors
CI/CD Pipelines: Managing production-ready application definitions and versioned deployments
Comparison Summary
| Feature | Primary Git (Workspace) | Secondary Git (Connection) |
|---|---|---|
| Configuration Location | Notebook Workspace Settings | Resources > Connections |
| Automatic Cloning | Yes (at workspace startup) | No (on-demand by platform) |
| Primary Use Case | Developing and versioning notebooks | App import/export and shared code |
| User Interaction | JupyterLab Git UI or Terminal | Syntasa UI (Apps, Processors) |
| Credential Scope | Workspace-specific | Reusable across the platform |
| SCM Support | Any Git URL | GitHub, GitLab, Bitbucket (optimized) |
Which One Should You Use?
Use Primary Git when starting a new project and you need a version-controlled workspace for developing notebooks (
.ipynb) and scripts.Use Secondary Git (Connection) when working with completed or shared applications, importing an App from a colleague, or maintaining a centralized repository for production assets.
Pro Tip
You can—and often should—use both. A common pattern is to:
Use Primary Git to develop and test custom code in a notebook.
Export the finalized Dataflow App using a Secondary Git Connection to store it in your organization’s central or production repository.
This dual-repo approach provides flexibility for developers while maintaining strong governance and portability across environments.