冲突解决后如何忽略Git中的文件模式更改?

时间:2011-12-08 12:15:49

标签: windows macos git file-permissions

我正在认真地停止编码并成为一名木匠。这个问题已经让我压了很长一段时间了,似乎没有任何明确的解决方案,除了强迫非Windows机器使用文件权限窗口似乎造成。

让我们从场景开始。我有2台开发机器,一台运行Windows7,另一台运行Mac OSX。他们都使用Eclipse和EGit,两者都从远程仓库克隆了同一个项目。这就是相似之处的结束,因为我的Windows机器有一个讨厌的习惯,即在其本地存储器上保留 644 (r-xr - r--)的文件模式,而Mac上的模式默认为冷静 775 (rwxrwxr - x)。

所以问题显然是文件权限 - GIT报告由于文件模式的差异而不是实际内容,有些文件已经改变。解决方案似乎很明显,运行以下命令:

 git config core.filemode false
 git config --global core.filemode false

...在提交和合并已解决的冲突时,它就像魅力一样,除了

例如,说Windows和Mac repos上都存在文件A,B和C.接下来,让我们在Mac机器上更改这3个文件的文件模式,以便开发人员可以编辑它们。现在更改文件A中的一些内容。因为我们忽略了文件模式(感谢上面的命令),只有文件A将被提交并推送,准备好让Windows机器获取,合并和享受...

现在,让我们在Windows机器上的Mac 上再次编辑文件A,有效地造成潜在的冲突,并让Windows机器首先提交并推送文件A.然后,当Mac用户将更改提交到文件A并从远程仓库获取最新更改时,显然会产生冲突。

解决Mac机器上的冲突并将文件A添加回本地仓库后,提交该合并包括先前忽略的文件B和C,从而突出显示我的问题!为什么先前忽略的文件包含在此合并提交中?这似乎不是专门的Mac / Windows问题,因为这个问题可以双向重现......

如果只有3个文件,这可能无关紧要,但我所指的这个项目包括数千个,所有这些上下推拉都是疯狂的。我错过了一些非常明显的东西吗任何帮助将不胜感激!

2 个答案:

答案 0 :(得分:1)

因此,经过漫长且经常令人沮丧的尝试,在比较笔记和Git上的变化时,试图让Windows和Mac OS机器彼此喜欢,似乎只是Git本身的功能让我发疯,而且更好了解如何更好地使用Git似乎是最终的答案。

最初,我想知道如何继续忽略文件模式更改(Windows似乎喜欢用自己的权限和模式应该更新的更新),同时我解决了从其他人更新文件所产生的冲突。简短的回答:你不能。这就是Git的工作方式。

那么当它出现时你会怎么处理这种情况?简短回答:使用分支

在我使用Git的原始方式中,我一直在我的本地仓库上工作我的主分支 - 已经是坏主意 - 所以我的所有工作都将在那里进行,所有冲突解决方案也需要在那里处理,迫使所有要再次进行比较的文件以及所有权限和文件模式都会受到质疑。

使用分支,您可以在另一个分支上工作,提交到该分支,将更新提取到主分支,然后在之后将其他分支与主分支合并。突然间,远程回购中的主人不再发生冲突了,你就赢了!

执行此操作的命令(从当前选定的分支创建分支):

git branch newbranch

结帐新分行:

git checkout newbranch

要将新分支与主分支合并(在您提交newbranch之后,请先切换到主分支):

git checkout master
git merge newbranch

希望这有助于某人! - :)

答案 1 :(得分:1)

好吧,我不确定你是如何得出结论的,因为明显的问题是git并没有忽略文件模式的改变。这也发生在我们这里。

如果设置该标志,在某些情况下似乎没有区别,仍然使用文件模式来确定更改的文件。

那必须是git中的一个bug,还有什么呢?

可能你的答案没有解释理由,因此我不认为这是正确的答案,这是一种解决方法。

正确的答案是git在没有被告知的情况下不使用文件模式,它显然忽略了它并且无论如何都要这样做。

你可以解释一下。