Working with git
Dotvault does not replace git. It reads your existing repo’s state, surfaces useful information alongside each env file, and gives you a focused way to stage and commit env files in particular. Everything else — branches, merges, pushes, pulls — stays in your normal git workflow, where it belongs.
What the sidebar tells you
Each env file in the sidebar gets a small status badge reflecting its state in git:
- M — modified since the last commit.
- S — staged and ready to commit.
- U — untracked by git.
- I — ignored via
.gitignore.
A clean file shows no badge at all. These badges are live — save an env file and its status updates immediately.
Blame information
For files tracked in git, each variable row shows blame information beneath the value: who last changed it and when. Hover the blame text to see the commit hash and message. Handy for answering “when did DB_HOST change and who did it” without leaving the editor.
The Git tab
Switch to the Git tab on any project to manage env-file changes directly:
- Select the files you want with the checkboxes and click Stage.
- Type a commit message and click Commit.
- Browse recent commit history in the same panel.
Dotvault deliberately only stages and commits .env files from this panel. If you have other staged or modified files in the repo — say from running git add in your terminal — the Git tab shows a count of them and warns you they’ll be included in your commit. That warning is important: a Dotvault commit uses your repo’s index as-is, so anything already staged will ride along whether you meant it to or not.
Deleting files
Dotvault protects files that git knows about. You can only delete env files that are untracked. Hover an untracked file in the sidebar and click the trash icon — Dotvault asks whether to remove it from the app only or delete it from disk as well. For tracked, staged, or ignored files, manage deletion through git itself.
Exposed secret warnings
When a value in a tracked, non-gitignored file matches a known secret pattern — Stripe keys, GitHub tokens, AWS credentials, and similar — Dotvault flags it as an exposed secret. The fix is almost always one of two things: add the file to .gitignore, or rotate the secret. The warning won’t block saving, but it’s a strong hint you don’t want to push it as-is.
If git isn’t available
Git integration is optional. If git isn’t installed on your system, or a project folder isn’t a repo, all git indicators and the Git tab are hidden automatically. Dotvault degrades cleanly — you just lose the status badges and blame.
You can also switch git integration off manually in Settings. That hides status badges, blame info, and the Git tab without touching your repo.
Best practices
- Keep real secrets out of tracked files. Use
.env.example(or.env.sample/.env.template) for shape, not values. - Commit env changes through the Git tab when you can — it makes the warning about unrelated staged files visible.
- Heed exposed-secret warnings before you push.
- For encrypted env files, commit the
.env*.encryptedfile to git and share the key out of band.