Gitignore settings don’t prevent checking in run configs if that’s what you want to do. Even if someone has the run configs pattern ignored, they’ll get those files with the repo clone. Gitignore only prevents adding files that aren’t already checked in - it’s a guard rail to prevent accidentally checking in so something you don’t want. You can override ignore settings to check in something new in with git add --force <filename>

Global gitignore is for idiosyncrasies of your computer, not for repo-specific stuff. For example if you use an editor that writes in-place backup or swap files (like .swp files with Vim’s default settings), or you’re on a Mac which writes .DS_Store files into every directory, you’re going to want those ignored for every repo. That way you can comfortably work with other people’s repos, even if they’re not configured for your particular setup.

The global ignore combines with gitignore files in each repo. So if it’s an ignore pattern that everyone working with that repo should have, put it in the repo.

Yes, I believe this was made for MacOS users. I don’t need to see your .DS_Store files!

That’s almost what I do with my work journal too. Daily logs with an index. A page for deferred tasks. A page here or there for tracking things that need to be done for a given project. I find the index helpful even if I only occasionally put an entry there.

For my personal journal daily logs are the core feature for sure. But I also get a lot of value from a future log, and a page for the current month with a list of events, and scheduled tasks.

I use bullet journals, and I have one for work. It’s not exactly the same - instead of my thought process it’s mostly what tasks I’m working on each day, and meeting notes. It helps me to organize what I what to get done so I don’t have to keep thinking about what I want to get done. It also helps me to get an idea of where my time went, and is a good place to write down anything I want to refer back to. Like when a coworker trained me on a deploy procedure I took notes, and added a line for that page number to my index.

That’s great! I finally cleaned up a lot of junk in the garage to make a usable work space. But it took me almost 3 years to get there!

The Linux kernel development workflow, the purpose for which git was invented, makes use of emailed patches https://docs.kernel.org/process/submitting-patches.html

When I’ve done this it’s generally done with JWTs where each micro service is configured with a trusted public key that is used to authenticate the JWT. The JWT can be sent to the client when they log in, and used to authenticate all API requests (forwarding the JWT as necessary for service-to-service requests). It’s also possible to have a gateway mint JWTs after using some other means to authenticate client requests.

Sometimes service-to-service requests don’t have a client request in context to pull a JWT from. In those cases you need another authentication mechanism, like a different signed token, or a shared secret.