Question

我刚刚开始使用Github。

我们是一个由两人组成的团队，负责Github回购的两个项目。

问题：在同步一个项目时，git希望我在所有repo项目中提交更改，包括我在其中的项目没有工作也没有做任何改变。 git几乎显示了所有需要提交所有项目中的文件才能解决分支问题分歧的问题。

enter image description here

我如何解决此问题，因为我无法推送我的提交。

我们多次面对这个问题。

请帮助!!

编辑：我们/团队成员都在使用Windows和另一个在repo中使用其他项目的人使用mac os。

Answer 1

这称为行尾的问题。由于您使用的是Windows，而其他开发人员正在使用Linux / MacOS，

每次按键盘上的返回键都会实际插入一个叫做行结尾的不可见字符。历史上，不同操作系统以不同的方式处理行结尾。

解决方案：

    git config --global core.autocrlf input
    # Configure Git on OS X or Linux to properly handle line endings

    git config --global core.autocrlf true
    # Configure Git on Windows to properly handle line endings

参考 - help.github.com

Answer 2

在gitconfig文件中，（无论这些设置适用于您的系统，请参阅文档），您可以使用`safecrlf = true＆＃39;这应该避免这个问题。

然而，存在一些风险。

手册说明了这一点：

   core.safecrlf
       If true, makes Git check if converting CRLF is reversible when end-of-line conversion is
       active. Git will verify if a command modifies a file in the work tree either directly or
       indirectly. For example, committing a file followed by checking out the same file should
       yield the original file in the work tree. If this is not the case for the current setting
       of core.autocrlf, Git will reject the file. The variable can be set to "warn", in which
       case Git will only warn about an irreversible conversion but continue the operation.

       CRLF conversion bears a slight chance of corrupting data. When it is enabled, Git will
       convert CRLF to LF during commit and LF to CRLF during checkout. A file that contains a
       mixture of LF and CRLF before the commit cannot be recreated by Git. For text files this
       is the right thing to do: it corrects line endings such that we have only LF line endings
       in the repository. But for binary files that are accidentally classified as text the
       conversion can corrupt data.

       If you recognize such corruption early you can easily fix it by setting the conversion
       type explicitly in .gitattributes. Right after committing you still have the original
       file in your work tree and this file is not yet corrupted. You can explicitly tell Git
       that this file is binary and Git will handle the file appropriately.

       Unfortunately, the desired effect of cleaning up text files with mixed line endings and
       the undesired effect of corrupting binary files cannot be distinguished. In both cases
       CRLFs are removed in an irreversible way. For text files this is the right thing to do
       because CRLFs are line endings, while for binary files converting CRLFs corrupts data.

       Note, this safety check does not mean that a checkout will generate a file identical to
       the original file for a different setting of core.eol and core.autocrlf, but only for the
       current one. For example, a text file with LF would be accepted with core.eol=lf and
       could later be checked out with core.eol=crlf, in which case the resulting file would
       contain CRLF, although the original file contained LF. However, in both work trees the
       line endings would be consistent, that is either all LF or all CRLF, but never mixed. A
       file with mixed line endings would be reported by the core.safecrlf mechanism.

   core.autocrlf
       Setting this variable to "true" is almost the same as setting the text attribute to
       "auto" on all files except that text files are not guaranteed to be normalized: files
       that contain CRLF in the repository will not be touched. Use this setting if you want to
       have CRLF line endings in your working directory even though the repository does not have
       normalized line endings. This variable can be set to input, in which case no output
       conversion is performed.

Git - 避免提交所有项目以同步一个项目

2 个答案: