Repair branches: AI fixes you review before anything is merged
How Vidabug commits each repair to a separate branch in your repository, what it never does, and how you decide what to merge.
When Vidabug meets a defect while testing your app, it documents it, repairs it and tests the repair again. Where that repair goes is your decision.
The rule
Your software. Your code. Your branches. Your decision.
Vidabug only writes to a repository when its owner has authorised repair branches. Even then, it writes only to its own branch for that job. It never pushes to your main branch, and it never merges.
What happens in a repair
- The defect is recorded: a screenshot, the steps that cause it, and the root cause in the code.
- The repair is made in the private machine that runs the job, with the code before and after.
- The repair is tested again and the result is recorded, with a screenshot after the change.
- The commit goes to the repair branch, with a message that says what it fixes and why.
- A pull request is opened so you can review the changes with the tools you already use.
When you have not authorised repair branches
Nothing is pushed. Vidabug still finds and repairs defects in its own copy, and you receive the changes as a patch file with the report. The delivery note says plainly that nothing was pushed.
Video-only jobs never change code
"Create an Application Video" never writes to your repository, whatever you have authorised. It uses a read-only connection, or your live app alone.
Reviewing a repair
Treat every repair as a proposal. Read the diff, run your own tests, and merge it only when you are satisfied. The project page shows each repair branch, its commits, its verification result and whether it has been merged.
What it does not cover
Vidabug can miss defects, and it does not certify software as bug-free. It is not a penetration test or a load test. Problems outside your code, such as a third-party service being down, are reported, not changed.