Merging and Pull Requests

Merging branches happens in your Git provider — GitHub, GitLab, or Azure DevOps — not in Koodisi. Koodisi pushes your branch to the remote and pulls the merged result back; everything between those two points is your provider's pull request flow. This page covers what that division means in practice, which merge strategy to choose, and how to verify the merged result once it lands.

What Koodisi does and does not do

Operation	Where it happens
Commit, push, and pull your branch	Koodisi, in the Version Control panel
Integrate remote commits into the branch you have checked out	Koodisi, using Pull
Merge one branch into another	Your Git provider, through a pull request
Choose a merge strategy such as squash	Your Git provider
Resolve a merge conflict	Your Git provider's merge editor
Publish and deploy the merged result	Koodisi, after Pull

Pull does perform a merge — it integrates the remote commits on your current branch into your local copy. What Koodisi has no interface for is merging one branch into another, and resolving a merge that conflicts. If a pull cannot be merged cleanly, Koodisi reports Merges with conflicts are not supported yet. and stops without changing your files. See Handling Merge Conflicts.

info

There is no merge, squash, or cherry-pick action anywhere in Koodisi. If a workflow you are designing depends on one, it belongs in your Git provider or in a local clone of the repository.

Raising a pull request

1. In the Version Control panel, stage your changes on the Changes tab and select Commit and Push. See Using Git with Applications.
2. Open your Git provider and raise a pull request from your feature branch to the target branch — typically develop, main, or master.
3. Have your team review the artifact-level changes. Every workflow, schema, resource, and configuration file that changed appears in the pull request, so review the whole file list rather than only the files you expected to touch.
4. Complete the merge in your provider, using the merge strategy your organization has agreed.

How you know it worked

The pull request shows as completed or merged in your Git provider, and the target branch's history contains your commit. To confirm from inside Koodisi, check out the target branch, select Pull, and open the Commits tab — your commit appears in the list. See Reviewing Commit History.

Choosing a merge strategy

Your Git provider offers several ways to complete a pull request. The choice is a provider setting and an organization policy — Koodisi neither sets nor enforces it, and works the same way whichever you pick.

Strategy	What lands on the target branch	When it suits Koodisi work
Squash and merge	One commit containing the whole feature branch	The usual choice for feature branches. You commit as often as you like while building, and the target branch keeps one reviewable commit per completed feature.
Merge commit	Every branch commit, plus a merge commit	Use when the individual commits carry meaning worth keeping, such as a sequenced schema migration.
Rebase and merge	Every branch commit, replayed onto the target	Use only where your team already understands rebasing; it rewrites commit identities.

Squash merging

Squash merging combines a feature branch's intermediate commits into a single commit on the target branch. It pairs well with the way Koodisi work is done: your local changes live in your browser's LocalDataStore until pushed, so you are encouraged to commit and push small changes often — and squashing means that frequency does not clutter the shared branch history.

A squashed feature branch looks like this:

feature/person-b
 ├─ Updated schema 'Person'.
 ├─ Updated workflow 'PersonIntake'.
 ├─ Updated schema 'Person'.
 └─ Updated resource 'field-map'.
                    │
                    ▼  Squash and merge
develop
 └─ Add Person B integration changes

Two things to know before adopting it:

• Squashing discards the individual commit messages. Koodisi generates commit messages from the files you staged — Updated workflow 'PersonIntake'. — so the squashed commit message is the one place a reader learns why the change was made. Write it deliberately in the pull request.
• The squashed commit is a new commit. Your local feature branch still points at the original commits, so it is not an ancestor of the target branch. After a squash merge, delete the feature branch rather than continuing to work on it, then create a fresh branch from the updated target branch.

warning

Do not squash or rewrite history on shared or long-lived branches such as develop, main, or a release branch. Squashing is for merging a feature branch into a target branch. Rewriting a branch other people have checked out forces everyone to re-clone.

After the merge

1. In the Version Control panel, open the Branches tab and check out the target branch.
2. Select Pull so your local copy includes every contributor's merged work.
3. If the merged feature branch was deleted in your provider, select More > Fetch & Prune to drop the stale remote-tracking branches from the Remote list.
4. Validate the merged state — confirm the schemas, subflows, and mappings you depend on are the ones you expect.
5. Publish and deploy from this branch. See The Development Lifecycle.

warning

Publishing captures the application as it exists on the branch you currently have checked out. Confirm the target branch is checked out in the Version Control panel before you publish — publishing from a feature branch publishes that branch's state, not the merged result your team reviewed.

When it does not work

Symptom	Cause	What to do
Pushes to this branch are not permitted; you must use a pull request to update this branch.	The remote branch is protected by your Git provider.	This is the protection working. Push to a feature branch instead, then raise a pull request into the protected branch.
Push rejected because it was not a simple fast-forward.	The remote branch moved ahead of your local branch after you committed.	Follow the committed-work recovery path in Handling Merge Conflicts.
Merges with conflicts are not supported yet.	Pull found changes on the remote that conflict with your local commits.	Resolve in your Git provider using the temporary-branch path in Handling Merge Conflicts.
The merged commit is not in Koodisi after the pull request completed	You are on the feature branch, or have not pulled since the merge.	Check out the target branch and select Pull. Confirm the branch name shown at the top of the Version Control panel.
Branches that were deleted in the provider still appear under Remote	Remote-tracking references have not been refreshed.	Select More > Fetch & Prune.

Next steps

• Parallel Development with Multiple Developers — how to divide work so merges stay small
• Handling Merge Conflicts — the recovery paths when a merge does conflict
• Reviewing Commit History — confirming what actually landed on a branch