- LF (Unix) i CRLF (Windows) són finals de línia diferents; homogeneïtza'ls per evitar diffs i errors.
- Git resol el problema amb core.autocrlf i .gitattributes; utilitza * text=auto i regles puntuals.
- Configura l'editor (VS Code/Visual Studio) i, si cal, renormalitza amb git add --renormalize .
- Mantingues LF al repositori i deixa a Windows utilitzar CRLF a la còpia de treball quan convingui.
Si treballes a Windows i alternes projectes amb gent de Linux o macOS, tard o d'hora et topes amb l'eterna batalla CRLF vs LF. De vegades sembla màgia negra: edites un arxiu, no canvies res “visible” i Git marca mig fitxer com a modificat. Tranquil, no és bruixeria; són els finals de línia jugant en contra teu.
Per estalviar-te mals de cap, convé entendre què hi ha a sota i com ajustar Git, els teus editors i les teves eines perquè cada fitxer arribi “net” al repositori, sense canvis fantasma ni errors rars en CI/CD o scripts. En aquesta guia t'explico, amb detall i al gra, com convertir, configurar i normalitzar CRLF i LF a Windows sense perdre el temps.
Què són LF i CRLF i per què importen
Els finals de línia són caràcters de control que delimiten cada línia en un fitxer de text: LF (\n, ASCII 10) y CRLF (\r\n, ASCII 13+10). En sistemes tipus Unix (Linux, macOS) s'usa LF, mentre que Windows utilitza CRLF per herència de les impressores i màquines d'escriure: primer retorn de carro (CR), després avanç de línia (LF).
L'elecció no és estètica: canviar d'un format a un altre pot provocar diffs artificials, scripts que fallen amb “command not found”, pipelines que rebenten en executar en Linux arxius guardats amb CRLF, o editors que mostren tot en una sola línia. Sí, obris un .sh amb CRLF a Bash i et pots menjar un bon ensurt.
Per arrodonir, Unicode reconeix més separadors (NEL U+0085, LS U+2028, PS U+2029, VT U+000B, FF U+000C), però en el desenvolupament quotidià el duel real és CRLF vs LF. Tot i així, saber que hi ha ajuda quan et topes amb textos de mainframes o fitxers rars que un editor antic no interpreta bé.
Una altra curiositat tècnica útil: un salt es pot tractar com separador (entre línies) o com terminador (marca la fi). Aquesta subtilesa explica per què de vegades veus una darrera línia “sense salt final” o línies buides de més quan barreges eines. Si necessites aprendre a trobar i reemplaçar salts de paràgraf, compte, perquè alguns analitzadors esperen una cosa o una altra.
Diferències per sistema i problemes típics
A Windows, el normal és CRLF; a Linux i macOS, LF. Aquest xoc es nota de seguida en equip mixt: algú edita un arxiu amb el sistema, el guarda, i el diff s'omple de canvis que en realitat són només finals de línia. A nivell pràctic et complica les revisions i contamina l'historial.
També hi ha efectes col·laterals: un script amb CRLF executat en un entorn Unix pot fallar amb errors críptics, o en CI una tasca es trenca perquè un shell interpreta malament els retorns. En l'altre sentit, obrir a Windows un fitxer amb només LF a editors antics pot aplanar-lo en una línia.
Compte amb eines d'integració contínua com Jenkins o GitHub Actions: si la build corre a Linux però tu puges fitxers amb finals de línia inconsistents, pots trencar el pipeline encara que “tot funcioni a la meva màquina”. Més d'un ha perdut hores per això.
La bona notícia és que hi ha una recepta clara: fixar una convenció i fer que les eines l'apliquin soles. Això passa pel Git i pel teu editor. I si el mal ja està fet, per renormalitzar el repo.
Per cert, editors moderns com VS Code mostren el tipus de salt a la barra d'estat i permeten canviar-lo al vol; és un salvavides quan detectes arxius “creuats” i vols posar ordre ràpid, o quan necessites evitar salts de pàgina i formats inesperats en enganxar text en documents.
Git i els finals de línia: core.autocrlf i .gitattributes
Git pot convertir finals de línia automàticament per mantenir l'historial net i evitar ensurts. La clau és l'opció core.autocrlf, que has d'entendre bé abans de tocar-la, i saber que la configuració pot estar a nivell global o local de repositori (la local mana).
Revisa la teva configuració global amb –global i recorda que en el repo hi pot haver un altre valor diferent que és el que preval. Per consultar-ho tot a nivell global, utilitza git config –list –global. Si al repo veus comportaments rars, comprova el valor local i prioritza'l segons allò que necessitis.
Maneres de core.autocrlf en termes pràctics (Windows vs Unix): veritable converteix CRLF en fer checkout i torna a LF al commit; entrada només converteix LF en fer commit (ideal a Linux/macOS); false no toca res (i sol ser pa per avui i gana per demà si hi ha equip mixt). A Windows, el més assenyat és veritable si no vols sorpreses.
ordres útils per ajustar i netejar la situació del teu repo sense embolicar-la massa: si vols que el repositori faci servir el valor global, eliminar la clau local; si prefereixes forçar un valor en aquest repo, configura'l sense –global. Per arreglar fitxers ja barrejats, renormalitza i fes un commit agrupant els canvis de finals de línia.
git config --list --global
# Ver el valor global efectivo
git config --unset core.autocrlf
# Quitar el valor local y heredar el global
git config core.autocrlf true
# Fijar el valor solo en el repo actual (Windows)
git add --renormalize .
# Recorrerá el repo y homogeneizará line endings según la config
git commit -m 'Homogeneizados los cambios de línea'
# Sube un solo commit de normalización
Però encara hi ha alguna cosa millor: un .gitattributes a l'arrel que viatge amb el codi. Amb la regla * text=auto li dius a Git que detecti els fitxers de text i gestioni els salts de línia com toca (LF al repo; CRLF en working copy de Windows si aplica). I pots afinar per extensió, p. ex., forçar que els .sln de Visual Studio es mantinguin com a CRLF sempre.
* text=auto
# Homogeneiza automáticamente (LF en el repo)
*.sln text eol=crlf
# Asegura CRLF en soluciones de Visual Studio
Quan introdueixis .gitattributes en un repo ja viu, no t'oblidis de git add –renormalize . i d'agrupar el commit. Així evites que cada col·laborador generi el seu “megacommit de neteja”. És una d'aquelles tasques que fas una vegada i et treu problemes durant anys.
Configurar l'editor: VS Code, EditorConfig i Visual Studio
El teu editor també hi pinta molt. A Codi VS podeu fixar el salt de línia des de la barra d'estat o amb l'opció files.eol. Si el projecte utilitza LF, marca'l i llest; l'editor guardarà així sense que hagis d'anar fitxer per fitxer. És ràpid i t'evita diffs sorollosos.
Si a l'equip cadascú utilitza un editor diferent, incorporar EditorConfig (.editorconfig) a l'arrel és mà de sant: defineix regles com a final de línia, codificació i espai/tabulador de forma consistent. La majoria d'editors moderns ho respecten i s'integra fenomenal amb Git i CI.
Per a qui utilitzi Visual Studio, hi ha un panell específic per desar amb una codificació i salt de línia concrets (Opcions de desament avançades). Pots accedir al flux Fitxer > Desa Com > desplegable Desa > Desa amb codificació, i també col·locar Opcions de desament avançades directament al menú Fitxer per a drecera.
- Obre Tools > Personalitzar.
- A la pestanya ordres, tria Barra de menús i selecciona Arxiu.
- Prem Afegir comandament, categoria Arxiu, I afegeix Opcions de desament avançades.
- Recol·loca amb Pujar/Baixar i tanca. Ja ho tens a mà.
Amb Visual Studio també pots topar amb fitxers que porten altres separadors (NEL, LS, PS). L'IDE intenta normalitzar-los quan detecta inconsistències i et demanarà instrucció. Mantenir .gitattributes i les opcions de guardar ben posades evita que el projecte se t'ompli de “casos exòtics”.
Més enllà de CRLF i LF: NEL, LS, PS i companyia
Unicode considera com a finals de línia certs punts de codi addicionals: NEL (U+0085), LS (U+2028) y PS (U+2029), a més de VT (U+000B) y FF (U+000C). No són habituals en projectes d'app/web, però apareixen a mainframes IBM (EBCDIC) i en alguns documents processats amb eines antigues o de nínxol.
Per compatibilitat, Unicode replica els controls ASCII de sempre amb el mateix valor numèric (CR i LF), i afegeix els nous per a conversions sense pèrdua entre codificacions (ex., mapejar EBCDIC NL a Unicode NEL). Si t'arriba un fitxer “rar”, un editor modern sol mostrar o demanar normalitzar.
| Caràcter | Descripció | Unicode |
|---|---|---|
| CR LF | Retorn + avenç | U+000D + U+000A |
| LF | Avanç de línia | U + 000A |
| EN EL | Línia següent | U + 0085 |
| LS | Separador de línia | U + 2028 |
| PS | Separador de paràgraf | U + 2029 |
En versions antigues del Bloc de notes de Windows ni tan sols LF es mostrava bé; avui el suport és molt millor, però NEL continua sent problemàtic en alguns entorns. Per això, de cara a repos i CI, mantenir-ho tot LF al repo i deixar a Git/editors el CRLF de la working copy a Windows és la jugada guanyadora.
Llenguatges de programació i salts de línia (\r, \n, i paranys)
En cadenes de text, molts llenguatges permeten seqüències de fuita: \n = LF, \r = CR. Amb això compons CRLF com \r\n quan cal, o insereixes un LF “net” amb \n. Però compte, perquè no tots els runtimes es porten igual.
Casos a tenir en ment: a Java, a més de \ry \n, tens %n (formatejadors) i System.lineSeparator() per obtenir el salt de línia del sistema de manera portable; a C#, Environment.NewLine fa el mateix; a PHP hi PHP_EOL; a Pitó, os.linesep. Si vols imprimir segons la plataforma, fes servir aquestes constants en lloc de casar-te amb CRLF.
Cura especial amb C i C ++: en mode text, la seqüència \n pot mapejar-se al salt de línia del sistema (en Windows, CRLF), i si tu imprimeixes \r\n pots acabar generant CRCRLF. En mode binari, la cosa és literal. Aquesta subtilitat agafa desprevingut més d'un quan compila a Windows i testeja a Linux.
En JavaScript/TypeScript, \n n'hi ha prou per a la majoria d'usos, però si processes entrada d'usuaris de Windows veuràs \r\ny hauràs de normalitzar en dividir línies. A més, quan generes HTML la maquetació final la controlen les etiquetes (p., br, p, h2…), no els caràcters \ro \n.
// C#
var s1 = "Primera\nSegunda"; // LF explícito
var s2 = "Primera" + Environment.NewLine + "Segunda"; // Salto del sistema
// Java
String a = "Uno\r\nDos"; // CRLF explícito
String b = "Uno" + System.lineSeparator() + "Dos"; // Portátil
// Python
s = 'Linea1' + os.linesep + 'Linea2'
// JavaScript
const t = 'L1\nL2'; // Normaliza entrada si viene con \r\n
Si generes trànsit de xarxa, recorda que protocols com HTTP, SMTP, FTP o IRC són taxatius: les capçaleres i moltes línies de control van amb CRLF sí o sí. No inventions: ajusta la sortida a la RFC o et trobaràs amb servidors que rebutgen les peticions.
Com detectar i convertir finals de línia de manera fiable
No hi ha una “BOM” que et digui el tipus de salt de línia d'un fitxer: cal mirar els bytes. A la pràctica, les eines compten CR (0x0D) i LF (0x0A) i veuen els seus patrons: si apareixen aparellats, sol ser CRLF; si només apareix 0x0A, és LF; si hi ha barreja no consistent, tens un batiburret que convé arreglar.
Alguns editors detecten i avisen; VS Code ho mostra a la barra d'estat; Visual Studio pot oferir normalitzar. A Git, el pas segur és definir .gitattributes i, si escau, renormalitzar per alinear tot l'arbre amb la política. El teu repositori (i les teves revisions) t'ho agrairan.
I si treballes amb “formats exòtics”? Editors com Notepad++ i VS Code manegen bé CRLF i LF, i solen identificar LS/PS. Per a NEL i casos d'EBCDIC, de vegades tocarà passar per una conversió prèvia de codificació a més del salt de línia.
L'estratègia guanyadora a la majoria de projectes és simple: guarda al repo amb LF, habilita conversió automàtica a Windows, i bloqueja excepcions puntuals amb eol=crlf per a fitxers que ho necessitin (per exemple, .sln). La resta són ensurts evitables.
Repos amb salts de línia mixts: com arreglar el desgavell
És molt típic: parts del codi vénen de Linux (LF) i d'altres s'han tocat a Windows (CRLF). El resultat és un arbre amb línies barrejades, diffs impossibles de llegir i gent preguntant-se per què el seu script avui no arrenca. Toca posar ordre.
Pla ràpid i segur:
- afegeix .gitattributes amb * text=auto i regles específiques si cal (p. ex., *.sln text eol=crlf).
- executa git add –renormalize . perquè Git recorri el repo i ajusti els salts de línia segons les regles.
- Fes un commit únic amb un missatge clar (ex., “Homogeneïtzats els canvis de línia”).
- Comunica'l a l'equip i demana tirar abans de seguir per minimitzar conflictes.
Si tens scripts sensibles (sh, pi, etc.) assegura't que es guarden amb LF i que no es deforma el shebang. Pots forçar-ho amb patrons a .gitattributes o revisar-ho al teu editor abans de confirmar.
Per a Visual Studio, si detecteu salts inconsistents, us proposarà normalitzar. Accepta, revisa el diff, i acompanya'l del commit de renormalització anterior perquè tot quedi rodó.
Des d'aquell moment, amb .gitattributes i core.autocrlf ben posats, es van acabar els pegats de “aquesta vegada va passar per CRLF”. I si algú obre el projecte a Linux o macOS, tot seguirà igual perquè al repo els arxius queden guardats amb LF.
Redactor apassionat del món dels bytes i la tecnologia en general. M'encanta compartir els meus coneixements a través de l'escriptura, i això és el que faré en aquest bloc, mostrar tot el més interessant sobre gadgets, programari, maquinari, tendències tecnològiques, i més. El meu objectiu és ajudar-te a navegar pel món digital de forma senzilla i entretinguda.