GitCrew

An interactive, visual Git workbench for VS Code. Browse your repository status, branches, and history, then run everyday and advanced Git operations - merge, rebase, cherry-pick, stash, reset, tag, and guided multi-branch release workflows - through a friendly UI that previews exactly what will happen, plays a short animation of the concept, and only runs after you confirm.

It also bundles a branch-drift radar that highlights lines other branches changed so you can spot merge conflicts before they happen.

Built so a developer, tester, or anyone on the team can perform Git tasks confidently without memorizing commands.

Highlights

• GitCrew panel - a dedicated view in the Activity Bar (the GitCrew icon) with tabs for Status, Actions, Branches, History, and Workflows.
• See before you do - every action shows the exact git commands, a plain-language impact summary, and warnings for anything destructive.
• Learn as you go - each action has a short guide and an animated diagram of what the command does.
• In-panel conflict resolution - when something conflicts, resolve it right in the panel and continue, without dropping to the terminal.
• Smart main-branch detection - automatically finds main, master, trunk, or whatever your team uses, and lets you override it.
• Team workflows - one-click automation for the release-freeze pattern: start a task from the right branch, keep it up to date, and ship it to the working branch - and to main when it's approved.
• Safety net - a warning when you work directly on a protected branch, one click to move that work to a task branch, and Recover Lost Work to undo a bad reset, rebase, or deleted branch.
• Tidy branches - clean up branches whose pull requests are already merged.

The GitCrew panel

Open it from the GitCrew icon in the Activity Bar, or run GitCrew: Open GitCrew from the Command Palette.

Status tab

• Current branch with ahead/behind counts and the detected main branch (click the main-branch chip to change it).
• Staged, unstaged, untracked, and conflicted files. Click any file to open a diff against HEAD.
• Inline actions to stage, unstage, or discard individual files.
• A commit box to write a message and commit (optionally staging everything first).
• Quick buttons for New task, Fetch, Pull, Push, and Stash.
• Protected-branch warning - if you have changes or unpushed commits directly on the main branch or your working branch, a banner explains it and offers Move to a new branch, so the work goes through a pull request like everything else.

Actions tab

Every command is grouped so you can find it fast. Click a group to expand it, click an action to open it.

When you open an action you get:

1. An animation illustrating the concept.
2. A guide explaining what it does and when to use it.
3. A form that asks only for what it needs (branch names, commit messages, options), with pickers pre-filled from your repository.
4. A live Preview panel showing the exact commands, the impact, and any warnings.
5. A Run button. For destructive actions (rebase, reset, clean, force push, delete, discard) Run stays disabled until you have seen the preview.

Results are shown step-by-step, including the output of each command, so nothing is hidden.

Branches tab

Lists local branches (with ahead/behind and current marker) and remote branches. Hover a branch for one-click Switch, Merge into current, Rebase onto, or Delete - each opens the matching action pre-filled and previewed.

History tab

A commit graph of recent history with refs, author, and date. Hover a commit to Cherry-pick it, Revert it, Reset to it, or copy its SHA.

Workflows tab

The guided team workflows, described below, in the order you use them: Start Task, Update Task From Base, Ship Task, and the multi-branch helpers.

Resolving conflicts in the panel

Merges, rebases, cherry-picks, and the team workflows can hit conflicts. When they do, a red Conflicts banner appears at the top of GitCrew and stays until you finish - you never have to drop to the terminal:

• Every conflicted file is listed with actions: open the merge editor, keep current (ours), take incoming (theirs), or mark resolved (stage it).
• Continue finishes the operation once no conflicts remain. For a plain merge/rebase/cherry-pick it runs the matching --continue; for a paused team workflow it resumes the remaining branches automatically.
• Abort safely backs out. For workflows it restores your original branch and keeps your work (the stash is preserved for Replicate), so nothing is lost.

Because of this, the team workflows now pause on a conflict instead of giving up - you resolve it in the panel and click Continue to carry on with the branches that are left.

Smart main-branch detection

Many teams don't use main. GitCrew figures out your trunk in this order:

1. Your gitcrew.mainBranch setting, if set.
2. origin/HEAD (the remote's default branch).
3. git config init.defaultBranch.
4. Common names: main, master, trunk, develop, development, default - local first, then on origin.

If it still can't tell, click the main-branch chip in the header and pick one. Your choice is saved to the workspace.

Team workflows

These automate a common release-freeze situation: while main is frozen you collect approved changes on a temporary branch (for example maintemp), and some changes must also go straight to main.

A task's life in GitCrew: Start Task → work → Update Task From Base if the working branch moved → Ship Task.

Start Task

The first step of every task, in one click (also the New task button on the Status tab, or GitCrew: Start Task):

1. Type the task name, for example login.
2. Start from defaults to your working branch (gitcrew.releaseBranch), or the main branch if none is set.
3. GitCrew switches to that branch, pulls the latest changes, and creates your task branch: login-maintemp from maintemp (or login-maint if gitcrew.releaseBranchSuffix is maint), and plain login when you start from the main branch. You can edit the name.

Changes you already made come along to the new branch. If your local copy of the start branch has commits that aren't on the remote, nothing is created and everything is put back as it was.

Update Task From Base

Teammates keep merging into the working branch while you work, and the longer your task branch lags behind, the bigger the conflicts in your pull request. Update Task From Base fetches the latest version of the branch your task started from (detected automatically) and brings it into your task branch:

• Merge (default) - safe; your commits are not rewritten.
• Rebase - linear history; rewrites your commits, so an already-pushed branch then needs a push with Force with lease.

Uncommitted changes are set aside and put back automatically. Conflicts open the Conflicts banner - resolve and click Continue, or Abort to put your branch back as it was.

Ship Task

The everyday flow for teams in a release freeze: every task goes to the working branch (for example maintemp), and only approved tasks also go to the main branch.

1. Pull the working branch, create your task branch from it (for example login-maint), and make your changes as usual.
2. Open Ship Task from your task branch, write the commit message, and tick Approved if the task is approved for the main branch.
3. Preview, then click Ship task.

What happens:

The two branches get the same changes but stay separate, so each pull request is reviewed and merged on its own. You end up back on your task branch.

GitCrew fills in the form for you:

• Branch this task started from - the gitcrew.releaseBranch setting if you set it, otherwise detected from your task branch (its tracking branch, or the branch it was cut from).
• Main branch - the auto-detected main branch (main, master, trunk, ...).
• New branch for the main branch - your task branch name without the working-branch suffix: login-maint from maintemp becomes login, login-maintemp becomes login. Set gitcrew.releaseBranchSuffix if your team uses a different suffix. You can always edit the name.

Good to know:

• Already committed? Leave the message empty - Ship Task uses the commits on your task branch.
• If the changes conflict with the main branch, the flow pauses: resolve the files in the Conflicts banner and click Continue, or Abort to remove the unfinished main-branch branch. Your task branch and its pull request are kept either way.
• If the main branch already has the exact changes, no empty branch or duplicate pull request is created.
• Before touching anything it checks for mistakes: running on the working branch itself, nothing to ship, a missing commit message, or a main-branch name that already exists.

Commit to Multiple Branches

Commit your staged changes on the current branch, then mirror that exact commit onto one or more other branches and push them all.

• Under the hood it commits once, then git switch + git cherry-pick onto each target, and optionally pushes each branch.
• If a cherry-pick hits a conflict, the flow pauses on that branch. Resolve it in the Conflicts banner and click Continue; the branches updated before the conflict stay updated and the remaining ones carry on. Or Abort to back out.

Use it when a hotfix must land on both a release branch and main.

Replicate Changes to Parallel Branches

Take your current uncommitted changes onto fresh feature branches cut from several bases - for example a feature branch off maintemp (login-maint) and another off main (login).

This replaces the manual dance of "switch, pull, branch, stash, apply, commit, push - then do it all again for the other base." You just:

1. Add one row per base and name the new branch for each (e.g. maintemp → login-maint, main → login).
2. Write one commit message and choose whether to pull each base first and whether to push.

Under the hood it stashes your changes once, then for each row: switches to the base, optionally pulls it, creates the new branch, applies the stash, commits, and optionally pushes. The stash is only dropped after every branch succeeds, so nothing is lost if a step fails. If applying the stash conflicts on a base, the flow pauses so you can resolve it in the Conflicts banner and click Continue; your stash is kept the whole time.

Propose Merges to Multiple Branches

Sometimes the same branch needs to be merged into more than one long-lived branch - for example a fix on your feature branch should be proposed into both main and a postrelease branch. This workflow opens a pull request into each base for you.

1. Pick the branch to propose (defaults to your current branch) and check the base branches to open a pull request into.
2. It pushes your branch once, then opens a pull request page for each base (base ← your branch) in your browser.

The result is one pull request per base, e.g. "merge login into main" and "merge login into postrelease", which reviewers can accept independently. It detects your host from the remote URL and builds the right link for GitHub, GitLab, Bitbucket, and Azure DevOps.

Safety net and housekeeping

Working directly on a protected branch

Your main branch and working branch (or the branches in gitcrew.protectedBranches) are normally changed only through pull requests. If you have changes or unpushed commits directly on one of them, the Status tab shows a warning, and the Commit and Push previews warn too.

Move Changes to a New Branch fixes it in one step: your uncommitted changes and unpushed commits move to a new branch you name, and the protected branch is put back to match the remote - as if you'd started on a task branch all along. Nothing is deleted.

Clean Up Branches

Every task leaves branches behind, and approved tasks leave two. Clean Up Branches checks with the remote and lists local branches that are:

• already merged into your main or working branch, or
• whose remote branch was deleted - which usually means the pull request was merged (this also catches squash-merged pull requests).

Each branch shows why it's listed, and brand-new branches with no commits are shown but not selected. Only branches on your machine are deleted; your main branch, working branch, and current branch are never listed. The result shows the commit each deleted branch pointed to, so any of them can be brought back.

Recover Lost Work

Git remembers every place your branch has been for about 90 days. Recover Lost Work shows those moments in plain words - "Committed "Add login"", "Reset to maintemp", "Switched from login to main", "Finished rebasing login" - with how long ago they happened. Pick the moment just before things went wrong, then:

• Create a new branch there (default) - safe; nothing else changes. Perfect for rescuing commits lost to a reset or a deleted branch.
• Move my current branch back there - undoes a bad reset, rebase, or merge. Your uncommitted changes are kept, the preview is required first, and you can always come back through the same list.

Branch-drift radar

While you work, GitCrew scans other recently committed branches and shows what they changed in the files you are editing - so you see possible merge conflicts before they happen.

• Editor highlights
  • Blue - a teammate changed these lines on a branch that isn't merged into yours yet.
  • Orange - you changed them too, so expect a merge conflict when the branches meet.
  • Hover a highlighted line for a plain-language explanation, the branch, author, and last change, plus Compare with that branch, What is this?, and Hide these highlights.
• Turn the highlights on or off any time with the eye button in the editor title bar (shown when the file has highlights) or in the Branch Drift view, from the status bar tooltip, or with GitCrew: Toggle Drift Highlights. The status bar shows a crossed-out eye while they are hidden, and your choice is remembered.
• Not sure what you're looking at? The first time highlights appear, GitCrew explains them in a short message. GitCrew: What Are the Drift Highlights? (or the ? button in the Branch Drift view) opens a one-page guide with an example.
• Branch Drift tree view - in the Source Control sidebar, each branch lists the files it changed; click one to diff it against your HEAD.
• Status bar - shows Drift: N files and turns warning-colored when any overlap your local edits. Hover it for the branches involved and to show or hide the highlights.

Enjoying GitCrew?

If GitCrew saves you time, a quick rating really helps others find it. GitCrew shows a gentle prompt after you have used it for a while, with Rate GitCrew, Remind me later, and No thanks - your choice is remembered. You can also click the ★ in the panel header, or run GitCrew: Rate GitCrew any time, to open the review page.

Commands

Most Git operations are performed from the GitCrew panel rather than the Command Palette.

Settings

Getting started

1. Open a folder that contains a git repository.
2. Click the GitCrew icon in the Activity Bar.
3. Use the Status tab for day-to-day work, the Actions tab to run any Git command with a preview, and the Workflows tab for multi-branch release flows.
4. If the main branch chip looks wrong, click it and pick the right one.

Safety notes

• Nothing runs until you press Run; destructive actions require you to view the preview first.
• Previews use read-only git queries (dry runs, rev-list counts, diff stats) and never modify your repository.
• Multi-step workflows stop at the first failure and report exactly where, so you are never left guessing.

Requirements

• VS Code 1.85.0 or higher
• git installed and on your PATH
• A git repository in the first workspace folder

Author

Kanaihya Kumar - kanaihyakmr@gmail.com

License

MIT