适用于单用户应用程序的多开发人员Git的最佳实践 [英] Best pracitces for multi-developer Git for single user application

问题描述

我对一个非常老的应用程序负责，我们正在尝试包装现代工具.

该应用程序是基于Linux的数据处理应用程序.它吸收了一些数据，进行了一些复杂的分析/模拟，并具有一个简单的Web/CSV界面.

我们运行了多个实例，每个实例针对我们的每个客户端，它们的核心相同，并且编写了一些存储在Git中的帮助程序/包装脚本.在Git中也可以添加尽可能多的配置文件.

该核心应用程序必须以服务Linux用户身份运行，并且很难为每个开发人员创建一个实例，因此我们每个客户端有一个测试实例，每个客户端有一个生产实例.

我们所有的代码都存储在GitLab中，因此我们将其全部推送到远程存储库中.我们将配置从远程拉到生产机器.

一般架构是:

  GitLab/\/\开发箱产品箱〜app1/〜app1/〜app2/〜app2/〜app3/〜app3/ 

我们的团队由5人组成.每个人通常都在〜appN环境之一中工作，但是人们四处走动.我们希望开发人员和GitLab中的提交历史都能够反映进行更改的实际人员.

我正在为此寻求最佳实践.目前，我们正在做的事情并不理想.这是我们的工作:

每个开发人员(以我们的示例开发人员Bob为例)在开发"框中以Linux用户〜appN的身份进行开发和测试更改.一旦更改看起来很不错，他们便将更改的文件复制到自己主目录〜bob/中的存储库的克隆中.他们进行提交并从该位置推送，从而将其名称附加到提交.为了确认所有内容均已提交并正确推送，他们返回〜appN并执行以下操作:

  git隐藏git pullgit stash pop 

如果这很干净，则他们知道所有内容都已提交并推送到远程存储库.如果不是干净的东西，那就错过了.

很明显，我们正在做的事情很混乱，容易出错并且混乱.我对如何解决它有一些想法，但是我希望专家们可以对这种环境下的最佳开发方式提供一些见识.

谢谢.

解决方案

每个开发人员(以我们的示例开发人员Bob为例)在开发"框中以Linux用户〜appN 的身份进行开发和测试更改.

这就是为什么我开发了git包装器

请注意，使用git 2.19或更高版本，您还可以使用 x509格式，而不仅仅是opengpg.

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.

解决方案

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 that article (from Alpha Olomi), 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.

这篇关于适用于单用户应用程序的多开发人员Git的最佳实践的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！