Параметры установки окончаний строк в windows в git

About line endings

Every time you press return on your keyboard you insert an invisible character called a line ending. Different operating systems handle line endings differently.

When you’re collaborating on projects with Git and GitHub, Git might produce unexpected results if, for example, you’re working on a Windows machine, and your collaborator has made a change in macOS.

You can configure Git to handle line endings automatically so you can collaborate effectively with people who use different operating systems.

Global settings for line endings

The git config core.autocrlf command is used to change how Git handles line endings. It takes a single argument.

$ git config --global core.autocrlf input
# Configure Git to ensure line endings in files you checkout are correct for macOS

$ git config --global core.autocrlf true
# Configure Git to ensure line endings in files you checkout are correct for Windows.
# For compatibility, line endings are converted to Unix style when you commit files.

$ git config --global core.autocrlf input
# Configure Git to ensure line endings in files you checkout are correct for Linux

Per-repository settings

Optionally, you can configure a .gitattributes file to manage how Git reads line endings in a specific repository. When you commit this file to a repository, it overrides the core.autocrlf setting for all repository contributors. This ensures consistent behavior for all users, regardless of their Git settings and environment.

The .gitattributes file must be created in the root of the repository and committed like any other file.

A .gitattributes file looks like a table with two columns:

• On the left is the file name for Git to match.
• On the right is the line ending configuration that Git should use for those files.

Example

Here’s an example .gitattributes file. You can use it as a template for your repositories:

# Set the default behavior, in case people don't have core.autocrlf set.
* text=auto

# Explicitly declare text files you want to always be normalized and converted
# to native line endings on checkout.
*.c text
*.h text

# Declare files that will always have CRLF line endings on checkout.
*.sln text eol=crlf

# Denote all files that are truly binary and should not be modified.
*.png binary
*.jpg binary

You’ll notice that files are matched—*.c, *.sln, *.png—, separated by a space, then given a setting—text, text eol=crlf, binary. We’ll go over some possible settings below.

• text=auto Git will handle the files in whatever way it thinks is best. This is a good default option.

• text eol=crlf Git will always convert line endings to CRLF on checkout. You should use this for files that must keep CRLF endings, even on OSX or Linux.

• text eol=lf Git will always convert line endings to LF on checkout. You should use this for files that must keep LF endings, even on Windows.

• binary Git will understand that the files specified are not text, and it should not try to change them. The binary setting is also an alias for -text -diff.

Refreshing a repository after changing line endings

When you set the core.autocrlf option or commit a .gitattributes file, you may find that Git reports changes to files that you have not modified. Git has changed line endings to match your new configuration.

To ensure that all the line endings in your repository match your new configuration, backup your files with Git, delete all files in your repository (except the .git directory), then restore the files all at once.

1. Save your current files in Git, so that none of your work is lost.

   $ git add . -u
   $ git commit -m "Saving files before refreshing line endings"

2. Add all your changed files back and normalize the line endings.

   $ git add --renormalize .

3. Show the rewritten, normalized files.

   $ git status

4. Commit the changes to your repository.

   $ git commit -m "Normalize all the line endings"

Further reading

• Customizing Git — Git Attributes in the Pro Git book
• git-config in the man pages for Git
• Getting Started — First-Time Git Setup in the Pro Git book
• Mind the End of Your Line by Tim Clem

Время прочтения
9 мин

Просмотры 3.4K

Я работаю в операционной системе «Windows 10». У меня на компьютере установлена программа «Git for Windows» версии 2.35.1. В принципе, «Git for Windows» — это та же знаменитая программа (набор программ) «Git» (система управления версиями), только скомпилированная из исходного кода в исполняемый файл, который может запускаться в операционных системах «Windows» (изначально исходный код «Git» был написан для компиляции в исполняемый файл, запускаемый в операционной системе «Linux»).

Дистрибутив «Git for Windows» кроме программы «Git» содержит разные полезные для работы с «Git» программы, вроде программы-оболочки «Git Bash» с интерфейсом командной строки и программы «Git GUI» с графическим оконным интерфейсом. В документации сказано, что «Git for Windows» является подмножеством платформы (набора инструментов и библиотек) «MSYS2». Как я понимаю, для компиляции используется компилятор из набора инструментов «MinGW-w64».

Окончания строк в разных операционных системах

Как известно (возможно, не всем), в операционных системах «Windows» окончание строки обычно представляется двумя символами, в таблице Юникода они обозначены кодами U+000D (возврат каретки, по-английски «Carriage Return», сокращенно «CR») и U+000A (подача бумаги на следующую строку, по-английски «Line Feed», сокращенно «LF»). В мир компьютеров эти управляющие коды пришли из мира печатных (пишущих) машинок.

В Unix-подобных операционных системах окончание строки обычно представляется одним символом «LF». (Говорят, в операционных системах от компании «Apple» до появления операционной системы «Mac OS X», которая вышла в 2001 году, окончание строки представлялось одним символом «CR». Сейчас в операционных системах «macOS» окончание строки представляется одним символом «LF», как и в других Unix-подобных операционных системах.)

Из-за того, что большинство текстовых редакторов (даже заточенных под написание текстов программ) плохо умеет работать с окончаниями строк разного вида, вышеописанная разница приносит проблемы, если над одним и тем же проектом работают программисты из разных операционных систем.

Я подготовил для экспериментов текстовый файл, содержащий несколько строк с окончаниями разного вида. Для работы с кодом я обычно использую программы «VS Code» и «Notepad++». Обе эти программы могут правильно отображать строки с окончаниями разного вида. Однако, программа «VS Code» не отображает отдельные символы, входящие в окончания строк, поэтому в ней не получается понять, где и какое окончание строки использовано. Для просмотра и определения видов окончаний строк я обычно использую программу «Notepad++», она умеет отображать отдельные символы, входящие в окончания строк. Вот как у меня на компьютере выглядит в программе «Notepad++» тестовый файл «myfile.txt» (включено отображение всех символов, то есть и тех, которые обычно не отображаются в текстовых редакторах):

На иллюстрации выше видно, что две строки имеют окончания в виде пары символов CR и LF (эту пару символов часто обозначают как «CRLF»), а другие две строки — в виде LF. В программе «Notepad++» у меня не получилось создать разные виды окончаний строк в одном и том же файле (хотя можно скопировать и вставить существующие с помощью инструмента специальной вставки), поэтому я сначала ввел текст файла в программе «Notepad++» с одинаковыми окончаниями строк, а потом подправил два из этих окончаний строк в шестнадцатеричном (двоичном) редакторе. Кодировка файла «myfile.txt» — UTF-8 (как видно на иллюстрации, размер файла — 222 байта, русские буквы занимают по два байта).

Также на иллюстрации выше видно, что в строке состояния программы «Notepad++» режим работы с окончаниями строк показан как «Windows (CR LF)». Этот режим не влияет на отображение символов только что открытого файла. Он лишь говорит о том, что при вставке нового окончания строки (нажатием клавиши «Enter») будет вставлено окончание строки вида CRLF. Этот режим можно переключить на «Unix (LF)» или на «Macintosh (CR)», после чего можно будет клавишей «Enter» вставлять окончания строк вида LF или CR. Однако, переключение этого режима не дает возможности работать в одном файле одновременно с несколькими видами окончаний строк, так как при переключении этого режима меняются сразу все окончания строк в файле на выбранный в режиме вид окончаний строк.

Тестовый файл «myfile.txt» я разместил в папке C:UsersИльяsourcerepostest. Пока он в этой папке один. Будем считать эту папку папкой нашего проекта.

Создание Git-репозитория и параметр «core.autocrlf»

С программой «Git» можно работать множеством способов, но я предпочитаю самый универсальный — из командной строки. Для этого я обычно использую программу-оболочку «PowerShell» версии 7, а запускаю ее в программе-«эмуляторе терминала» «Windows Terminal». Итак, проверим, что программа «Git» установлена на компьютере и доступна в папке нашего проекта:

PS C:UsersИльяsourcerepostest> git --version
git version 2.35.1.windows.2

Создадим Git-репозиторий для нашего проекта:

PS C:UsersИльяsourcerepostest> git init
Initialized empty Git repository in C:/Users/Илья/source/repos/test/.git/

«Репозиторием» обычно называют папку (хранилище, базу данных), в которой хранится исходный код программы (папку проекта). А «Git-репозиторием» называют базу данных, в которой хранятся разные версии файлов нашего проекта, информация о них и об изменениях, вносимых в эти файлы. Сама программа (система программ) «Git» у меня установлена в папке C:Program FilesGit. Чтобы обеспечить управление версиями файлов нашего проекта, в папке нашего проекта с помощью вышеприведенной команды была создана скрытая папка «.git» (у меня в программе «Проводник Windows» включено отображение скрытых папок, поэтому ее там видно), в которой хранятся база данных с версиями файлов нашего проекта и разные служебные файлы.

Сразу после создания папки «.git» в ней уже есть файлы базы данных и разные служебные файлы. Но пока что эта база данных пуста (пока еще не содержит версий файлов нашего проекта). Чтобы файлы нашего проекта попали под отслеживание в них изменений от программы «Git», они должны быть добавлены в базу данных в папке «.git» посредством коммитов («коммит» — это операция регистрации изменений в файлах проекта).

Настройка работы программы «Git» может быть произведена на трех разных уровнях: на уровне операционной системы (для всех ее пользователей), на уровне отдельного пользователя (global) и на уровне проекта (local). При установке программы «Git» программа-установщик обычно задает умолчательные настройки на уровне текущего пользователя операционной системы. В рамках данного поста мы затронем только настройки на уровне текущего проекта, они хранятся в файле .gitconfig (этот файл не имеет расширения) текущего проекта. Этот файл был создан в результате вышеприведенной команды «git init», он — текстовый, но нет нужды редактировать его вручную, для этого есть отдельная команда «git config».

Если какой-либо параметр не определен в вышеупомянутом файле настроек текущего проекта, то значение этого параметра будет автоматически взято из файла настроек текущего пользователя операционной системы. Для чистоты эксперимента мы будем прямо прописывать нужное значение нужного параметра в файле настроек текущего проекта с помощью следующей команды:

PS C:UsersИльяsourcerepostest> git config --local core.autocrlf true

Как работает параметр «core.autocrlf» мы проверим экспериментально, после чего станет понятно, для чего этот параметр можно использовать.

1. Параметр «core.autocrlf», значение «true»

Итак, с помощью команды, приведенной выше, мы установили для параметра «core.autocrlf» значение «true». Совершим первый коммит, в который включим текущую версию нашего тестового файла «myfile.txt»:

PS C:UsersИльяsourcerepostest> git add "myfile.txt"
warning: LF will be replaced by CRLF in myfile.txt.
The file will have its original line endings in your working directory

PS C:UsersИльяsourcerepostest> git commit -m "Первый коммит"
[master (root-commit) 4d71045] Первый коммит
 1 file changed, 4 insertions(+)
 create mode 100644 myfile.txt

В блоке кода выше приведены сразу две команды подряд. Команда «git add» формирует список содержимого будущего коммита. Когда содержимое коммита сформировано, делаем сам коммит (регистрацию изменений в коде программы в базе данных в папке «.git» нашего проекта) с помощью команды «git commit».

Два сообщения, выданные после первой команды в блоке кода выше, могут запутать неопытного пользователя. Первое сообщает о том, что окончания строк вида LF будут заменены окончаниями строк вида CRLF в нашем тестовом файле «myfile.txt». Второе сообщает, что версия файла «myfile.txt», находящаяся в папке проекта, сохранит окончания строк в оригинальном виде. На первый взгляд, эти сообщения противоречат друг другу. Путаница возникает из-за того, что в обоих сообщениях употреблено будущее время, но не уточняется, что события, о которых идет речь, хоть и произойдут в будущем, но произойдут НЕ одновременно.

На самом деле, во втором сообщении имеется в виду, что оригинальные окончания строк в файле «myfile.txt» останутся нетронутыми работой запущенной команды «git add». А первое сообщение предупреждает о том, что в будущем, после извлечения версии файла «myfile.txt» из базы данных в папку проекта, окончания строк вида LF будут затерты окончаниями строк CRLF из-за текущего значения настройки «core.autocrlf».

Проверим это на практике. После окончания работы двух команд, показанных в блоке кода выше, я заглянул в файл «myfile.txt», находящийся в папке проекта (в терминах программы «Git» ее называют «рабочей папкой» [working directory], так как именно тут мы работаем с файлами проекта, вносим в них изменения), и убедился, что окончания строк в нем остались без изменений (две строки с окончаниями вида CRLF, две строки с окончаниями вида LF). То есть обещание «The file will have its original line endings in your working directory» сбылось.

После этого я удалил файл «myfile.txt» из папки проекта в корзину операционной системы. Представим, что я потерял рабочие файлы своего проекта. Восстановим их (конкретно в нашем проекте один файл, но в общем случае их может быть много) в папку проекта из базы данных, созданной ранее средствами программы «Git» для нашего проекта:

PS C:UsersИльяsourcerepostest> git checkout -f master
Already on 'master'

В результате этой команды в папке проекта снова появился файл «myfile.txt». Однако, все четыре окончания строк в этом файле теперь стали одного вида: CRLF. Сбылось обещание из предупреждения «warning: LF will be replaced by CRLF in myfile.txt.».

Как работает настройка «core.autocrlf» со значением «true»? Если при такой настройке мы помещаем версию измененного файла в базу данных «Git» данного проекта, то все найденные в этом файле окончания строк вида CRLF конвертируются в окончания строк вида LF. Если при такой настройке мы извлекаем версию файла, хранящуюся в базе данных «Git» данного проекта, то все найденные в этой версии файла окончания строк вида LF конвертируются в окончания строк вида CRLF. Вот как это можно показать схематично:

  add, commit       База        checkout
-------------->  данных Git  -------------->
 (CRLF -> LF)       (LF)      (LF -> CRLF)

Подчеркну, что на этой схеме внесение в базу данных (коммит) и извлечение из нее (checkout) разнесены во времени. Если внесение в базу данных произошло при настройке «core.autocrlf» со значением «true», а извлечение из базы данных произошло при настройке «core.autocrlf» со значением «false», то конвертация при извлечении не произойдет и все четыре окончания строк в извлеченном файле окажутся вида LF (в том виде, в котором этот файл был помещен в базу данных и хранится там). Это замечание может быть сходным образом применено и к другим значениям настройки «core.autocrlf».

2. Параметр «core.autocrlf», значение «false»

Схема работы при такой настройке:

    add, commit            База             checkout
------------------->    данных Git     ------------------->
 (без конвертации)    (CRLF и/или LF)   (без конвертации)

При такой настройке в базе данных «Git» будет храниться именно то, что мы туда положили. И будет извлечено именно то, что хранится в базе данных, без изменений.

3. Параметр «core.autocrlf», значение «input»

Схема работы при такой настройке:

  add, commit       База          checkout
-------------->  данных Git  ------------------->
 (CRLF -> LF)       (LF)      (без конвертации)

Зачем нужны эти три настройки

Параметр «core.autocrlf» со значением «false» — это естественный режим работы программы «Git», который использовался бы, если б не было разницы в представлении окончаний строк в разных операционных системах.

Собственно, параметр «core.autocrlf» придумали для обеспечения работы над одним проектом программистов из разных операционных систем. Предполагается, что программист в операционной системе «Windows» будет работать с файлами, в которых окончания строк только вида CRLF. При этом предполагается, что он включит для проекта настройку «core.autocrlf» со значением «true». Тогда он будет работать в своей папке проекта с файлами, в которых окончания строк будут вида CRLF, при этом в базе данных «Git» эти же файлы будут сохранены с окончаниями вида LF. Программист в операционной системе «Windows» этого даже не заметит, ведь конвертация происходит автоматически, как было показано выше в пункте 1.

В тот же момент программист в Unix-подобной операционной системе будет работать с той же базой данных «Git», но у него для проекта будет включена настройка «core.autocrlf» со значением «input» (или со значением «false»). Он будет получать из базы данных файлы с окончаниями строк вида LF, как и принято в Unix-подобных операционных системах.

В принципе, программист в операционной системе «Windows» тоже может использовать параметр «core.autocrlf» со значением «false» в случае, если он работает со своей базой данных «Git» один и пишет код только для операционных систем Windows. Либо он работает вместе с другими программистами, но все участники проекта работают в операционных системах «Windows» и проект предназначен только для операционных систем «Windows». Либо, еще один вариант, в коде есть файлы с окончаниями строк разного вида (CRLF и/или LF) и программист хочет сам отслеживать виды окончаний строк в своих файлах, без вмешательства программ, без автоматической конвертации.

Полезные ссылки

1. В книге «Pro Git» (вторая редакция, вышла в 2014 году), авторы: Scott Chacon (Скотт Чакон) и Ben Straub (Бен Страуб), в главе 8 «Настройка Git», в подглаве 8.1 «Конфигурация Git» (статья большая, ищите в ее последней трети раздел «Форматирование и пробелы»).

2. Хороший, развернутый ответ на вопрос «Git replacing LF with CRLF» на известном сайте «Stack Overflow».

Line ending format used in OS:

• Windows: CR (Carriage Return r) and LF (LineFeed n) pair
• OSX, Linux: LF (LineFeed n)

We can configure git to auto-correct line ending formats for each OS in two ways.

1. Git Global configuration
2. Using .gitattributes file

Global Configuration

In Linux/OSX

git config --global core.autocrlf input

This will fix any CRLF to LF when you commit.

In Windows

git config --global core.autocrlf true

This will make sure that, when you checkout in windows, all LF will be converted to CRLF.

.gitattributes File

It is a good idea to keep a .gitattributes file as we don’t want to expect everyone in our team to set their own config. This file should be placed in the repository root and. If it exists, git will respect it.

* text=auto

This will treat all files as text files and convert to OS’s line ending on checkout and back to LF on commit automatically. If you want to specify the line ending explicitly, you can use:

* text eol=crlf
* text eol=lf

The first one is for checkout and the second one is for commit.

*.jpg binary

This will treat all .jpg images as binary files, regardless of path. So no conversion needed.

Or you can add path qualifiers:

my_path/**/*.jpg binary

Line ending format used in OS:

• Windows: CR (Carriage Return r) and LF (LineFeed n) pair
• OSX, Linux: LF (LineFeed n)

We can configure git to auto-correct line ending formats for each OS in two ways.

1. Git Global configuration
2. Using .gitattributes file

Global Configuration

In Linux/OSX

git config --global core.autocrlf input

This will fix any CRLF to LF when you commit.

In Windows

git config --global core.autocrlf true

This will make sure that, when you checkout in windows, all LF will be converted to CRLF.

.gitattributes File

It is a good idea to keep a .gitattributes file as we don’t want to expect everyone in our team to set their own config. This file should be placed in the repository root and. If it exists, git will respect it.

* text=auto

This will treat all files as text files and convert to OS’s line ending on checkout and back to LF on commit automatically. If you want to specify the line ending explicitly, you can use:

* text eol=crlf
* text eol=lf

The first one is for checkout and the second one is for commit.

*.jpg binary

This will treat all .jpg images as binary files, regardless of path. So no conversion needed.

Or you can add path qualifiers:

my_path/**/*.jpg binary

До этого момента мы описывали основы того, как Git работает и как его использовать, а так же мы познакомились с некоторыми инструментами Git, которые делают его использование простым и эффективным.
В этой главе мы рассмотрим некоторые настройки Git и систему хуков, что позволяет настроить поведение Git.
Таким образом, вы сможете заставить Git работать именно так как нужно вам или вашей компании.

Конфигурация Git

В главе Введение кратко упоминалось, что вы можете настроить Git, используя команду git config.
Первое, что вы делали, это установили своё имя и e-mail адрес:

$ git config --global user.name "John Doe"
$ git config --global user.email johndoe@example.com

Сейчас вы познакомитесь с несколькими наиболее интересными опциями, которые можно установить для настройки поведения Git.

Кратко: Git использует набор конфигурационных файлов для изменения стандартного поведения, если это необходимо.
Вначале, Git ищет настройки в файле /etc/gitconfig, который содержит настройки для всех пользователей в системе и всех репозиториев.
Если передать опцию --system команде git config, то операции чтения и записи будут производиться именно с этим файлом.

Следующее место, куда смотрит Git — это файл ~/.gitconfig (или ~/.config/git/config), который хранит настройки конкретного пользователя.
Вы можете указать Git читать и писать в него, используя опцию --global.

Наконец, Git ищет параметры конфигурации в файле настроек в каталоге Git (.git/config) текущего репозитория.
Эти значения относятся только к текущему репозиторию и доступны при передаче параметра --local команде git config.
(Если уровень настроек не указан явно, то подразумевается локальный.)

Каждый из этих уровней (системный, глобальный, локальный) переопределяет значения предыдущего уровня, например, значения из .git/config важнее значений из /etc/gitconfig.

$ git config --global core.editor emacs

Subject line (try to keep under 50 characters)

Multi-line description of commit,
feel free to be detailed.

[Ticket: X]

$ git config --global commit.template ~/.gitmessage.txt
$ git commit

Subject line (try to keep under 50 characters)

Multi-line description of commit,
feel free to be detailed.

[Ticket: X]
# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
# On branch master
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
# modified:   lib/test.rb
#
~
~
".git/COMMIT_EDITMSG" 14L, 297C

$ git config --global core.pager ''

$ git config --global user.signingkey <gpg-key-id>

$ git chekcout master
git: 'chekcout' is not a git command. See 'git --help'.

The most similar command is
    checkout

$ git chekcout master
WARNING: You called a Git command named 'chekcout', which does not exist.
Continuing under the assumption that you meant 'checkout'
in 0.1 seconds automatically...

$ git config --global color.ui false

color.branch
color.diff
color.interactive
color.status

$ git config --global color.diff.meta "blue black bold"

$ cat /usr/local/bin/extMerge
#!/bin/sh
/Applications/p4merge.app/Contents/MacOS/p4merge $*

path old-file old-hex old-mode new-file new-hex new-mode

$ cat /usr/local/bin/extDiff
#!/bin/sh
[ $# -eq 7 ] && /usr/local/bin/extMerge "$2" "$5"

$ sudo chmod +x /usr/local/bin/extMerge
$ sudo chmod +x /usr/local/bin/extDiff

$ git config --global merge.tool extMerge
$ git config --global mergetool.extMerge.cmd 
  'extMerge "$BASE" "$LOCAL" "$REMOTE" "$MERGED"'
$ git config --global mergetool.extMerge.trustExitCode false
$ git config --global diff.external extDiff

[merge]
  tool = extMerge
[mergetool "extMerge"]
  cmd = extMerge "$BASE" "$LOCAL" "$REMOTE" "$MERGED"
  trustExitCode = false
[diff]
  external = extDiff

$ git diff 32d1776b1^ 32d1776b1

$ cat /usr/local/bin/extMerge
#!/bin/sh
/Applications/kdiff3.app/Contents/MacOS/kdiff3 $*

$ git mergetool --tool-help
'git mergetool --tool=<tool>' may be set to one of the following:
        emerge
        gvimdiff
        gvimdiff2
        opendiff
        p4merge
        vimdiff
        vimdiff2

The following tools are valid, but not currently available:
        araxis
        bc3
        codecompare
        deltawalker
        diffmerge
        diffuse
        ecmerge
        kdiff3
        meld
        tkdiff
        tortoisemerge
        xxdiff

Some of the tools listed above only work in a windowed
environment. If run in a terminal-only session, they will fail.

$ git config --global merge.tool kdiff3

$ git config --global core.autocrlf true

$ git config --global core.autocrlf input

$ git config --global core.autocrlf false

$ git config --global core.whitespace 
    trailing-space,-space-before-tab,indent-with-non-tab,tab-in-indent,cr-at-eol

$ git config --global core.whitespace 
    -space-before-tab,indent-with-non-tab,tab-in-indent,cr-at-eol

$ git apply --whitespace=warn <patch>

$ git apply --whitespace=fix <patch>

$ git config --system receive.fsckObjects true

$ git config --system receive.denyNonFastForwards true

$ git config --system receive.denyDeletes true

Line ending format used in OS:

• Windows: CR (Carriage Return r) and LF (LineFeed n) pair
• OSX, Linux: LF (LineFeed n)

We can configure git to auto-correct line ending formats for each OS in two ways.

1. Git Global configuration
2. Using .gitattributes file

Global Configuration

In Linux/OSX

git config --global core.autocrlf input

This will fix any CRLF to LF when you commit.

In Windows

git config --global core.autocrlf true

This will make sure that, when you checkout in windows, all LF will be converted to CRLF.

.gitattributes File

It is a good idea to keep a .gitattributes file as we don’t want to expect everyone in our team to set their own config. This file should be placed in the repository root and. If it exists, git will respect it.

* text=auto

This will treat all files as text files and convert to OS’s line ending on checkout and back to LF on commit automatically. If you want to specify the line ending explicitly, you can use:

* text eol=crlf
* text eol=lf

The first one is for checkout and the second one is for commit.

*.jpg binary

This will treat all .jpg images as binary files, regardless of path. So no conversion needed.

Or you can add path qualifiers:

my_path/**/*.jpg binary

Git — это распределенная система управления версиями.

Для начала установим GIT

Первоначальные настройки

git config --list

Выводит список всех настроек.

Для начала зададим имя:

git config --global user.name "Dmitriy"

И зададим e-mail в глобальную настройку:

git config --global user.email "ip@polyakovdmitriy.ru"

Параметры установки окончаний строк:

Для предотвращения проблем, при работе на разных операционных системах.

для unix/mac:

git config --global core.autocrlf input
git config --global core.safecrlf warn

для виндовс:

git config --global core.autocrlf true
git config --global core.safecrlf warn

Установка отображения unicode

git config --global core.quotepath off

Создание репозитория

Для создания репозитория, нужно из папки проекта, набрать команду:

git init

Для добавления файлов в репозиторий:

git add index.html
git commit -m "create file"

Проверка состояния репозитория

git status

После внесения изменений в файл, например index.html

Можно или проиндексировать их командой

git add index.html

Или использовать команду, для отмены изменений:

git checkout --index.html

После индексации изменений, можно:

Снять индексацию изменений, командой:

git reset HEAD index.html

Командой commit — можно закомитить все проиндексированные изменения.

Для индексации всех изменений в каталоге и подкаталогах, можно использовать команду

git add .

Просмотр истории

git log

Формат истории настраивается, допустим будем использовать такой:

git log --pretty=format:"%h %ad | %s%d [%an]" --graph --date=short

Чтобы не набирать такую длинную команду, можно задать алиас:

git config --global alias.hist "log --pretty=format:'%h %ad | %s%d [%an]' --graph --date=short"

Получение старых версий

Для получения старой версии, нужно ввести команду:

git checkout <hash>

В качестве hash, используется версия, которая выводится при git config, достаточно использовать первые 7 знаков хэш-кода.

Для возврата к последней версии в ветке master, используется команда

git checkout master

Создаем теги версий

git tag v1

После этого можно использовать при откатывании название тега, вместо хэша:

git checkout v1

Для откатывания на предыдущую версию, которая перед тегом v1, можно использовать такую команду:

git checkout v1~1

Для того чтобы сделать коммит, который отменит предыдущий, можно набрать команду:

git revert HEAD --no-edit

Сброс коммитов до определенного:

git reset --hard v1

Изменение предыдущего коммита:

git commit --amend -m "Add fishka"

Создаем ветку

git branch <имяветки>

Переключаемся на созданную ветку

git checkout <имяветки>

Слияние веток

git merge master

Перебазирование

git rebase master

Лучше не использовать перебазирование, если ветка является публичной или расшаренной.

Клонирование репозиториев

git clone hello cloned_hello

Посмотреть ветки

git branch

Или все ветки

git branch -a

Извлечение изменений в клонированном репозитории

git fetch

Слияние извлеченных изменений

git merge origin/master

Или для слияния можно использовать

git pull

что эквивалентно:

git fetch
git merge origin/master

Добавление ветки наблюдения

git branch --track styles origin/styles

Создание чистого репозитория

git clone --bare hello hello.git

Добавление удаленного репозитория

git remote add shared ../hello.git

Отправка изменений в удаленный репозиторий

git push shared master

Извлечение общих изменений

git remote add shared ../hello.git
git branch --track shared master
git pull shared master

Далее запускаем git сервер и можно использовать совместно.

Символы конца строки EOL для текстовых файлов различаются в зависимости от операционной системы. Linux использует перевод строки LF, Windows использует возврат каретки + перевод строки CRLF. Если несколько разработчиков работают над одним проектом на GitHub под разными операционными системами — бардак практически гарантирован.

Главное, что нужно помнить — в репозитории все текстовые файлы должны быть с окончаниями LF.

Настройки EOL для Git

Настройка core.eol имеет значение по умолчанию native, другие возможные значения — это lf и crlf. Git использует значение этой настройки, когда записывает файлы в рабочую директорию при выполнении таких команд, как git checkout или git clone. Имеет смысл, только если core.autocrlf равно true.

Настройка core.autocrlf имеет значение по умолчанию false, другие возможные значения — это true и input. Настройка определяет, будет ли Git выполнять какие-либо преобразования EOL при записи/чтении в/из репозитория. Значение по умолчанию опасно, потому что может привести к записи в репозиторий CRLF файлов.

• core.autocrlf=false — ничего не делать при записи в репозиторий, ничего не делать при чтении из репозитория
• core.autocrlf=input — при записи в репозиторий заменять CRLF на LF, при чтении из репозитория ничего не делать
• core.autocrlf=true — при записи в репозиторий заменять CRLF на LF, при чтении из репозитория заменять LF на core.eol

Значение input подходит при работе под Linux:

$ git config --local core.eol native
$ git config --local core.autocrlf input

Значение true подходит при работе под Windows:

$ git config --local core.eol native
$ git config --local core.autocrlf true

При выполнении этих команд будет создан файл .git/config в директории проекта:

[core]
eol = native
autocrlf = input

[core]
eol = native
autocrlf = true

Можно записать эти значения в глобальный файл конфигурации Git ~/.gitconfig, если заменить --local на --global.

Все настройки Git

Поскольку мы тут работаем с настройками Git, есть смысл упомянуть, какие они бывают и как их посмотреть.

• Системная конфигурация Git управляет настройками для всех пользователей и всех репозиториев на компьютере.
• Глобальная конфигурация Git управляет настройками текущего вошедшего пользователя и всех его репозиториев.
• Локальная конфигурация Git управляет настройками для отдельно взятого репозитория.

Эти три файла конфигурации выполняются в каскадном порядке — сначала системный, затем глобальный, и наконец, локальный. Это означает, что локальная конфигурация Git всегда будет перезаписывать настройки, установленные в глобальной или системной конфигурации.

$ git config --list
$ git config --list --system
$ git config --list --global
$ git config --list --local

Если не указать, какую конфигурацию надо показать (первая команда) — будут показаны все три конфигурации, объединенные в вывод консоли. Чтобы посмотреть настройки вместе с именем файла конфигурации, можно использовать ключ show-origin.

$ git config --list --show-origin
file:C:/Program Files/Git/etc/gitconfig http.sslcainfo=C:/Program Files/Git/mingw64/ssl/certs/ca-bundle.crt
file:C:/Program Files/Git/etc/gitconfig http.sslbackend=openssl
file:C:/Program Files/Git/etc/gitconfig diff.astextplain.textconv=astextplain
..........
file:C:/Users/Evgeniy/.gitconfig        user.name=Evgeniy Tokmakov
file:C:/Users/Evgeniy/.gitconfig        user.email=...............
file:C:/Users/Evgeniy/.gitconfig        core.autocrlf=false
..........
file:.git/config        core.repositoryformatversion=0
file:.git/config        core.filemode=false
file:.git/config        core.bare=false
..........

$ git config --list --show-origin | grep autocrlf
file:C:/Program Files/Git/etc/gitconfig core.autocrlf=true
file:C:/Users/Evgeniy/.gitconfig        core.autocrlf=false
file:.git/config                        core.autocrlf=true

Небольшой эксперимент

У меня операционная система Windows. Создаем директорию repo-eol-example, внутри нее — текстовой файл file.txt. Добавим в файл пару строк и убедимся, что окончания строк — CRLF.

Переходим в директорию проекта, выполняем три команды

$ git init
$ git config --local core.eol native
$ git config --local core.autocrlf true

Добавляем наш файл в индекс и фиксируем изменения

$ git add file.txt
$ git commit -m "add file.txt"

Добавляем в наш файл еще строку, чтобы он изменился

И восстановим его из репозитория в изначальном виде

$ git checkout -- file.txt

Что произошло? При добавлении файла в репозиторий (commit) символы CRLF были заменены на LF. При извлечении файла в рабочую директорию (checkout) — символы LF были заменены на CRLF.

Давайте убедимся в том, что в репозитории у нас символы LF. Для этого изменим настройку Git, чтобы вообще никаких замен не было. Добавим в файл строку, а потом восстановим из репозитория в изначальном виде.

$ git config --local core.autocrlf false
$ git checkout -- file.txt

Что произошло? При извлечении файла в рабочую директорию — символы EOL остались без изменений, как они сохранены в репозитории.

Предупреждения от Git

Когда случается нештатная ситуация — Git предупреждает об этом. Например, если мы установили следующие настройки для Git:

$ git config --local core.eol native
$ git config --local core.autocrlf input

И пытаемся записать CRLF файл в репозиторий — Git предупреждает, что символы CRLF будут заменены на LF (при записи в репозиторий). Тут ситуация явно нештатная — вроде бы настройки соответствуют Linux, но при этом в рабочей директории откуда-то взялся CRLF файл, а этого быть не должно.

$ git add other.txt
warning: CRLF will be replaced by LF in other.txt.
The file will have its original line endings in your working directory

При извлечении такого файла из репозитория в рабочую директорию — никаких преобразований EOL не будет, потому что input работает только при записи в репозиторий. И мы получим LF окончания строк в этом файле — так, как и должно быть в Linux.

Еще одна нештатная ситуация — мы установили следующие настройки для Git:

$ git config --local core.eol native
$ git config --local core.autocrlf auto

И пытаемся записать LF файл в репозиторий — Git предупреждает, что символы LF будут заменены на CRLF (при чтении из репозитория). Тут ситуация явно нештатная — вроде бы настройки соответствуют Windows, но при этом в рабочей директории откуда-то взялся LF файл, а этого быть не должно.

$ git add another.txt
warning: LF will be replaced by CRLF in another.txt.
The file will have its original line endings in your working directory

При извлечении такого файла из репозитория в рабочую директорию — будет выполнена замена LF на CRLF. И мы получим CRLF окончания строк в этом файле — так, как и должно быть в Windows.

Тут важно то, что как в первой, так и во второй ситуации — файл будет сохранен в репозитории с LF окончаниями строк, как и должно быть.

Настройка core.safecrlf

Как Git узнает, что файл является текстовым? У Git есть внутренний метод эвристической проверки, является ли файл двоичным или нет. Файл считается текстовым, если он не является двоичным. Git иногда может ошибаться — и по этой причине существует настройка core.safecrlf.

Эту настройку нужно установить в значение true. Тогда при подготовке к замене CRLF на LF — Git проверит, что сможет успешно отменить операцию. Это защита от того, чтобы выполнить замену в файле, который не является текстовым — и, тем самым, безнадежно его испортить.

Работа под Windows

Лично мне удобно везде использовать LF, хотя у меня основная система Windows — поэтому установил себе настройки, чтобы вообще не заменять EOL.

$ git config --global core.eol native
$ git config --global core.autocrlf false

Современные IDE способны работать под Windows с EOL как в Linux, так что необходимости в заменах просто нет. В настройках VS Code у меня установлено значение LF для EOL.

{
    ..........
    "files.eol": "n", // символ конца строки как в linux
    ..........
}

Чтобы следить за символами конца строки — можно установить расширение «Render Line Endings», которое показывает символы LF и CRLF.

{
    ..........
    "editor.renderWhitespace": "all", // показывать символы пробелов
    "files.eol": "n", // символ конца строки как в linux
    ..........
    "code-eol.newlineCharacter": "↓", // символ LF
    "code-eol.crlfCharacter"   : "←↓", // символы CRLF
    // подсвечивать как ошибку EOL в файле, если не совпадает с настройкой files.eol
    "code-eol.highlightNonDefault": true,
}

Когда в проект случайно попадёт файл с CRLF символами конца строки — эти символы будут подсвечены красным цветом (вообще, цветом errorForeground темы).

Но такая подсветка будет всего секунду, потому что у меня еще настроено автосохранение открытых файлов — но этой секунды достаточно, чтобы увидеть проблему и отреагировать.

{
    ..........
    "editor.renderWhitespace": "all", // показывать символы пробелов
    "files.eol": "n", // символ конца строки как в linux
    "files.autoSave": "afterDelay", // автоматическое сохранение файла
    "files.autoSaveDelay": 1000, // задержка перед сохранением файла
    ..........
    "code-eol.newlineCharacter": "↓", // символ LF
    "code-eol.crlfCharacter"   : "←↓", // символы CRLF
    // подсвечивать как ошибку EOL в файле, если не совпадает с настройкой files.eol
    "code-eol.highlightNonDefault": true,
}

Чтобы настройки VS Code всегда были правильными, можно создать файл .editorconfig в корне проекта и установить расширение «EditorConfig for VS Code». Расширение читает файл .editorconfig и устанавливает правильные настройки VS Code.

# эта настройка должна быть в самом начале; если установлена в true,
# парсер не будет искать другие конфиги родительских директориях
root = true

# правила для текстовых файлов
[*.{txt,md,html,css,scss,js,jsx,ts,tsx,py,php,json,xml,sh}]
# кодировка файлов
charset = utf-8
# концы строк как в linux
end_of_line = lf
# пустая строка в конце файла
insert_final_newline = true
# удалять пробелы в конце строк
trim_trailing_whitespace = true
# заменять табуляцию на пробелы
indent_style = space
# табуляция заменяется 4 пробелами
indent_size = 4

{
    ..........
    "files.encoding": "utf8", // кодировка файлов
    "files.eol": "n", // концы строк как в linux
    "files.insertFinalNewline": true, // пустая строка в конце файла
    "files.trimTrailingWhitespace": true, // удалять пробелы в конце строк
    "editor.insertSpaces": true, // заменять табуляцию на пробелы
    "editor.tabSize": 4, // табуляция заменяется 4 пробелами
    ..........
}

Еще лучше — разместить файл .editorconfig в корне директории, которая содержит все проекты, над которыми идет работа. Тогда при открытии любого проекта VS Code будет подхватывать этот файл и его не надо будет создавать отдельно для каждого проекта.

Работа в команде

В настоящее время настройку core.autocrlf использовать нежелательно. На смену ей пришел файл .gitattributes в корне рабочей директории проекта, который нужно добавить под наблюдение Git.

*   text=auto

$ git add .gitattributes
$ git commit -m "Add .gitattributes"

Тем самым мы говорим Git, чтобы он самостоятельно определял текстовые файлы и заменял CRLF на LF при записи в репозиторий. Это эквивалентно установке core.autocrlf=true в файле конфигурации, но файл .gitattributes имеет приоритет над файлом конфигурации.

Таким образом, у всех разработчиков, которые работают над одним проектом, будет одинаковое поведение Git при записи в репозиторий. А вот настройка core.eol у каждого разработчика будет своя, из файла конфигурации на компьютере. И извлекать файлы в рабочую директорию разработчик может с любыми окончаниями — LF или CRLF.

Если файла .gitattributes нет — Git по старинке будет использовать core.autocrlf из файла конфигурации для замены символов EOL.

Если случилась беда

Все-таки это произошло — в репозиторий попали CRLF файлы. Проверить это можно с помощью команды

$ git ls-files --eol
i/crlf  w/crlf  attr/                   file-crlf-one.txt
i/crlf  w/crlf  attr/                   file-crlf-two.txt
i/lf    w/lf    attr/                   file-lf-one.txt
i/lf    w/lf    attr/                   file-lf-two.txt

Первая колонка — окончания строк в репозитории, вторая колонка — окончания строк в рабочей директории. Такая команда может выдать несколько тысяч строк, а нам интересно — есть ли вообще в репозитории такие файлы, так что нужен фильтр.

$ git ls-files --eol | grep "i/crlf"
i/crlf  w/crlf  attr/                   file-crlf-one.txt
i/crlf  w/crlf  attr/                   file-crlf-two.txt

Давайте наведем порядок — создадим файл .gitattributes, добавим его в репозиторий, выполним команду нормализации EOL в репозитории.

*   text=auto

$ git add .gitattributes
$ git commit -m "Add .gitattributes"
[master 347c98e] Add .gitattributes
 1 file changed, 1 insertion(+)
 create mode 100644 .gitattributes

$ git add --renormalize .

$ git status
On branch master
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
        modified:   file-crlf-one.txt
        modified:   file-crlf-two.txt
$ git commit -m "Normalize eol"
[master e54c4b7] Normalize eol
 2 files changed, 4 insertions(+), 4 deletions(-)

Смотрим, что у нас теперь в репозитории — все хорошо, все окончания строк сейчас LF:

$ git ls-files --eol
i/none  w/none  attr/text=auto          .gitattributes
i/lf    w/crlf  attr/text=auto          file-crlf-one.txt
i/lf    w/crlf  attr/text=auto          file-crlf-two.txt
i/lf    w/lf    attr/text=auto          file-lf-one.txt
i/lf    w/lf    attr/text=auto          file-lf-two.txt

Теперь надо заменить файлы в рабочей директории, для этого выполняем две команды:

$ git rm --cached -r .
rm '.gitattributes'
rm 'file-crlf-one.txt'
rm 'file-crlf-two.txt'
rm 'file-lf-one.txt'
rm 'file-lf-two.txt'
$ git reset --hard
HEAD is now at e54c4b7 Normalize eol

Смотрим, что у нас теперь в рабочей директории (у меня Windows и core.eol=native):

$ git ls-files --eol
i/none  w/none  attr/text=auto          .gitattributes
i/lf    w/crlf  attr/text=auto          file-crlf-one.txt
i/lf    w/crlf  attr/text=auto          file-crlf-two.txt
i/lf    w/crlf  attr/text=auto          file-lf-one.txt
i/lf    w/crlf  attr/text=auto          file-lf-two.txt

Дополнительно

• Mind the End of Your Line
• Normalizing Line Endings in Git

Поиск:
Git • Linux • Web-разработка • Windows • Конфигурация • Настройка • EOL • CRLF • LF • Файл • IDE