如何在并发环境中实际使用 Git答案

【问题标题】：How to actually work with Git in a concurrent enviornment如何在并发环境中实际使用 Git
【发布时间】：2013-10-07 11:52:40
【问题描述】：

所以，我们正在从 CVSNT 迁移到 Perforce 或 Git，过去几周我一直在研究它们的功能，我很清楚 Perforce 实际上有点相似，因为它是中心化的。

Git 看起来很快，但我们是一家所有开发人员都待在同一个房间里的公司，即使有超过 100 名开发人员，仍然所有计算机都连接到 CVSNT 服务器...

出于这个原因，我不知道如何让 Git 像 Perforce 那样工作。

由于处于离线状态，当一个人克隆 Git 存储库时，他将复制历史记录以及该存储库的所有相关信息以使其离线工作，但是，以并发方式工作，例如，您拥有本地文件的历史记录似乎很奇怪...

所以如果开发者 B 提交并推送到服务器，开发者 A 不会知道它，它不会出现在他的文件历史中……除非他真的从服务器拉取，对吧？！（只要它们在同一个分支中..）

但是如果它以这种方式工作，那么我实际上会以集中方式与分布式 SCM 一起工作......并且必须“猜测”一个人何时推送到服务器......即使有一个命令要知道如果文件有新版本，手动检查是不好的。

有人可以更好地解释一下 Git 是如何以并发方式工作的，而无需知道另一个人何时实际推送到服务器等。

另一件事，我在 Git 上找不到任何好的修订图，我在 Tortoise Git 中找到了，但它更像是一个分支图而不是修订图..

【问题讨论】：

【解决方案1】：

...并且必须“猜测”何时推送到服务器..即使有一个命令可以知道文件是否有新版本，这很糟糕必须手动检查..

为此，有一个名为 git hooks 的功能可以让您在每次提交之前或之后（以及在其他时间）启动脚本。

因此，您可以使用它来通知（电子邮件、短信、鸽子）在特定分支上工作的其他人有人推送到它，因此他们应该进行提取。

【讨论】：

【解决方案2】：

像 git 这样的 DVCS 的通常工作流程并不依赖于您猜测是否有人推送。

您只需推动，如果其他人在您之前推动，your action will be, by default, denied（因为不是“快进”）。

然后你拉：

至于修订图，simple git log --graph 可以帮助您了解发生了什么（我like this alias）。

【讨论】：

【解决方案3】：

通常的场景（非常简化）如下：

主分支可能会在开发人员分支后发生变化，但如果新的更改不与对主分支所做的更改相交，则合并会自动完成。因此，当git 执行合并时，master 分支只会被阻塞一小段时间。

如果它们确实相交（这种情况并不常见），有两种方法可以解决它。首先，负责处理拉取请求的人可以手动解决冲突。第二，他可以打电话给开发商，让他去做。然后，开发人员检查更新后的 master 分支，将其合并到其本地分支（解决冲突）并创建一个新的 pull request，现在几乎可以保证成功。

实际上，当然，可能有多个并发分支（例如，master，一些主要功能的分支，一个发布分支等），以及几个管理人员。但无论如何，没有全局锁，也不需要维护与主存储库的连接。

Git Flow 中描述了一个非常好的 Git 开发过程。

【讨论】：