Keep Repeatable Git Tasks in SourceTree with Custom Actions

You are in SourceTree reviewing a pull request, and the template asks for the source branch name. You switch to a terminal, run git rev-parse --abbrev-ref HEAD, copy the output, switch back, and paste. It takes thirty seconds, but it breaks your focus—and if a teammate asks how you did it, the answer lives in your shell history, not in the team’s shared workflow.

SourceTree Custom Actions let you bind small, repeatable Git commands to menu items inside the client. Once configured, an action runs against the currently open repository as its working directory. This keeps routine chores visible in one place instead of scattering them across terminal windows.

What a custom action is

A custom action is a user-defined command stored in SourceTree’s client settings. It is not part of the repository, so it does not travel with a clone or appear in .git/config. After you save it, SourceTree lists it under a Custom Actions menu. You choose the executable, any arguments, and whether SourceTree shows a window with the command output.

Because the command runs in SourceTree’s environment, it may not see the same PATH or shell profile as your login terminal. Version-managed tools such as nvm or pyenv can resolve differently. Treat custom actions as GUI shortcuts for simple, non-interactive jobs, not as replacements for repository hooks or CI enforcement.

Worked example: copy the current branch name

This example is read-only: it reads the current branch and places it on the clipboard. It requires no parameters and no administrative permissions.

macOS

Open SourceTree settings, locate Custom Actions, and add a new action. Use the shell and a command such as:

git rev-parse --abbrev-ref HEAD | pbcopy

Set the working directory to the selected repository, leave parameters blank, and decide whether to show output. Since pbcopy writes to the clipboard, hiding the output window is usually fine.

Windows

On Windows, use the clipboard command available to the shell SourceTree invokes. In PowerShell, for example:

powershell -NoProfile -Command "git rev-parse --abbrev-ref HEAD | clip"

Quoting differs between PowerShell and Command Prompt, so do not copy the macOS command verbatim. Test the exact string on a Windows machine before sharing it with a mixed team.

Verify the result

1. Create a scratch repository with one commit and a feature branch.
2. Add the read-only action above in SourceTree.
3. Select the repository in SourceTree and run the action from the Custom Actions menu.
4. Paste into a pull request template or text editor.
5. In a terminal, run git rev-parse --abbrev-ref HEAD and confirm the values match.

Expected behavior: the clipboard contains only the short branch name, with no extra terminal decoration. If the values differ, SourceTree may be using an embedded Git installation rather than your system Git.

Trade-offs and limitations

• Per-user only. Custom actions are client settings. Teammates must recreate them; they are not enforced or versioned with the repository.
• Environment differences. SourceTree often bundles its own Git. Run a custom action that executes git --version and compare it with your system Git to spot version or flag differences.
• No TTY. Commands that expect interactive input, such as git add -p, may fail because a menu item does not attach a terminal. Keep a terminal fallback in your team runbook.
• No secrets. The command text is visible to anyone with access to the machine and may appear in screenshots or settings backups. Never store tokens or passwords in an action.
• Avoid one-click destructive commands. Force pushes, hard resets, and clean operations are easier to mis-click in a GUI menu than to run deliberately in a terminal.

Actionable closing

Start with one read-only action, such as copying the branch name or showing the embedded Git version. Verify it on a scratch repo, test it on both Windows and macOS if your team is mixed, and document which commands belong in the terminal instead. Custom Actions work best when they remove small friction points without pretending the GUI can replace every Git workflow.