git-pro

What it does

git-pro is a single-window Electron app for developers who juggle more than one git identity — a work account and a personal account being the usual pair. A profile bundles user.name, user.email, and an SSH private key; activating a profile writes those values into git config along with a core.sshCommand that pins the right key. Activation works globally or per-repository. The app also manages SSH keys: generate (ed25519, RSA 4096, ECDSA 521), list with fingerprints, copy the public key, add to ssh-agent, test auth against a host, delete.

1
# git-profile: work
2
name=Prashant Chaturvedi
3
email=prashant.chaturvedi@o612.in
4
sshkey=/home/pc/.config/git-profile/keys/work

It is a frontend for the git-profile bash CLI. Both programs read and write the same files under ~/.config/git-profile (or $GIT_PROFILE_HOME), so a profile created in the app activates from the terminal and vice versa — the directory is the API.

Why I built it

The CLI is fine when I’m already in a terminal, but identity state is something I want to see: which profile is active, which key a profile points at, and whether that key file still exists. The GUI surfaces the warnings a CLI only shows when you remember to ask — a profile whose configured private key is missing is flagged in the detail pane, not discovered on the next failed push. The constraint I cared about most was honesty: no database, no sync service, no second source of truth. The files stay authoritative.

Key features

• File-format compatibility — same .profile files, same keys/ directory, same active state file as the CLI, including parser semantics (first key= wins) and owner-only permissions.
• Scoped activation — global (~/.gitconfig) or a picked repository’s local config, with a git rev-parse --is-inside-work-tree check on the chosen directory. Editing the active profile re-activates it so git config can’t drift.
• Managed SSH keys — generate, fingerprint, copy public key, ssh-add, and ssh -T auth tests, all against the system binaries rather than bundled libraries.
• Sandboxed renderer — contextIsolation, nodeIntegration: false, sandbox: true, and a narrow contextBridge API; all argument validation happens in the main process.
• No framework, no build step — plain HTML/CSS/JS renderer (~1,300 lines total); npm start runs it.