Question

我们拥有一支由大约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文件。我注意到diff标头显示错误的信息：

@@ -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时遇到问题吗？

Answer 1

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

浏览您的工作流程，与标准的git工作流程和建议（周围有几个）进行比较。 Git是一个工具，具有最好的Unix传统：适用于知道自己在做什么的专家用户。所以它不会挡路，也不会试图猜测用户。只要他们是排名新手，偶尔会发生逆火，但他们很快就会学到（或者在挫折中放弃; - ）。

Answer 2

我怀疑这可能是编辑问题;也许开发人员的文本编辑器，其名称在还原提交上，不会加载从上游提取的更改，因此当他保存，提交并推送他的更改时，文本编辑器最终会覆盖从Git中引入的内容。事实上它只是一种被归还的文件，因此更加合理。

Answer 3

如果您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

在拉动上游合并之后，奇怪的git行为恢复了在本地分支中所做的更改

3 个答案: