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--