Hi Slavko, Thanks for the information and for sharing the SnapLogic documentation.
At the moment, our organization’s Git strategy doesn’t allow us to follow a trunk-based development approach.
Our current setup is structured as follows:
Each SnapLogic Project Space maps to a single source repository in GitHub for a given source/target combination.
Within that repository, each project or application is organized into its own separate folder.
We may have multiple developers working concurrently on different projects within the same repository.
Given this model, we’re trying to understand how best to manage the following statuses in SnapLogic:
Our main concern is around parallel development. For example, if multiple developers are working in different project folders but within the same repository, how does SnapLogic recommend handling asset tracking and commits to avoid conflicts or unintended overwrites? In particular:
How should we manage “Modified Locally” assets when multiple developers are committing to the same repository?
What is the recommended approach when assets appear as “Conflict Tracked” in this multi-project, multi-developer setup?
Are there best practices for aligning SnapLogic asset tracking with a non–trunk-based branching strategy (e.g., feature branches or environment-specific branches)?
We want to ensure our Git workflow remains consistent with our organization’s standards while still leveraging SnapLogic’s Git integration effectively.
Appreciate your guidance on how best to align these approaches.
