← All extensions
Source Control banner

Source Control

ivyx✓

Stage, commit, and read your history as a branch graph in a Git sidebar next to your files

Source Control

Stage, commit and discard your Git changes from a sidebar panel, and read your project's history as a branch graph in the same place.

What you can do

  • Review your working-tree changes, split into Staged and Changes lists.
  • Stage or unstage files one at a time or all at once.
  • Commit your staged changes, or commit and push in one step.
  • Ask the active AI core to write the commit message from what you have staged, in the style of your recent commits.
  • Discard changes to a file after confirming.
  • Open any file's diff in the editor, in one column or side by side.
  • Fetch, pull and push from the panel's toolbar.
  • Switch or create branches from the branch name in the status bar.
  • Follow your history as a graph, with a lane per branch, and click a commit to see the files it changed.
  • Start tracking a folder that is not a Git repository yet.
  • Turn an MLOps pipeline into a GitHub Actions workflow that runs the same checks, and add a pre-push gate that runs them before you push.

Getting started

Open Source Control from the activity bar. In a Git repository your changes are listed there; in any other folder the panel offers Initialize Repo. The sparkle button in the commit message box writes a message for you, and the Graph sits at the bottom of the panel. The CI actions are in the command palette under names that start with MLOps:.

Requirements

  • An active AI core, for the written commit messages.
  • For the CI actions, a pipeline built with MLOps, and the GitHub CLI signed in to read the status of remote runs.

Good to know

  • The graph only reads your repository and never writes to it.
  • Your commit history teaches the message writer form only, never content, and nothing leaves your machine unless the AI core you picked is a remote one.
  • Generating the workflow writes nothing if a stage cannot run outside the editor, and tells you why.
  • The pre-push gate runs the gates only, never training. git push --no-verify bypasses it, and a hook you already had is never replaced.
  • Secrets are never sent anywhere. The workflow names any missing one and hands you the gh secret set line to run yourself.