What are Git-enabled applications?
A Git-enabled application is one whose source is version-controlled in a Git repository. Koodisi keeps a working copy in your browser and pushes and pulls against a remote repository — GitHub, GitLab, Azure DevOps, or a self-hosted Git server. Understanding where each copy lives is the key to working confidently, because the two are not kept in step automatically.
How the storage works
There are two places your work exists:
| Location | What it holds | What it means |
|---|---|---|
| Your browser's LocalDataStore | The working copy, your local branches, commits, and stashes | Specific to one browser on one machine. Not a backup, and not visible to your team. |
| The remote repository | Everything that has been pushed | The shared source of truth, and the only copy your team and your other devices can see. |
Committing writes to the local datastore. Pushing is what makes work exist anywhere else.
An unpushed change exists in exactly one place: the browser you made it in. Clearing site data, switching browsers, or moving machines loses it. Push regularly.
What being Git-enabled gives you
- Version control — track what changed, who changed it, and when, and roll back when you need to. See Reviewing Commit History.
- Branching — work on a feature branch, leave protected branches protected, and merge through a reviewed pull request. See Using Git with Applications.
- Collaboration — several developers build one integration in parallel without overwriting each other. See Parallel Development with Multiple Developers.
- Repository structure — one application per repository, or several applications in one multi-module repository. See Single vs. Multi-Module Repositories.
- Deployment provenance — a deployment records the branch, commit, and repository it came from, so you can tell what is actually running.
What Koodisi does not do
Koodisi covers the local half of Git — staging, committing, branching, stashing, pushing, pulling, and reading history. It does not merge one branch into another, resolve conflicting merges, squash, or move individual commits between branches. Those happen in your Git provider's pull request interface.
Pull does merge remote commits into the branch you have checked out, and handles that cleanly. What it cannot do is complete a merge that conflicts — it stops and leaves your files unchanged. See Merging and Pull Requests.
Next steps
- Creating a Git-Enabled Application — start a new one
- Add Git to an Existing Application — connect one you already have
- The Development Lifecycle — the end-to-end path to production