Azure DevOps Server (TFS）中代码文件换行问题解决方案（Git)

之前写过一篇博客“探索TFS Git 库文件换行（CRLF）的处理方式”，主要是针对TFVC代码库的。

下面这篇文章说明如何在TFS的Git库中处理代码换行的问题。

概述

在Azure DevOps Server（之前叫TFS）中使用Git管理源代码，需要特别注意代码文件的换行处理。我们在许多团队碰到这样现象，开发人员在自己的Windows 中使用Eclipse 或者Visual Studio 编写和调试代码，功能都正常。但是，使用TFS 的自动生成和发布功能，将源代码下载到Linux 或 AIX等非Windows 的服务器上做编译和其他操作的时候，发现所有的功能都乱套的，甚至连基本的编译都无法成功。排查原因后发现，导致系统异常的原因是文件换行的格式。

我们在编写代码的时候，每次敲击一次回车键，代码会从下一行开始。实际上，我们在代码行的最后面插入了一个不可见的字符，这个字符叫做换行符（line ending）。在历史上，不同的操作系统处理换行符的方式不一样，例如Windows 使用crlf，Linux 使用lf，而早期的mac使用cr，后来有改为lf了。更加详细的内容，可以参考我上一篇博客“探索TFS Git 库文件换行（CRLF）的处理方式”。

在TFS 的Git库中，服务器和客户端对于文件换行符也有自己的处理方式。由于不同的开发人员使用不同的工具和操作系统，例如你使用Windows开发调试，而你的同事使用Mac编写代码，而TFS代理服务器则使用Linux 编译打包。如果不能统一处理换行标准，必然会导致许多未知的问题。例如我们在项目实施过程中，经常碰到这样的问题：“上一次的持续集成成功了，我们没有修改代码，怎么这次就出问题了，怎么这次就失败？”分析原因，TFS服务器在两次持续集成流程中使用了不同的代理服务器，而不同代理服务器上Git客户端处理换行的方式不一样。

解决不同开发人员、不同编译环境处理Git中的源代码换行的问题，我们可以使用下面两个统一的方案：统一开发环境中的Git配置，统一代码库的设置。

解决方案

1. 统一开发环境中的Git配置

在开发人员的计算机上配置Git客户端的全局变量（core.autocrlf），可以强制用户使用指定的方式处理行尾标识符，例如：

$ git config --global core.autocrlf true

# 按照Windows的方式处理换行符

$ git config --global core.autocrlf input

# 按照Linux的方式处理换行符

2. 统一代码库的设置

按照上面的方式处理文件，可以在一台开发计算机上使用统一的标准处理的源代码。但是，在实际开发过程中，需要按照不同的Git库做不同的处理。例如，对于存储.net程序的代码库，我们希望使用Windows的方式来处理换行符；对于java和shell脚本，我们希望使用Linux的方式处理换行符。

Git为我们提供了一种机制，可以针对每个库，设置不同的处理方式。在Git中，有一个特殊的文件.gitattributes。这个文件配置了Git客户端处理代码时候的各种设置（https://git-scm.com/docs/gitattributes) 。我们在每个git库中添加这个文件，再根据自己的需要，修改文件中的设置，就可以实现对不同库不同处理方式。.gitattributes中的设置会覆盖用户在上一章节中的配置。从此以后，无论你的开发人员工作在哪个平台上，只要他下载已经配置.gitattributes文件的代码库，就会按照我们指定的方式处理换行符。

.gitattributes必须放置在代码库的根目录下。保存的方式与我们提交、推送的方式完全一样。你可以把它视为一个普通的代码文件。

.gitattributes文件中的内容有点类型一个两行的表格：

左边的内容表示Git库中的文件名称或者文件路径
右边的内容表示对代码文件换行符的处理方式

下面是一个简单的示例：

# 使用默认的方式，开发人员客户端如何，git就如何处理换行符

* text=auto

# 明确指定使用原文件中的换行符

*.c text

*.h text

# 指定扩展名为sln的文件名称，使用Windows的换行符

*.sln text eol=crlf

# 指定扩展名为png或jpg的为二进制文件，不需要处理做任何修改

*.png binary

*.jpg binary

从上面的配置，你可以看到，在配置.gitattributes文件时，我们可以使用通配符，例如*.c, *.sln, *.png等。还可以使用空格，在一行中同时指定多种文件。下面，来看一下各种处理文件的配置方式：

text=auto: Git将按照自己的方式处理文件，一般是按照我们在上一节中配置的方式处理换行符。
text eol=crlf：在代码克隆、签出时，Git总是将换行符转换为crlf，就是我们Windows常用的格式。即使在Linux或者Mac操作系统中，Git也会按照这种方式处理。
text eol=lf：在代码克隆、签出时，Git总是将换行符转换为lf，就是我们Linux常用的格式。即使在Windows操作系统中，Git也会按照这种方式处理。
binary：Git会认为这种文件不是纯文本文件，它对这些文件不做任何处理。

3. 后续处理

按照上面的方式配置了你环境或者Git库后，你会发现实际上本地的文件没有任何变化。原来是Windows换行的，照样还是Windows。但是，实际上Git已经迫切希望按照你设定的方式来文件了。

可以参考下面的方式更新你的本地文件，同时还不会丢失目前的工作成果：

1）立即保存目前的所有文件

git add . –u

git commit –m “在刷新文件换行符之前，保存所有更改”

2）删除Git索引，并且强制Git从小扫描工作目录

rm .git/index

3）重写Git的索引文件，并应用最新的换行设置

git reset

4）查看Git状态

git status

5）将所有修改过的文件添加到提交清单中

git add -u

6）添加.gitattributes文件

git add .gitattributes

7）提交和推送文件

git commit –m “统一文件换行符”
git push

微软DevOps MVP 张洪君 http://www.cnblogs.com/danzhang

--End--