Best pracitces for multi-developer Git for single user application

Question

I am responsible for a quite old application that we are trying to wrap modern tools around.

The application is a Linux based data processing application. It takes some data in, does some complex analysis/simulation, and has a simple web/CSV interface.

We run multiple instances of this, one for each client of ours, where the core the same, and we write some helper/wrapper scripts that we store in Git. Also as many config files as we could add are in Git.

The core application is required to be run as a service Linux user, and it's difficult to create an instance for each developer, so we have one test instance per client, and one production instance per client.

All of our code is stored in GitLab, so we push it all to a remote repository. We pull the config from the remote to the production machine.

The general architecture is:

              GitLab
             /      \
            /        \
       Dev box      Prod box
       ~app1/       ~app1/ 
       ~app2/       ~app2/ 
       ~app3/       ~app3/

Our team is made of 5 people. Each person typically works on one of the ~appN environments, but people move around. We want the commit history both locally in Dev and in GitLab to reflect the actual human that made the change.

I'm searching for best practices for this. Right now what we are doing feels suboptimal. Here's what we do:

Each developer (let's call our example developer Bob) works as the Linux user ~appN on the Dev box to develop and test changes. Once they a change looks good they copy the changed files to a clone of the repo in their own home directory ~bob/. They do a commit and push from this location, which attaches their name to the commit. To confirm that everything was committed and pushed correctly they go back to the ~appN and do:

git stash
git pull
git stash pop

If this is clean then they know that everything is committed and pushed to the remote repo. If it's not clean something was missed.

Clearly what we are doing is convoluted, error prone, and messy. I have some ideas on how to fix it, but I'm hoping the experts can provide some insight into the best way to develop in this kind of environment.

Thanks in advance.

Answer 1

Each developer (let's call our example developer Bob) works as the Linux user ~appN on the Dev box to develop and test changes.

That is why I developed VonC/gitw, a git wrapper script which will force you to be correctly identified when you are doing git command.

That way, you don't have to copy back code done in the shared environment (Linux, with a generic service account) back to your PC, make commits and push.
You can directly do those changes, as you, in the shared environment, commit and push.

---

The OP 45th Percentile adds in the comments:

for compliance reasons we need to be able to tie back the commits to an authenticated user

That is an orthogonal issue, which involves autosigning commits with GPG keys.
In your case, you would complete the git wrapper in order, for a given user, to set the config user.signingkek, referencing the right key to use.

You can see the all process illustrated in the article "How To Sign Your Commits On GitHub With GPG." (from Mpho Mphego), but the idea remains: on the first commit, the user (correctly identified through gitw) will have to enter the passphrase associated with their key:

Note that with git 2.19 or more, you can also sign using x509 format, not just opengpg.