Why connect GitHub?
By default, Myndlab stores your project's generated code internally. Connecting a GitHub repository lets you:
- Keep a complete, auditable history of every build and iteration
- Collaborate with developers who prefer working locally in their own editor
- Run your existing CI/CD pipeline (tests, linting, deployments) on every push
- Use pull requests for code review before changes go live
- Fall back to the repo if you ever stop using Myndlab — the code is yours
Connect a repository
1
Open Project Settings
From the Build screen, click the project name at the top of the left rail → Settings → Git.
2
Authenticate with GitHub
Click 'Connect GitHub'. You'll be redirected to GitHub to install the Myndlab GitHub App on your account or organisation. Grant access to the repositories you want to use.
3
Choose a repository
Select an existing repo from the dropdown, or let Myndlab create a new empty one. If the repo already has code, Myndlab will read it before any future builds.
4
Choose a branch
Select the branch Myndlab should push to. The default is 'main'. For team projects we recommend using a dedicated branch like 'myndlab' or 'generated'.
5
Save
Click Save. Myndlab will do an initial push of the current project code to the selected branch.
ℹNote.The Myndlab GitHub App requests read/write access only to the repositories you explicitly select during setup. It never accesses other repos in your account.
Push generated code
Once a repository is connected, every successful build automatically pushes a commit to the configured branch. The commit message includes the prompt excerpt and a build ID:
git log
commit 3f8a2c1
Author: Myndlab Build Agent <builds@myndlab.ai>
Date: Mon May 25 11:42:03 2026
[myndlab] Add real-time search filter to contacts list
Build: ml-20260525-114203
Changed: src/components/ContactsList.tsx, api/routes/contacts.pyYou can also trigger a push manually at any time from Settings → Git → Push now. This is useful if you connected GitHub after the initial build and want to sync the current state.
Pull external changes
If a developer on your team modifies files in the repo directly (outside Myndlab), you can pull those changes into the Myndlab editor:
1
Open Settings → Git
You'll see a 'Changes available' banner if the remote branch is ahead of Myndlab's local copy.
2
Click Pull
Myndlab fetches the remote changes and applies them to the project files. A diff summary shows what changed.
3
Review the diff
Check the diff in the file explorer. Myndlab highlights files that were modified externally so you can spot unexpected changes.
4
Continue building
The editor now reflects the pulled changes. Your next build will use the updated codebase as its starting point.
Branch workflow
For team projects or when you want to experiment without affecting production, use a branch-per-feature workflow:
1
Create a branch in Settings → Git
Click 'New branch', name it (e.g. 'feature/search-filter'), and select it as the active branch. Myndlab switches its push target immediately.
2
Build on the branch
All builds while the branch is active push commits there, not to main.
3
Open a PR on GitHub
When the feature is ready, open a pull request from GitHub's UI. Your CI pipeline runs, teammates review, and you merge as normal.
4
Switch back to main
Return to Settings → Git and reselect the main branch. Myndlab resumes pushing there.
💡Tip.Name branches descriptively. Myndlab includes the branch name in build log entries, which makes it easy to trace which feature a particular build was for when reviewing history.
Handling conflicts
A conflict occurs when Myndlab's generated code and an external change both modify the same file in incompatible ways. Myndlab detects this before pushing and surfaces the conflicting files in the editor.
You have two options when a conflict is detected:
1
Accept Myndlab's version
Myndlab's generated code takes precedence. External changes to the conflicting file are discarded. Use this when you trust the latest build output.
2
Accept the external version
The externally-modified file is kept as-is. Myndlab's changes to that file are not applied. Use this when a developer has done significant manual work you don't want to overwrite.
⚠Watch out.Frequent conflicts usually mean too many people are editing the same files in different tools simultaneously. The cleanest pattern is: let Myndlab own the generated files, and keep any hand-written custom logic in separate files that Myndlab is told not to touch.