2

我们有一个由大约 10 名开发人员组成的团队，我们经常遇到有人的更改意外恢复的情况。我们的工作流程非常简单。开发人员进行本地提交，从上游拉取，然后推送到上游（简而言之，这是我们的工作流程，但它也可能包括从开发人员的个人上游分支在 Github 上发出拉取请求）。奇怪的行为是开发人员进行本地提交，从上游拉取，然后发现他的更改已恢复。就好像 git 正在解决与theirs策略的冲突，尽管我们都没有这个设置，也没有涉及实际的合并冲突。变化更像是这样的：

本地提交：

.some_style {
-  width: 150px;
+  width: 100px;
  color: black;
}

合并后：

.some_style {
  width: 150px;
  color: black;
}

没有其他提交涉及这部分代码，也没有人手动解决合并冲突（无论如何都不应该存在）。在开发人员完成合并并将其推送到上游后，我们有时会看到另一个开发人员提交的差异日志，该日志似乎反转了第一个开发人员所做的更改。通常，此还原提交以其他人的名义出现，尽管他们没有触及相关文件。

其他一些开发人员的提交：

.some_style {
+  width: 150px;
-  width: 100px;
  color: black;
}

我们不知道这是如何发生的或如何重新创建它。也许我们在某些方面缺乏 git 协作的知识，希望有人能指出我们正确的方向。

编辑 这个问题似乎只影响 css/scss 文件。我注意到差异标头显示了错误的信息：

@@ -359,10 +367,12 @@ img.badge-pic {

 #sampleProfileCover {
   float: left;
-  width: 200px;
+  width: 230px;
+  height: 150px;
   text-align: center;
   img {
     width: 200px;
+    height: 220px;
   }
 }

请注意，标题将此样式标识为img.badge-pic. 这种风格实际上在文件中出现得更早。git 可能无法解析 css/sass 吗？

4

3 回答 3

1

在git中，更改不会自动恢复；非常小心不要丢失任何东西。检查是否有人在做git rebase, git push -f（当他们的推动不起作用时，“让它起作用”，因为它不是快进），或git reset. 任何历史编辑都是危险的。让他们通读git-scm链接的一些教程。

回顾你的工作流程，与标准的 git 工作流程和建议进行比较（周围有几个）。Git 是一个工具，在最好的 Unix 传统中：适用于知道自己在做什么的专家用户。所以它不会妨碍用户，并且不会试图对用户进行事后猜测。只要他们是新手，这偶尔会适得其反，但他们很快就会学会（或者沮丧地放弃;-)。

于 2013-03-16T18:57:26.277 回答
1

我怀疑这可能是编辑器问题；也许名称在恢复提交上的开发人员的文本编辑器没有加载从上游提取的更改，因此当他保存、提交和推送他的更改时，文本编辑器最终会覆盖从 Git 引入的内容。由于它只是一种正在恢复的文件，因此这更加合理。

于 2013-03-18T05:04:53.207 回答
1

如果您git push --force向服务器发送有冲突的提交，就会发生这种情况。如果另一个冲突提交的作者立即拉取强制提交并将其合并，则这可以工作——他仍然附加了自己的提交，并且拉取将显示他身边的冲突（除了执行 fsck 时没有其他人会注意到 - - 有人必须进行合并。只是将其推到遗忘状态并不是解决方案，而且显然 git 的默认设置不适合普通开发人员！然后，冲突的提交将被推到一边并悬空而不是附加到提示或您的调用方式你可以通过运行 git fsck 来检查：

$ git fsck
Checking object directories: 100% (256/256), done.
dangling commit 4f851a97274917a1486f81833c6e96c4b1efeabc

您还可以阻止您的开发人员使用force. 解决方案：将以下内容添加到您的存储库配置文件中：

[receive]
    denyNonFastForwards = true

另请参阅http://randyfay.com/content/avoiding-git-disasters-gory-story

于 2013-03-20T06:34:04.290 回答