Windows users should set git config --global core.autocrlf true, so that Git converts LF to CRLF when checked out and returns to LF when submitted; 2. macOS/Linux users should set git config --global core.autocrlf input, and only converts CRLF to LF when submitted; 3. The best practice is to submit .gitattributes files to the repository, clearly specify the line ending format of various types of files to ensure team consistency; 4. If there are already confusing line ending characters, configure .gitattributes first, then run git add --renormalize . and submit to fix it.
When working across different operating systems—like Windows, macOS, and Linux—you'll often run into issues with line endings in text files. Windows uses CRLF
( \r\n
), while Unix-based systems (macOS/Linux) use just LF
( \n
). Git can help manage this automatically so your repo stays clean and consistent.

Here's how to handle line endings properly in Git:
? Set core.autocrlf
(Windows Users)
If you're on Windows , set this in your global Git config:

git config --global core.autocrlf true
- Git will convert
LF
toCRLF
when checking out files (for Windows apps). - It converts
CRLF
back toLF
when committing (so the repo stays clean).
? This prevents Git from thinking every line changed just because of line endings.
? Set core.autocrlf
(macOS/Linux Users)
On macOS or Linux , use:

git config --global core.autocrlf input
- Git will convert any incoming
CRLF
toLF
on commit. - No conversion happens on checkout (since Unix tools expect
LF
).
? Use .gitattributes
(Best Practice for Teams)
Even better: define line ending behavior in the repo itself using a .gitattributes
file in your project root:
# Normalize all text files to LF on commit * text=auto eol=lf # Or, be more specific: *.sh text eol=lf *.py text eol=lf *.js text eol=lf *.md text eol=lf *.txt text eol=lf # Windows-specific files that should keep CRLF *.bat text eol=crlf *.cmd text eol=crlf
This ensures everyone gets consistent behavior—no matter their OS or local Git settings.
? Pro tip: Commit
.gitattributes
to your repo—it's part of your project's configuration now.
?? What If Line Endings Are Already Messed Up?
If your repo already has mixed line endings:
- Make sure
.gitattributes
is set up correctly. - Run this to re-normalize all files:
git add --renormalize .
- Commit the changes:
git commit -m "Normalize line endings"
This won't change your code—it just fixes how Git stores line endings internally.
Summary
- Windows:
core.autocrlf true
- macOS/Linux:
core.autocrlf input
- Always: Use
.gitattributes
for team projects - Fix existing issues with
git add --renormalize
It's not glamorous, but getting this right early saves headaches later—especially in cross-platform teams. Basically, just set it and forget it.
The above is the detailed content of How to Handle Line Endings Across Platforms in Git. For more information, please follow other related articles on the PHP Chinese website!
- Windows:

Hot AI Tools

Undress AI Tool
Undress images for free

Undresser.AI Undress
AI-powered app for creating realistic nude photos

AI Clothes Remover
Online AI tool for removing clothes from photos.

Clothoff.io
AI clothes remover

Video Face Swap
Swap faces in any video effortlessly with our completely free AI face swap tool!

Hot Article

Hot Tools

Notepad++7.3.1
Easy-to-use and free code editor

SublimeText3 Chinese version
Chinese version, very easy to use

Zend Studio 13.0.1
Powerful PHP integrated development environment

Dreamweaver CS6
Visual web development tools

SublimeText3 Mac version
God-level code editing software (SublimeText3)

Hot Topics

Packfile is an efficient mechanism used by Git to package, compress and transfer repository objects. When you execute gitpush, gitfetch or gitclone, what Git actually transmits is the packfile; 1. It is initially generated by loose objects through gitgc or gitrepack commands and stored in the .git/objects/pack/ directory; 2. The packfile not only contains object data, but also records the delta relationship between objects, and achieves rapid search with index file (.idx). 3. This design reduces the transmission volume and improves synchronization efficiency; 4. A large number of small packfiles may affect performance, and can be used through gitgc or git

To view Git commit history, use the gitlog command. 1. The basic usage is gitlog, which can display the submission hash, author, date and submission information; 2. Use gitlog--oneline to obtain a concise view; 3. Filter by author or submission information through --author and --grep; 4. Add -p to view code changes, --stat to view change statistics; 5. Use --graph and --all to view branch history, or use visualization tools such as GitKraken and VSCode.

To delete a Git branch, first make sure it has been merged or no retention is required. Use gitbranch-d to delete the local merged branch. If you need to force delete unmerged branches, use the -D parameter. Remote branch deletion uses the gitpushorigin-deletebranch-name command, and can synchronize other people's local repositories through gitfetch-prune. 1. To delete the local branch, you need to confirm whether it has been merged; 2. To delete the remote branch, you need to use the --delete parameter; 3. After deletion, you should verify whether the branch is successfully removed; 4. Communicate with the team to avoid accidentally deleting shared branches; 5. Clean useless branches regularly to keep the warehouse clean.

ToswitchGitbranches,firstupdatethelocalrepowithgitfetch,checkexistingbrancheswithgitbranchcommands,thenusegitcheckoutorgitswitchtochangebranches,handlinguncommittedchangesbycommitting,stashing,ordiscardingthem.WhenswitchingGitbranches,ensureyourlocal

To discard the modifications in the Git working directory and return to the state of the last commit, 1. For the modifications of the tracked files, use gitcheckout-- or gitcheckout--. Discard all modifications; 2. For new files that are not tracked, use gitclean-f to delete the files. If the directory is included, use gitclean-fd. Before execution, use gitclean-fd to preview the delete content; 3. If you need to reset all changes (including the temporary storage area and the working directory), use gitreset-hard. This command will reset the working directory and the temporary storage area. Be sure to operate with caution. These methods can be used individually or in combination to achieve the purpose of cleaning up the working directory.

To add a subtree to a Git repository, first add the remote repository and get its history, then merge it into a subdirectory using the gitmerge and gitread-tree commands. The steps are as follows: 1. Use the gitremoteadd-f command to add a remote repository; 2. Run gitmerge-srecursive-no-commit to get branch content; 3. Use gitread-tree--prefix= to specify the directory to merge the project as a subtree; 4. Submit changes to complete the addition; 5. When updating, gitfetch first and repeat the merging and steps to submit the update. This method keeps the external project history complete and easy to maintain.

Git hooks are used to automatically run scripts before and after commits, pushes and other operations to execute tasks. Specific uses include: 1. Run code checks or tests before submission; 2. Forced submission information format; 3. Send notifications after push. They help unify team specifications and reduce manual steps, such as preventing submissions when tests fail. Git hooks are located in the .git/hooks/ directory in the repository and are not shared by default. They need to be copied manually or used tools such as Husky for team collaboration. Writing a basic hook requires creating an executable file and naming the corresponding event, such as pre-commit, and writing logical judgments there to block or allow operations.

Soundstageafafileiititwittingchatcase, USEGITIZEADTORDOREMEVOME FROMARNINGAREAILACT.TOUNDACT Rungit Reset.ForPartialStialing, Usgit rests-PtointelavEevstehuncificisshunissehunissue
