Approaches
To better isolate my various activities, I use one account per “theme”: one account for my common “affairs” (e-mail, accounting, web browsing, photos, …), one account for Gramps research (it originated from my choice of KDE Plasma environment and I opened specifically an account for GNOME desktop, but a few upgrades back I dropped Gnome completely as having the libraries installed is enough; so now, even this account is under KDE Plasma), one account for “general” development (Gramps is only the latest one), one account for LXR maintenance (as I am the lead developer), …
Isolation
This is combined with an ad-hoc group policy: the accounts are attached to various groups to allow “easy” file transfers between user home directories. Not all accounts have the same privileges. In particular the “development” accounts are the most limited ones as things may easily go awry.
For backup and exchange purposes I also created a /home/groups/ directory with subdirectories with the same names as the groups. Only the groups have write-access. There is also a /home/groups/projects/ directory where I store “remote” git repos as sync’ed backups for my .git active trees. And a friend of mine offered hosting on his NAS as second-level backup.
Workflow
First I never work on two projects simultaneously. If I must switch to another one under my development account, I close everything, making sure that the state is well defined. I should probably also do a checkpoint with Git but I don’t like to have “pending” commits (meaning the patch sets are not guaranteed to be complete so that applying them will result in a functional app). Perhaps with an adequate commit message telling this is only a temporary backup … Only then I switch to the other project (very easy with KDevelop as it guarantees a clean environment by switching the working directories, setting the correct shell environment, …
My desktop computer is rather well “furbished”. I have 2 wide screens (there are 3 connectors on the GPU card but two out of them are exclusive from each other, so my 3rd monitor was useless). Consequently I can have the KDevelop + Konsole (terminal) windows on one screen, Firefox (code cross-references through LXR), Sqliteman (DB monitoring) and Gramps windows on the other screen.
I mention Konsole because I launch Gramps with a command line. All debugging output (which is normally discarded in GUI mode) is displayed in the Konsole window and I can trace what’s is happening as the Gramps window open and change.
I remember having tried Python venv once on some Django project but I don’t feel at ease with it because I’m discovering Python while modifying Gramps. In addition what you change in venv is not forwarding to your code files. I find it as quick to leave Gramps and to patch the source file then relaunch Gramps as playing in venv.
Git
Git is your friend. I cloned the official Gramps repo (not the one where PR are pushed because I don’t want to subscribe to one more site, be it GitHub).
The first thing to do is to create your own branch. This isolates you from the development on the master branch. You then control when you want to rebase to see if your changes are compatible with mainstream.
I use Git frequently to compare my state with master (or any other branch) to see if I am relatively close to official releases. My goal is to avoid to diverge too much so that I can still benefit from progress on the main branch.
Git also allows me to eventually revert a dead end or cancel the effects of a badly designed patch.
Other tools
Kompare: KDE Plasma GUI front-end to diff.
LXR: interactive browsing on source code; you can have several tabs in Firefox to show you several files; identifiers are clickable to display the list of definitions and uses; you can click on these to jump to the line in the file (comes in complement to what KDevelop offers).
LibreOffice Draw & Writer: to make diagrams on Gramps internals and take structured notes on my discoveries in the source code as well as my introspection on what I’d like