Установка Git на Windows, macOS и Linux и первая настройка

[Pavel_Git]

Зачем вообще этот урок и какую боль он снимает

Кажется, что установить Git - дело на две минуты: скачать, прокликать, готово. Но именно на этом шаге рождается половина будущих страданий. Установил с дефолтами - и через неделю ловишь дикие диффы, где "изменился весь файл" хотя ты поправил одну строку. Сделал первый коммит - а он подписан непонятным именем вроде DESKTOP-7F3K2\Admin, и теперь твоя история навсегда замусорена. Создал репозиторий - а ветка называется master, хотя весь проект на main, и push улетает не туда.

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



Установить Git: Windows, macOS, Linux

Git - это не одна программа, а набор утилит плюс библиотека. На разных системах его удобнее ставить разными способами. Разберем по очереди.

Windows. Тут нужно скачать дистрибутив Git for Windows с сайта git-scm.com (раздел Downloads). Это не "официальный Git от компании Git" - такой компании нет, Git разрабатывает сообщество. Git for Windows - это сборка, которая тащит за собой не только сам git.exe, но и целое мини-окружение в стиле Unix. Что туда входит:

• сам Git;
• Git Bash - терминал с эмуляцией bash и набором юниксовых утилит (ls, grep, ssh, curl). Это важно: в Windows нет родного bash, а почти вся документация Git и туториалы написаны под него. Git Bash дает тебе ту же командную строку, что у коллег на маке и линуксе;
• Git GUI и графический просмотрщик истории gitk (legacy, но работают);
• интеграцию в проводник (пункты "Git Bash Here" по правому клику);
• credential manager для хранения паролей и токенов.

При установке инсталлятор задает кучу вопросов. Два из них реально важны. Первый - выбор редактора по умолчанию (по дефолту предлагают Vim, новичку лучше выбрать в списке "Notepad" или, если стоит, VS Code - чтобы не залипнуть в виме при первом же коммите). Второй - "Configuring the line ending conversions". Там по умолчанию стоит вариант "Checkout Windows-style, commit Unix-style" - это и есть пресловутый core.autocrlf=true, к которому мы еще вернемся и который в 2026 году уже не считается лучшим выбором. Остальное можно смело оставлять как есть.

После установки открываешь Git Bash (или обычный PowerShell - git.exe доступен и там) и проверяешь:

Код: Выделить всё

$ git --version
git version 2.54.0.windows.1

Видишь версию - значит Git в PATH и готов к работе. Суффикс windows.1 - это номер сборки Git for Windows поверх апстрима 2.54.0.

macOS. Тут два пути. Простой - поставить инструменты разработчика Apple, в которые входит Git:

Код: Выделить всё

$ xcode-select --install

Выскочит окошко, согласишься, оно поставит Command Line Tools, и git появится. Минус: Apple обновляет свою сборку Git лениво, она часто отстает на несколько версий. Поэтому правильный путь для разработчика - менеджер пакетов Homebrew:

Код: Выделить всё

$ brew install git
$ git --version
git version 2.54.0

Brew всегда тянет свежий апстрим. Тонкость: после установки в shell может остаться кэш старого пути к бинарнику. Если git --version упрямо показывает старую эпловскую версию, проверь, что в PATH каталог Homebrew (/opt/homebrew/bin на Apple Silicon) идет раньше /usr/bin. Команда which -a git покажет все найденные бинарники по порядку.

Linux. Тут все зависит от дистрибутива и его пакетного менеджера. Никаких инсталляторов - одна строка в терминале:

Код: Выделить всё

# Debian, Ubuntu, Mint
$ sudo apt update && sudo apt install git

# Fedora, RHEL, Rocky, Alma
$ sudo dnf install git

# Arch, Manjaro
$ sudo pacman -S git

Дистрибутивные репозитории иногда отстают от апстрима, но для большинства задач это некритично - бери из пакетов. Если нужна именно последняя версия, ставят из PPA (на Ubuntu это ppa:git-core/ppa) или собирают из исходников, но новичку это не требуется. Проверка - та же git --version.

Где Git хранит настройки: три уровня system, global, local

Прежде чем настраивать, надо понять модель. Любая настройка Git живет в одном из трех текстовых файлов, и они образуют иерархию по приоритету. Это и есть ответ на вопрос "почему моя настройка не применилась" - ее перебил файл уровнем ниже.

• system - один файл на всю машину, для всех пользователей. Лежит обычно в /etc/gitconfig (на Windows внутри каталога установки Git). Правится с флагом --system и требует прав администратора. Трогают редко.
• global - твой личный конфиг, один на пользователя. Файл ~/.gitconfig (или ~/.config/git/config). Флаг --global. Сюда идет 99% твоей ручной настройки: имя, почта, редактор, алиасы.
• local - конфиг конкретного репозитория. Файл .git/config внутри проекта. Флаг --local или просто без флага, если ты стоишь внутри репо. Перебивает global. Сюда кладут то, что специфично для одного проекта - например, рабочую почту для рабочего репо, когда личная стоит в global.

Правило простое: более узкий уровень побеждает более широкий. local перебивает global, global перебивает system. Увидеть итоговую картину с указанием, откуда какое значение пришло, можно так:

Код: Выделить всё

$ git config --list --show-origin
file:/etc/gitconfig         core.autocrlf=input
file:/home/user/.gitconfig  user.name=Ivan Petrov
file:/home/user/.gitconfig  user.email=ivan@example.com
file:.git/config            user.email=ivan@work-corp.com

Тут видно главное: user.email задан и в global, и в local. Победит local - то есть в этом репо коммиты пойдут с рабочей почтой ivan@work-corp.com, хотя глобально стоит личная. Это рабочая лошадка для тех, кто мешает личные и корпоративные проекты на одной машине. Файлы - обычный текст в INI-подобном формате, их можно открыть и поправить руками, но через команду git config надежнее: меньше шансов сломать синтаксис.

Настройка Git: имя, почта, редактор

Минимум, без которого Git будет ругаться на каждый коммит, - представиться. Имя и почта вшиваются в каждый коммит как авторство, это не логин и не пароль, а просто подпись в истории. Ставим глобально:

Код: Выделить всё

$ git config --global user.name "Ivan Petrov"
$ git config --global user.email "ivan@example.com"

Почту ставь ту же, что привязана к твоему аккаунту на GitHub/GitLab, - иначе твои коммиты не свяжутся с профилем и не зачтутся в статистику. Имя пиши человеческое, латиницей или кириллицей - как хочешь видеть его в истории навсегда. Поменять задним числом уже сделанные коммиты можно, но это переписывание истории - отдельная больная тема, лучше сразу настроить правильно.

Дальше - редактор. Git открывает его, когда тебе надо написать сообщение коммита, разрешить конфликт или отредактировать список при интерактивном rebase. По умолчанию на Unix это часто Vim, и новичок, не зная как из него выйти (:q!, кстати), впадает в панику. Ставим что-то привычное:

Код: Выделить всё

# VS Code (флаг --wait обязателен, иначе Git решит, что ты закрыл редактор мгновенно)
$ git config --global core.editor "code --wait"

# Nano - простой консольный, есть почти везде
$ git config --global core.editor "nano"

Проверить любое значение поштучно:

Код: Выделить всё

$ git config --global core.editor
code --wait

Ветка по умолчанию: почему в 2026 ставим main вручную

А вот тут - самый частый источник путаницы, и здесь интернет массово устарел. Когда ты делаешь git init, Git создает первую ветку. Долгое время она называлась master. Сообщество движется к main, и многие думают, что Git уже сам так делает. Это неправда для ванильного Git в 2026 году. Чистый Git серии 2.54 по-прежнему создает ветку master и при этом печатает предупреждение:

Код: Выделить всё

$ git init demo
hint: Using 'master' as the name for the initial branch. This default branch name
hint: is subject to change. To configure the initial branch name to use in all
hint: of your new repositories, which will suppress this warning, call:
hint:
hint:   git config --global init.defaultBranch <name>
...
Initialized empty Git repository in /home/user/demo/.git/

Git сам подсказывает решение. Встроенным дефолтом main станет только в Git 3.0 (ожидается в конце 2026), а до тех пор - ставим руками раз и навсегда:

Код: Выделить всё

$ git config --global init.defaultBranch main

Теперь каждый новый git init будет создавать ветку main, и hint исчезнет. Учти: эта настройка влияет только на новые репозитории. Уже существующие репо не переименуются - там ветку придется переименовывать отдельной командой (git branch -m), это другой разговор. И еще: когда ты клонируешь чужой репозиторий, имя главной ветки берется из него, а не из твоего init.defaultBranch. Так что эта настройка - про твои собственные новые проекты.

Удобства: color.ui и help.autocorrect

Пара мелочей, которые делают жизнь приятнее. Цветной вывод (зеленые добавления, красные удаления в диффах) в современном Git включен в режиме auto по умолчанию, но если вывод вдруг черно-белый, можно задать явно:

Код: Выделить всё

$ git config --global color.ui auto

И автокоррекция опечаток в командах. По умолчанию выключена. Если включить, Git будет угадывать, что ты имел в виду, когда промахнулся по клавишам:

Код: Выделить всё

$ git config --global help.autocorrect 20

$ git stauts
WARNING: You called a Git command named 'stauts', which does not exist.
Continuing in 2.0 seconds, assuming that you meant 'status'.

Значение - десятые доли секунды задержки перед автозапуском. 20 значит "подожди 2 секунды и выполни исправленную команду". Если поставить help.autocorrect immediate - запустит мгновенно без паузы; prompt - спросит подтверждение. Удобно, но новичку советую prompt: будешь видеть, что именно Git собрался запустить, и не словишь сюрприз.

Окончания строк: core.autocrlf и почему в 2026 лучше .gitattributes

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

Классическое лечение - core.autocrlf. На Windows ставят true (при коммите CRLF превращается в LF, при выгрузке обратно в CRLF), на macOS/Linux - input (только при коммите CRLF режется в LF, обратного преобразования нет):

Код: Выделить всё

# Windows
$ git config --global core.autocrlf true

# macOS, Linux
$ git config --global core.autocrlf input

Но честно: в 2026 году это уступающий подход. Проблема autocrlf в том, что это личная настройка каждого разработчика, и если кто-то ее не выставил или выставил иначе - беда возвращается. Современная best practice - не полагаться на конфиг каждого, а зафиксировать политику окончаний строк в самом репозитории через файл .gitattributes с правилом text=auto. Тогда правила едины для всей команды независимо от их личных настроек, и лежат они под версионным контролем. Подробно .gitattributes мы разберем в отдельном уроке - пока просто запомни: autocrlf тебя выручит на одиночной машине, но командное решение - это .gitattributes.

SSH-ключ и credential helper - коротко

Чтобы push/pull на GitHub/GitLab не спрашивал пароль каждый раз, есть два пути. Первый - SSH-ключ. Генерируешь пару ключей, публичную половину добавляешь в настройки своего аккаунта на хостинге:

Код: Выделить всё

$ ssh-keygen -t ed25519 -C "ivan@example.com"

Тип ed25519 - современный, короткий и быстрый, бери его, а не старый rsa. Дальше копируешь содержимое ~/.ssh/id_ed25519.pub в веб-интерфейс хостинга (Settings - SSH keys). Второй путь - работа по HTTPS с токеном, и тогда удобно, чтобы Git запоминал учетные данные через credential helper:

Код: Выделить всё

$ git config --global credential.helper store

helper store кладет токен в файл (просто, но в открытом виде - на личной машине ок, на чужой нельзя). На Windows и macOS лучше системные хранилища: manager (встроен в Git for Windows, шифрует) и osxkeychain (связка ключей macOS). Глубоко аутентификацию разберем позже - сейчас задача просто знать, что эти механизмы есть.

Типичные грабли

• Забыл user.email - и коммиты "ничьи". Git подставит автоопределенную почту вида user@hostname, и на хостинге коммиты не привяжутся к профилю. Всегда проверяй git config user.email перед первым коммитом в новом окружении.
• Настройка "не работает", потому что ее перебивает local. Поставил почту в global, а в репо коммиты идут с другой - значит в .git/config есть свой user.email. Диагностика - git config --list --show-origin.
• Ждал main, получил master. Не выставил init.defaultBranch=main и думал, что Git сам. Нет, ванильный Git 2.54 этого не делает - main будет дефолтом только с 3.0.
• code --wait без --wait. Без флага --wait Git думает, что редактор закрылся сразу, и берет пустое сообщение. Коммит срывается или уходит пустым.
• Правил ~/.gitconfig руками и сломал синтаксис. Лишняя скобка в имени секции - и Git перестает читать весь файл. Безопаснее через git config.

Мини-лаба: настрой Git с нуля за 5 минут
Повтори руками по шагам в своем терминале:

• Проверь установку: git --version. Если команды нет - поставь Git способом для своей ОС из этого урока.
• Представься: git config --global user.name "Твое Имя" и git config --global user.email "твоя@почта".
• Поставь main дефолтом: git config --global init.defaultBranch main.
• Задай редактор: git config --global core.editor "nano" (или "code --wait").
• Включи автокоррекцию мягко: git config --global help.autocorrect prompt.
• Посмотри весь конфиг с источниками: git config --list --show-origin. Найди свои строки.
• Создай тестовый репо: git init lab-test и зайди в него. Убедись, что ветка называется main: git branch --show-current.
• Поставь в этом репо отдельную почту: git config user.email "local@test.com" (без --global!) и снова посмотри git config --show-origin user.email - увидишь, что значение взято из .git/config, а не из ~/.gitconfig.

Контрольные вопросы

• Какие три уровня конфигурации есть у Git, в каких файлах они лежат и кто кого перебивает?
• Почему в 2026 году после git init без настройки ты получаешь ветку master, а не main, и как это исправить раз и навсегда?
• Чем core.autocrlf уступает подходу через .gitattributes для команды?
• Зачем редактору VS Code нужен флаг --wait в core.editor?

Итог
Ты поставил Git под свою ОС, проверил версию и сделал базовую настройку, которую профи прописывают один раз на новой машине: имя, почта, редактор, main как ветка по умолчанию, удобства вроде автокоррекции. Главное, что ты теперь понимаешь модель трех уровней system/global/local и можешь диагностировать "почему настройка не применилась" через --show-origin. Это фундамент - дальше будем делать первые коммиты, и благодаря этой настройке твоя история сразу будет чистой и подписанной правильно.

[deepheap]

Спасибо, наконец понял почему у меня в global стоит main, а в рабочем репо все равно вылазит master - там в .git/config своя ветка осталась от клона. show-origin все показал.

[fpgamaker]

А help.autocorrect immediate безопасно ставить? боюсь что он мне reset --hard запустит вместо чего-то безобидного пока я думаю