DevNotes+
Sharing notes with your team
Notes are private until you say otherwise. Sharing one puts it through git like any other file in the repo — reviewable in a diff, visible in a PR, and merged the same way.
Private by default
The first time DevNotes+ creates .devnotes/ in a project, it writes a .gitignore inside it containing a single line:
*Everything in the folder is ignored. You can write whatever you like — half-formed ideas, complaints about the code, notes on a bug you have not reproduced yet — and none of it reaches the repository.
If your project already has a rule that force-adds files, or a global gitignore that behaves unusually, confirm with git status after your first note that .devnotes/ is genuinely untracked. It takes ten seconds and the alternative is committing your private notes.
Sharing one note
Open a note's overflow menu and toggle Share this note.
DevNotes+ then adds a negated entry to .devnotes/.gitignore that un-ignores that one file. Any images the note references are un-ignored too, so the note arrives at your teammate complete rather than with broken image links. The first time you share anything, .gitignore and tags.json are un-ignored as well — the team needs both for sharing to work at all.
The result is an ordinary Markdown file, staged and committed like any other change:
git add .devnotes
git commit -m "notes: document the retry floor"Un-sharing is the same toggle in reverse. Note that this stops future changes from being tracked — a note you have already committed stays in the repository's history until you remove it there, exactly like any other file.
Share the notes that answer “why is this like this?” — the ones a reviewer or a future maintainer would otherwise have to ask about. Keep working notes and reminders to yourself. The value of a shared note collection drops fast when it fills up with other people's todo lists.
One tag set for the team
.devnotes/tags.json holds your tag definitions — labels, colours, icons and order — and it is committed as soon as anyone shares a note. That means a repo has one tag vocabulary rather than one per developer, and a note tagged Bug means the same thing wherever it is read.
Because it is a tracked file, changing tags is a change your team reviews. Renaming a tag or changing its colour turns up in the diff like anything else.
Seeing what changed
The Activity section of the sidebar lists recent note changes with an author and a timestamp, marking whether each was created or updated. Three kinds of author show up: you, your teammates, and Claude Code, which is labelled distinctly so you can tell machine-written notes from human ones.
Ownership comes from your git user name, so activity attribution needs git configured — git config user.name — and works best when everyone on the team has done the same.
The section only appears once there is activity to show.
When two people edit the same note
A shared note is a text file, so git handles it like a text file: if two people change the same note and the changes cannot be merged automatically, you get a conflicted file with <<<<<<< markers in it.
DevNotes+ detects those markers and flags the note as conflicted rather than showing you a broken card. Opening it brings up a conflict panel that renders both versions side by side — yours and the incoming one, each labelled with the branch or commit it came from — with three ways out:
| Choice | Result |
|---|---|
| Keep mine | Your version wins; the incoming one is discarded. |
| Keep theirs | The incoming version wins; yours is discarded. |
| Merge versions | Opens an editor where you assemble one note from both, then saves that. |
Resolving through the panel rewrites the file cleanly, without conflict markers. You still need to stage and commit the result, the same as any other conflict resolution.
Pulling in a teammate's notes
Nothing special is required. Shared notes arrive with git pull like any other file, and DevNotes+ watches .devnotes/ for changes made outside the extension — so the sidebar updates on its own once the pull lands. If it looks stale, run DevNotes: Refresh.
Working without git
DevNotes+ does not require a git repository. Without one you lose sharing, note ownership, activity attribution, branch scoping and note_history. Everything else — notes, code links, tags, reminders, templates, export, the MCP integration — works exactly the same.