Using Git to Develop Applications
Git integration lets you manage your application's source in a Git repository. Koodisi keeps a working copy in your browser and pushes and pulls against your remote — GitHub, GitLab, Azure DevOps, or a self-hosted server. For a team, Git is not just a backup: it is the collaboration model that lets several developers build one integration without overwriting each other.
New here? Start with The Development Lifecycle for the end-to-end path a change takes from your workspace to production, and which stages happen in Koodisi versus your Git provider. The pages below cover each part in depth.
Getting started
- The Development Lifecycle — how a change reaches production, and which stages live where
- What Git-Enabled Applications Are — where your work is stored, and what Koodisi does and does not do
- Creating a Git-Enabled Application
- Add Git to an Existing Application
- Single vs. Multi-Module Repositories
Working day to day
- Using Git with Applications — the Version Control panel: staging, committing, branches, and stashes
- Reviewing Commit History — reading and searching a branch's commits
- Cloning Git Applications
- Deleting Git Applications
Collaborating as a team
- Merging and Pull Requests — raising a pull request, choosing a merge strategy such as squash, and pulling the result back
- Parallel Development with Multiple Developers — dividing work so branches stay independent
- Git Workflow for Development — organizing a main flow and its subflows
- Handling Merge Conflicts — recovering from a conflicting pull or a rejected push
Policies and governance
- Git Branching Policy — organization branch naming rules
- Protecting Deployment Branches — restricting which branches can deploy
Guidance and troubleshooting
- Working with Git Applications: Best Practices
- Schema Guidelines — how schemas are tracked per branch
- Managing the Local Datastore — export, import, and clear
- Troubleshooting Guide — credential, clone, push, and datastore errors
Where to start
If you are setting up for a team, read The Development Lifecycle, then agree the working model in Parallel Development with Multiple Developers before anyone creates a branch.