2

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

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

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

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

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

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

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

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

4

3 回答 3

5

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

好吧，为此有一个称为git hooks的功能，它允许您在每次提交之前或之后（以及在其他时间）启动脚本。

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

于 2013-10-07T12:04:42.810 回答
4

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

您只需推动，如果其他人在您之前推动，则默认情况下您的操作将被拒绝（因为不是“快进”）。

然后你拉：

  • 理想情况下，您git pull --rebase是为了在该分支的最新提交之上重做您的工作）。
  • 你检查一切是否仍然有效
  • 你推回去

至于修订图，一个简单git log --graph的可以帮助您了解发生了什么（我喜欢这个别名）。

于 2013-10-07T12:11:54.317 回答
3

通常的情况（非常简化）如下：

  1. 开发人员将 master 分支签出到他的机器（在 SVN 中也称为“主干”，即最近提交的地方）。
  2. 他从中分出并创建了一个本地分支。
  3. 在这个本地分支中，他创建了必要的提交。
  4. 他从这个分支创建了一个“拉取请求”（换句话说，要求将它合并回主控）。
  5. 负责主分支的人会审查更改并将它们合并到主分支中。

主分支可能会在开发人员分支时发生变化，但如果新的更改不与对主分支所做的更改相交，则合并会自动完成。所以主分支在git执行合并时只被阻塞了可以忽略不计的时间。

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

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

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

于 2013-10-07T12:12:44.403 回答