教程文档【免费下载链接】30-seconds-of-codeCoding articles to level up your development skills项目地址https://gitcode.com/gh_mirrors/30/30-seconds-of-code点击查看免费下载导读在跨平台协作或长期维护的 Git 仓库中CRLF与LF行尾混用常导致脚本报错、diff 刷屏等诡异问题。本文基于 30 Seconds of Code 仓库中 fix-incorrect-line-endings 这一实战经验系统讲解如何通过core.autocrlf与git add --renormalize两条命令在不重写提交历史的前提下一次性修正全仓库的行尾并补充core.eol、.gitattributes、core.safecrlf等配置的深度原理与验证方法。读完本文你将能独立排查并根治 Git 仓库中的行尾问题。一、问题现场一行诡异的报错在 30 Seconds of Code 的这篇 Git 实战记录中作者同事在运行一个 Ruby 脚本时遇到了如下报错env: ruby\r: No such file or directory乍看像是找不到 Ruby 解释器但真正的原因是行尾line endings。该脚本文件使用了CRLF行尾而系统期望的是LF行尾。在 Unix 系 Shell 解析 shebang#!/usr/bin/env ruby时行尾的\r被当作解释器路径的一部分于是变成了ruby\r自然无法执行。这类问题在不同操作系统间编辑文件时极易出现操作系统行尾符号说明WindowsCRLF\r\n回车 换行Unix / Linux / macOSLF\n仅换行该文档还特别指出一个容易被忽略的事实即使整个团队都使用 Unix 系系统文件也可能被某个工具或历史提交带入CRLF行尾——案例中正是通过 VS Code 的状态栏确认了文件实际是CRLF编码。因此行尾问题并不只发生在跨平台团队中排查时不要先入为主地排除同系统协作的场景。二、第一步设置全局行尾策略找到原因后第一步是让 Git 接管行尾处理并统一成LF# 为仓库中的所有文件设置 LF 行尾 git config --global core.autocrlf inputcore.autocrlf的取值语义core.autocrlf控制 Git 在**检出checkout与提交commit**时的行尾转换行为共有三个取值取值行为适用场景true提交时CRLF→LF检出时LF→CRLFWindows 用户input提交时CRLF→LF检出时不做任何转换Unix/Linux/macOS 用户false完全不转换仓库已用.gitattributes精确管理行尾在 Unix 系环境执行git config --global core.autocrlf input意味着工作区里的文件保持原始状态但一旦进入暂存区/提交Git 会统一将其转为LF入库。这正是全局修复行尾的第一步。[!TIP]需要特别说明的是该命令只影响之后的写入行为并不会修改已经存在于工作区或历史中的文件。这也是原文档明确指出doesnt fix existing files的原因——要修正存量文件还需要第二步。配套配置core.eol与git config -e与本仓库中另一篇 line-endings 记录的知识相呼应core.eol是更细粒度的行尾配置直接指定仓库内文件应使用哪种行尾# Usage: git config core.eol [lf | crlf] git config core.eol lf # 使用 UNIX 行尾 git config core.eol crlf # 使用 DOS 行尾两者协作关系可概括为core.autocrlf决定何时转换core.eol决定转换到什么目标。若你的团队同时涉及 Windows 与 Unix 成员推荐配合 配置 Git 的默认文本编辑器 后直接使用 git config -e 编辑配置文件 手工核对这些键值git config --global -e # 打开全局配置文件 git config -e # 打开当前仓库的配置文件三、第二步不重写历史修正存量文件直接对所有存量文件重新提交会污染提交历史代价过高。正确的做法是使用git add --renormalize# 重新检查仓库中所有文件并应用新的行尾设置 git add --renormalize .原理为什么它不重写历史git add --renormalize会忽略工作区文件是否看起来没变强制对所有已跟踪文件重新执行clean 过滤器 行尾规范化流程并把规范化后的内容重新写入索引staging area。关键在于它只改变索引中记录的 blob 内容不触碰任何历史提交对象你随后的提交是一个普通的新提交历史记录依然完整保留与git filter-branch或git rebase等重写历史的操作有本质区别——这也是原文档强调without messing up the repositorys history的原因。从执行细节看该命令内部等价于git add --renormalize对所有匹配的文件执行 core.autocrlf/core.eol规则下的重新规范化。Git 会比对规范化前后内容只有行尾真正变化的文件才会进入待提交状态git status会显示这些文件为 modified。[!WARNING]运行前请确保当前工作区是干净的或至少已暂存/提交你的改动避免把未完成的编辑一并卷入这次批量规范化。完整修复流程将两步串起来就是原文档给出的完整解决方案# 1. 设置全局行尾策略为 LF git config --global core.autocrlf input # 2. 重新规范化所有存量文件不改写历史 git add --renormalize . # 3. 查看将被修正的文件列表确认无误 git status # 4. 提交本次行尾修复 git commit -m Normalize line endings to LF四、进阶用.gitattributes做团队级行尾治理core.autocrlf是本机级配置依赖每个成员的本地设置在多平台团队中并不足够可靠。更规范的团队级做法是提交一个.gitattributes文件把行尾规则固化进仓库本身# 所有文本文件统一使用 LF 入库 * textauto # 指定文件类型强制 LF / CRLF *.sh text eollf *.bat text eolcrlf # 二进制文件禁止行尾转换 *.png binary *.jpg binary配合.gitattributes后git add --renormalize .会按属性文件中的规则重新规范化全部文件效果与core.autocrlf一致但对所有克隆该仓库的人生效规则随仓库分发。五、验证与防范避免问题复发修复完成后可用以下手段验证行尾是否已统一# 查看某文件的实际行尾$ 表示行尾CRLF 会显示 ^M git diff --cached # 用 cat 检查是否还有 CRLF 残留 cat -v script.rb | grep \^M # 用 file 命令确认 file script.rb预防复发方面可以开启core.safecrlf在提交时拦截可能出错的行尾转换git config --global core.safecrlf warn # 只警告 git config --global core.safecrlf true # 禁止提交严格模式另外仓库中同主题的 JavaScript 片段 normalizeLineEndings 提供了一个有趣的非 Git视角在程序处理字符串层面用一条正则即可完成行尾归一化const normalizeLineEndings (str, normalized \n) str.replace(/\r?\n/g, normalized);这提醒我们行尾问题是横跨操作系统 → 版本控制 → 字符串处理三个层面的系统性问题本文的 Git 方案负责仓库层面而上面的 JS 工具函数负责运行时数据处理层面。六、总结回顾整个修复过程核心方法论可以浓缩为三点症状识别形如env: ruby\r: No such file or directory的报错、或 diff 中整文件变红的怪象优先怀疑行尾问题规则先行git config --global core.autocrlf input确立全局行尾策略Unix 系团队统一LF存量修复git add --renormalize .在不重写历史的前提下重新规范化所有已跟踪文件随后正常提交。这两条命令的组合正是 fix-incorrect-line-endings 这篇文档给出的标准解法。配合.gitattributes、core.safecrlf等治理手段你可以彻底告别跨平台行尾噩梦。赞分享教程文档【免费下载链接】30-seconds-of-codeCoding articles to level up your development skills项目地址https://gitcode.com/gh_mirrors/30/30-seconds-of-code点击查看免费下载相关推荐CANN pyasc 算子编程asc.language.basic.exp 自然指数计算的三种调用范式与实现解析CANN pyasc 算子编程asc.language.basic.exp 自然指数计算的三种调用范式与实现解析 asc.language.basic.exp教程文档30-seconds-of-code 项目使用说明30 seconds of code 项目使用说明 1. 项目目录结构及介绍 项目 30 seconds of code 的目录结构如下 .github/ 教程文档30-seconds-of-php-code 项目教程30 seconds of php code 项目教程 1. 项目的目录结构及介绍 30 seconds of php code/ ├── src/ │ ├──上一篇React Native Navigation动态配置终极指南如何实时修改导航栏和页面属性 下一篇终极数据科学资源宝库gh_mirrors/da/datascience一站式Python工具集合创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考