与Git的行结尾

Question

我已经设置了一个Jenkins作业,它将build.sh从我的存储库中执行一个.作业开始和退出时出现以下错误:

d:\ jenkins\workspace\test-win7> c:\ cygwin64\bin\bash.exe -xe build.sh + $'\ r'build.sh:第2行:$'\ r':找不到命令

我发现这是因为行结尾的问题.我build.sh在Notepad ++中编写了我的CRLF结尾.我使用了一个带有以下选项的.gitattributes文件,但它们都不起作用.我还用LF结尾保存了我的文件并提交了它们但是这个错误仍然不会消失.有谁可以善意向我解释这条线结束系统是如何工作的？我应该在我的.gitattributes文件中保留什么设置,以便我的构建在Jenkins上运行,而从我的Repo中提取的朋友不会受到影响.

• *.sh text eol=crlf
• * text=auto
• *.sh text eol=lf

我的jenkins构建节点是一个Windows节点.我在Windows本地机器上进行Eclipse开发.

Answer 1

只需直接将eol.sh 文件放入 unix 样式即可。

即使您的构建环境是在 Windows 上，您也使用的是 cygwin 环境，对吗？无论如何，windows命令解释器cmd.exe首先无法理解shell脚本，所以你不必担心windows回车。

或者，您可以通过配置特殊文件来配置 Git 在每个存储库的基础上管理行结尾的方式.gitattributes。该文件被提交到存储库中并覆盖个人的core.autocrlf设置，确保所有用户的行为一致，无论其 Git 设置如何。文件的优点 .gitattributes是您的线路配置与您的存储库相关联。您无需担心协作者是否具有与您相同的行结束设置。

该.gitattributes文件必须在存储库的根目录中创建并像任何其他文件一样提交。

文件.gitattributes看起来像一个包含两列的表格：

左边是Git要匹配的文件名。右侧是 Git 应对这些文件使用的行结束配置。

这是一个示例.gitattributes文件。您可以将其用作存储库的模板：

# Set the default behavior, in case people don't have core.autocrlf set.
* text=auto

# Explicitly declare text files you want to always be normalized and converted
# to native line endings on checkout.
*.c text
*.h text

# Declare files that will always have CRLF line endings on checkout.
*.sln text eol=crlf

# Denote all files that are truly binary and should not be modified.
*.png binary
*.jpg binary

您会注意到文件是匹配的--*.c, *.sln, *.png--，用空格分隔，然后给出设置--text, text eol=crlf, binary。我们将在下面讨论一些可能的设置。

text=autoGit 将以它认为最好的方式处理文件。这是一个很好的默认选项。text eol=crlfGit 总是会在结帐时将行结尾转换为CRLF。您应该将其用于必须保留CRLF结尾的文件，即使在 OSX 或 Linux 上也是如此。text eol=lfGit 总是会在结帐时将行结尾转换为 LF。您应该将其用于必须保留 LF 结尾的文件，即使在 Windows 上也是如此。二进制 Git 会理解指定的文件不是文本，并且不应该尝试更改它们。二进制设置也是 的别名-text -diff。

来源： https://help.github.com/articles/dealing-with-line-endings/ 其他阅读材料： 如何更改行结束设置