Parallel Development with Multiple Developers

For a single developer, working locally in one workspace is manageable. For several developers building one integration over weeks or months, Git is the collaboration model — and the way you divide the work matters more than any Git command. This page sets out an operating model that keeps branches independent, sequences shared artifacts, and keeps conflicts rare enough to be handled as exceptions.

The principle behind all of it: the recommended model is not several developers editing the same workflow. It is a stable main flow with focused feature or subflow branches, each owned by one developer, reviewed and merged through your Git provider.

Dividing the work

Split parallel work along boundaries that map to separate files in the repository:

Boundary	Example	Why it works
Subflow	One developer owns the employee demographics subflow, another owns benefits and deductions	Each subflow is its own artifact, so the branches do not touch the same files
Feature	An intake path, a reconciliation path	Natural review units, and each maps to one pull request
Schema migration	A shared Person schema moving to a new shape	Schemas are consumed by many workflows, so they need their own branch and their own merge
Resource or configuration	A shared endpoint resource, a deployment profile value	Same reasoning as schemas — shared inputs, sequenced separately

Keep the main orchestration flow stable. Merge completed subflows first, then create a short wiring branch that connects them into the main flow. The main flow stays the reviewed source of truth rather than a file everyone edits at once.

Sequencing shared artifacts

The most common cause of a genuine conflict is two branches editing one shared schema or resource. Shared artifacts are sequenced, not parallelized:

1. Create a branch containing only the shared change — for example feature/schema-employee-v2 from the up-to-date target branch.
2. Apply the schema or resource edit and nothing else. Commit and push.
3. Raise a pull request and merge it into the target branch first, before the dependent feature branches go far.
4. In each dependent branch, check out the target branch, select Pull, then create or re-sync the feature branch so it maps against the new shape.

Schemas need tighter discipline than workflows because workflow mappings depend on their shape, and because an edited schema becomes branch-scoped. See Schema Guidelines.

The working agreement

These are the rules to agree as a team, in the order they apply during a normal day:

1. Check out the target branch and select Pull before creating any work branch. A new branch inherits whatever you currently have checked out.
2. Create one focused branch per feature, subflow, schema migration, or shared-resource change.
3. Update your own Credentials at the start of a session so commits carry the right author. See Using Git with Applications.
4. Build and validate in Koodisi. Commit and push small changes often — LocalDataStore is browser-specific, so unpushed work exists in exactly one place.
5. If the target branch moves while your branch is open, check out the target branch, pull, and sync before your final pull request.
6. Raise pull requests in your Git provider. Resolve any conflicts there. See Merging and Pull Requests.
7. After the merge, return to Koodisi, check out the target branch, select Pull, and select More > Fetch & Prune if branches were deleted.
8. Validate the merged state, then publish and deploy only from the reviewed target branch.

A worked example: three developers, one release

Three developers deliver one integration release against a develop target branch.

Developer	Owns	Branch
Developer 1	Employee demographics subflow	feature/employee-demographics-subflow
Developer 2	Benefits and deductions subflow	feature/benefits-deductions-subflow
Developer 3	Shared resources and deployment profile configuration	feature/shared-resource-config

The sequence:

1. The shared Person schema change is needed by both subflows, so it goes first, on its own branch, and is merged into develop before the subflow work begins in earnest.
2. Each developer checks out develop, pulls, and creates their own branch from it.
3. Each developer changes only the artifacts they own, plus directly related resources.
4. Each publishes their branch to Development and validates it before pushing for review. See The Development Lifecycle.
5. Each raises a pull request into develop. Because the branches touch different files, the merges are independent.
6. Once the subflows are merged, a short wiring branch connects them into the main orchestration flow.
7. Someone checks out develop, pulls, confirms the branch name in the Version Control panel, and publishes from there.

This proves the point worth making to a client: parallel development works when ownership is split by artifact boundary, and shared dependencies are merged early so dependent branches can sync before continuing.

Handling long-running branches

A branch that runs for weeks without syncing accumulates drift, and drift becomes one large conflict at the end of the release. Sync regularly instead:

• Check out the target branch, pull, and bring those changes into your feature branch at a natural pause — after a subflow is complete, not mid-edit.
• Keep the branch's scope focused. A branch that grows to cover three features is three merges' worth of risk in one pull request.
• Validate after syncing. The base changed, so the behavior you validated a week ago is no longer the behavior you are about to merge.

For an urgent fix while feature branches are open, create a hotfix/ branch from the production or target branch, validate it, merge it through a pull request, publish from the target branch, then have every active feature branch pull the target branch.

What not to adopt as the model

Avoid	Why	Instead
Two developers editing the same workflow at once	This is the pattern that produces overlap and conflicts	Split into subflows or focused feature branches
Everyone working directly on develop or main	Removes the review gate and risks accidental overwrite	Feature branches with pull request review
Expecting to resolve merge conflicts in Koodisi	Koodisi has no merge editor	Resolve in your Git provider's pull request interface
Leaving work unpushed for long periods	LocalDataStore is browser-specific and is not a shared backup	Commit and push small changes frequently
Deleting a shared schema	Deletion breaks references in Git-enabled and cloned applications	Deprecate, or manage through the registry
Publishing from an unmerged feature branch	Publishing captures the checked-out branch's state	Check out and pull the target branch, then publish
Letting a long-running branch drift	Turns many small conflicts into one large one	Sync with the target branch regularly

Common mistakes and how to recover

Symptom	Cause	What to do
The new branch contains someone else's unrelated work	A branch inherits the branch you had checked out when you created it	Check out and pull the intended parent branch, then create the branch again
You cannot switch branches	Koodisi blocks a switch while the current branch has uncommitted changes	Commit, stash, or discard first. Koodisi offers Stash Changes or Commit Changes when you attempt the switch
Unrelated files appear in your pull request	Shared artifacts changed, or an older schema was written into the branch on first edit	Review every changed file before merging. See Schema Guidelines
A schema behaves differently across two branches	An edited schema is tracked in the branch that edited it, while other branches still use the reference	Merge the schema change to the target branch, then have dependent branches pull
Commits are attributed to the wrong person	Several developers used one saved credential	Each developer updates their own Credentials at session start

Next steps

• Merging and Pull Requests — the merge strategies and the post-merge path
• Git Workflow for Development — organizing a main flow and its subflows
• Handling Merge Conflicts — the recovery paths