Warning: file_get_contents(/data/phpspider/zhask/data//catemap/9/git/24.json): failed to open stream: No such file or directory in /data/phpspider/zhask/libs/function.php on line 167

Warning: Invalid argument supplied for foreach() in /data/phpspider/zhask/libs/tag.function.php on line 1116

Notice: Undefined index: in /data/phpspider/zhask/libs/function.php on line 180

Warning: array_chunk() expects parameter 1 to be array, null given in /data/phpspider/zhask/libs/function.php on line 181
在拉取后本地标记为已删除的Git文件_Git_Azure Devops_Continuous Integration - Fatal编程技术网

在拉取后本地标记为已删除的Git文件

在拉取后本地标记为已删除的Git文件,git,azure-devops,continuous-integration,Git,Azure Devops,Continuous Integration,今天开始的一个问题是,我们的一个分支机构表现得非常怪异。 如果拉取分支,则会将文件标记为未老化更改,并将其删除。与分支的服务器版本相比,此文件确实存在 当然,如果我对文件执行git签出,则删除操作将撤消。 如果我进一步删除该分支的本地版本并进行另一次拉取,则不会将同一文件标记为删除 此文件的最新更改早在三个月前。最近一次提交是在几天前。夜间CI管道运行良好 我们正在使用Azure DevOps和所有包含的功能,例如使用多个代理构建管道等 有什么线索吗 我应该补充一点,这造成了巨大的问题,因为我们

今天开始的一个问题是,我们的一个分支机构表现得非常怪异。 如果拉取分支,则会将文件标记为未老化更改,并将其删除。与分支的服务器版本相比,此文件确实存在

当然,如果我对文件执行git签出,则删除操作将撤消。 如果我进一步删除该分支的本地版本并进行另一次拉取,则不会将同一文件标记为删除

此文件的最新更改早在三个月前。最近一次提交是在几天前。夜间CI管道运行良好

我们正在使用Azure DevOps和所有包含的功能,例如使用多个代理构建管道等

有什么线索吗

我应该补充一点,这造成了巨大的问题,因为我们的构建从今天起就无法运行。因为构建步骤拉分支->获得相同的标记以删除->构建解决方案失败

发生以下情况,从一个完全干净的、不相关的、没有变化的地方结账:

git checkout <corrupt branch>
git status
git签出
git状态

如果我们在签出之前或之后提取分支,则会得到相同的结果,因为损坏的分支尚未完全同步

编辑,我们注意到:

git checkout <corrupt branch>
git status
警告:以下路径发生冲突(例如区分大小写的路径 在不区分大小写的文件系统上),并且只有一个来自同一个文件系统 碰撞组位于工作树中:

未对文件夹路径或文件进行任何更改。数百个项目都使用此路径。他们中只有一个人认为这条路是重复的。
有什么想法吗?

问题确实在于案例不敏感。最大的问题是,没有任何历史表明这条道路一直在改变。很明显,有些事情已经改变了

事实证明,我们的一位开发人员将该文件移动到了一个小写路径。在与问题出现的位置无关的分支/构建中

它显示了在隔离的代理池中存在泄漏的构建和肮脏的工作区的一些问题,我们现在已经纠正了这些问题。我们还关闭了在路径中提交更改的功能,这些更改只在大小写上有所不同。幸运的是它相当孤立

找到解决办法后,我觉得很愚蠢。。
你活着,你学习。

你能在你的问题中添加一些命令-/git状态输出吗?这可能会有帮助。我想到的一件事,就是发生在我身上的
--autostash
,但我猜你已经尝试了足够多的方法来排除这种可能性<代码>--autostash可以隐藏和恢复您的隐藏或拖动(这是通过本地修改无法完成的)。这包括恢复删除。并且可以将autostash配置为总是在拉取期间发生。它发生在该分支被拉取到的每台机器上。多个工作站,更重要的是没有共享本地设置的新VM和容器。我们已经很长时间没有在构建中更改任何内容了。这是昨晚发生的。根据错误消息,您正在使用不区分大小写的文件系统。你用的是哪种操作系统?我们解决了。这是愚蠢的。我们正在使用windows。问题确实在于案件不敏感。最大的问题是,没有任何历史表明这条道路一直在改变。很明显,有些事情已经改变了。事实证明,我们的一位开发人员将该文件移动到了一个小写路径。在与问题出现的位置无关的分支/构建中。它显示了一些问题,有一个泄漏的建设和肮脏的工作区,我们现在已经纠正。我们还关闭了在路径中提交更改的功能,这些更改只在大小写上有所不同。幸运的是它相当孤立。