Git is a version control system for tracking changes in computer files and coordinating work on those files among multiple people.
I know the next ones:
1. Place all different settings in environment variables. You have a different .env file for each environment, and you must add some code to Production for reading and setting these values. It's good for deploying into containers, but challenging for management when we have a large production. I mean, we have many settings that can vary depending on the environment: active flag, pool size, timeouts, and so on. Not only endpoints.
2. My own case.
In a healthcare setting we've an Ensemble namespace through which passes a key HL7 feed (the ADT feed from our PAS). It is split up, transformed and passed on to multiple downstream systems. We consider the feed going to each downstream system an interface. Each interface is developed as separately as possible - typically as a separate branch of our git repo (which we access via VS Code).
All this is fine till we try and name the version(s). We both want to know what is currently in live (the sum of all the interfaces in the namespace) and know what version each specific interface is at.
What does everyone think about submitting an issue in a repository and then submitting a pull request to fix that issue. Is it an unnecessary step or does it give extra context and logging for the issue? I ask this because when I find a bug in an Open Exchange app, I always submit the Issue and then often submit a Pull Request to fix the issue.
I think that if the repository owner doesn't like your suggested fix, it is helpful to have the issue around so that they can deny the pull request and potentially implement their own change for the issue.