Установка, настройки и первый осмысленный коммит

Чтобы запись можно было понять позже

Вы подготовили файл и хотите сохранить его. Git просит имя и email. Эти поля объясняют, кто создал запись; они не выполняют вход на GitHub и не доказывают личность автора. В лабораториях используйте учебное имя и learner@example.invalid. Никакие настоящие пароли или токены в настройках автора не нужны.

Начните с git --version. Если команда не найдена, установите Git по официальной странице, откройте новый терминал и повторите проверку. Для команд этого курса нужен Git 2.28 или новее. На Windows выполняйте примеры в Git Bash: синтаксис mktemp, переменных и перенаправлений здесь не рассчитан на PowerShell. Умение открыть папку и отредактировать текст достаточно для старта; знания Go не требуются.

Где действуют настройки

Настройка без --global внутри репозитория относится к этому репозиторию. --global меняет предпочтения пользователя для многих проектов. В учебных примерах мы выбираем локальную область, чтобы не заменять ваши реальные имя, email и другие привычки. git config --show-origin --get user.email показывает значение вместе с источником; это помогает понять, почему отображается неожиданная настройка. Области конфигурации описаны в руководстве Git.

git init -b main создаёт репозиторий с начальной веткой main. Название main — принятое нами соглашение, а не специальная команда или единственная допустимая ветка. До первого коммита ветка ещё не указывает на существующий снимок. Поэтому запросы вроде git show HEAD пока не могут показать историю.

Коммит должен обозначать законченное изменение, которое можно объяснить. Для текста это может быть добавление инструкции запуска, для программы — исправление одного поведения вместе с проверкой. Сообщение «changes» не объясняет причину. «Document queue capacity» связывает запись с конкретным правилом. Нельзя добиться хорошей истории только форматом сообщения: содержимое тоже должно быть согласованным.

Создайте репозиторий с двумя файлами

lab=$(mktemp -d "${TMPDIR:-/tmp}/git-02.XXXXXX")
cd "$lab"
git init -b main
git config user.name "Учебный автор"
git config user.email "learner@example.invalid"
git config commit.gpgsign false
printf 'Background jobs\n' > README.txt
printf 'queue=16\nworkers=2\n' > config.example
git status --short
git add README.txt config.example
git diff --cached
git commit -m "Add service description and example settings"
git status --short
git log -1 --format='%h %s'

Перед commit оба файла подготовлены. После commit короткий status пуст: рабочие файлы, индекс и последний снимок согласованы. В log видна одна запись с вашим сообщением. Пустой вывод status означает отсутствие перечисляемых изменений, а не отсутствие файлов вообще.

Мы передаём сообщение через -m, чтобы редактор не открылся неожиданно. В реальной работе можно вызвать commit без этой опции и написать несколько абзацев в настроенном редакторе. Если всё-таки открыт терминальный редактор, остановитесь и прочитайте его подсказки; не печатайте следующую shell-команду в окно сообщения. Команда продолжится после сохранения или отмены редактирования.

Теперь измените только README и выполните git commit -m "Update description" без add. Git сообщит, что изменения не подготовлены; новая запись не появится. Это ожидаемая защита границы индекса. Сначала посмотрите diff, затем добавьте нужный файл и сохраните его. Не заменяйте этот опыт механическим git add .: вам нужно видеть выбранный набор.

Проверьте сообщение фактическим снимком

Автор назвал запись «Добавить инструкцию запуска», но в cached diff находятся инструкция, изменение лимита и удаление примера. Стоит ли просто уточнить заголовок? Возможно, это три независимых решения, которые нужно подготовить отдельно. Сначала спросите, можно ли проверить и при необходимости отменить каждое без остальных. Для тесно связанных описания и примера один коммит разумен; для случайной правки лимита может понадобиться отдельная запись. Единого обязательного размера коммита в строках нет. Попробуйте дать каждому своему снимку короткое объяснение без слова «и», затем проверьте, не разорвали ли вы этим необходимую связь файлов. Это упражнение учит выбирать содержание до сохранения.

Самостоятельная лаборатория

Выделите 25–40 минут. В новой временной папке создайте README с целью проекта, пример конфигурации и заметку с вопросами. Сделайте первый коммит только с целью. Во втором добавьте конфигурацию, оставив заметку untracked. В третьем исправьте одну ошибку формулировки, не смешивая её с новым правилом.

Перед каждым commit запишите ожидаемые пути и число изменённых строк. Сравните их с git diff --cached --stat. Если обнаружили лишний файл, пока не сохраняйте его: способы убрать путь из индекса будут разобраны в главе об отмене. Для этой лаборатории проще начать отдельный опыт с правильно выбранными add, чем применять незнакомую разрушительную команду.

Критерии готовности

В истории три понятные записи. Заметка не попала ни в одну. Локальная настройка автора указывает на учебные данные. Вы можете повторить работу в новой папке без готового списка команд и объяснить, почему commit отказался сохранять неподготовленное изменение. Проверка успешного exit code полезна, но её недостаточно без чтения подготовленного diff.

Разбор

Первый снимок содержит только README, второй добавляет пример, третий меняет одну формулировку. Если все файлы оказались в первой записи, add выбрал больше, чем вы планировали. Если commit просит автора, проверьте, находитесь ли вы внутри правильного репозитория и где задана настройка. Если вмешалась подпись или hook из личных настроек, прочитайте ошибку; лабораторный commit.gpgsign false отключает требование подписи только здесь.

Git сохраняет файлы, но не пустые папки как самостоятельные объекты. Создание пустого каталога не даст новой записи status. Не нужно придумывать «потерю данных», если в нём пока ничего нет.

Следующая глава научит читать изменения и историю. Первичные источники для действий: git init, git commit. Последовательность от установки к повседневной записи сопоставлена с оглавлением Pro Git, но лаборатория и критерии здесь самостоятельные.