关于在多个用户之间共享一个 git clone 文件夹有很多问题，但一切似乎都是针对 Linux 的（下面有两个链接）。我有同样的问题，但对于 Windows 机器。我希望其他人已经做到了这一点，并有一个推荐的过程。
希望是由于每个用户都有自己的登录名，因此每个用户都将在 Windows 凭据管理器中拥有自己的凭据，并在自己的 .ssh 文件夹中存放密钥。如果每个用户都克隆了他们自己版本的存储库以进行工作，这就足够了。
但是，如果用户 A 克隆到目录并注销，然后用户 B 登录并尝试进行拉取（从远程获取/合并新提交），进行一些更改并将新更改推送到遥控器？我希望这能成功，每个用户都有单独的提交信息（作者信息）。
--shared在这种情况下有用吗？有没有办法让 git 的全局配置（名称/电子邮件，对于每个登录名都不同）与用户 A 的信息（来自初始 git 克隆，在 .git/config 中）？这甚至可能吗？
[编辑]
添加有关用例的详细信息。这是评论中要求的。
我有一个构建过程，我用脚本自动化了相当多的过程。它需要正确配置的机器（多个编译器、补丁等）和几个第 3 方组件。构建包括克隆约 50 个不同的存储库、生成 makefile、make、make install（按照 repos 上的特定顺序），然后运行其他打包/构建步骤。这需要几个小时，乘以几个构建配置以进行干净构建。为了加快进程，脚本将生成启发式方法来识别链中的步骤是否需要运行（即，make 可以判断是否需要重新运行，但这无助于make install或后续步骤）。最终结果是安装程序。我们对新版本进行了大约 6 个月的完全重建（我们可能会更新配置（编译器等）），并且有涉及更新和/或调整存储库子集（推送和拉取）的次要版本。脚本也可能需要修改，它们位于自己的 git 存储库中。
虽然脚本使我可以在不占用太多带宽的情况下完成任务，但我希望团队中的其他一些人能够运行这些步骤。困境就在这里。“简单”的解决方案是拥有一个共享帐户，但这实际上使 git 成为这个棘手的部分（ssh 密钥、github 令牌），并且还有许多其他缺点。保留此环境的多个实例，每个开发人员一个，将是“最好的”，但会产生同步机器环境的新问题。这也意味着一个开发人员不能通过为他们启动长时间运行的进程来“帮助”其他人（他们需要由每个不同的帐户/机器运行）。允许多个开发人员使用不同的帐户，但在同一台机器上和同一文件夹结构中工作似乎是最好的折衷方案。
实际上，真正的问题是构建环境。虽然有一些方法可以解决这个问题（厨师、工件存储库等），但在这种情况下，如果可能的话，手动设置构建环境和共享 git 存储库（git 的“特殊”使用）似乎是合理的。因此问题。
[/编辑]