Как начать работать с Git: сохранять изменения и восстанавливать файлы

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

Что должно получиться

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

Начните с копии папки, в которой нет паролей и личных данных. Откройте её в редакторе, а терминал — именно в этой папке. Команда git --version проверяет доступность Git. Если система не распознаёт команду, сначала установите Git из официального источника для своей системы и заново откройте терминал.

Git хранит историю локально. Учётная запись на GitHub для этого упражнения не нужна. Отправка истории на внешний сервер — отдельное действие: создание коммита само по себе ничего не публикует в интернете. И наоборот, наличие локальной истории не спасёт от потери единственного диска.

Из чего это складывается

Индекс помогает выбрать состав сохранения. В первом упражнении выбирайте целые файлы, чтобы не усложнять работу отбором отдельных строк.

После git add Git берёт содержимое файла в индекс на этот момент. Если затем продолжить редактирование, новые правки автоматически в индекс не попадут. Поэтому один файл может одновременно значиться подготовленным и изменённым: в нём уже есть выбранная версия и появились дополнительные правки.

Как это сделать по шагам

1. Проверьте папку. Убедитесь, что терминал открыт в учебном проекте. Просмотрите файлы, уберите из упражнения секреты и данные пользователей. Сохраните документ в редакторе, иначе Git не увидит ещё не записанный на диск текст.
2. Создайте репозиторий. Выполните git init. В обычной локальной папке появится служебный каталог .git. Первый коммит ещё не создан. Имя начальной ветки зависит от настроек, поэтому смотрите фактическое имя, а не подставляйте его из чужого примера.
3. Прочитайте состояние. Выполните git status. Найдите учебный файл. Далее пример использует index.html: заменяйте это имя своим фактическим путём, если файл называется иначе.
4. Подготовьте файл. Выполните git add — index.html. Так вы явно выбираете один файл. Пока не используйте добавление всей папки: сначала научитесь понимать состав будущего коммита.
5. Проверьте выбранное содержимое. Выполните git diff --staged. Просмотрите изменения, которые попадут в сохранение. В новом репозитории здесь будет видно содержимое добавляемого файла.
6. Создайте коммит. Выполните git commit -m 'Добавлена учебная страница'. Если Git сообщает, что не определены имя и адрес автора, задайте свои данные для этого репозитория и повторите сохранение. Не копируйте чужую личность из примера.
7. Проверьте историю. Выполните git log --oneline, затем git status. Найдите своё сообщение. Убедитесь, что оставшиеся изменения понятны. Чистый статус не исключает наличия игнорируемых файлов.
8. Повторите цикл на маленькой правке. Измените текст страницы, сохраните файл, посмотрите git diff, снова подготовьте файл и создайте отдельный коммит с описанием новой правки.

Для имени и адреса автора служат настройки user.name и user.email. Внутри репозитория выполните git config --local user.name 'ВАШЕ ИМЯ' и git config --local user.email 'ВАШ EMAIL'. Вместо значений в кавычках подставьте свои данные, которые согласны видеть в истории проекта. Эти данные не являются паролем и сами по себе не дают доступ к внешнему сервису.

Как читать состояние перед сохранением

Команда git status отвечает на вопрос, что происходит с файлами. Команда git diff без дополнительных параметров показывает разницу между рабочими файлами и индексом. Она не заменяет просмотр подготовленного содержимого: для него нужен git diff --staged.

Например, вы заменили подпись кнопки, выполнили git add, затем исправили опечатку в том же файле. Обычный git diff покажет последнюю опечатку, а git diff --staged — ранее выбранную замену подписи. Если хотите сохранить обе правки вместе, снова выполните git add для этого файла и перечитайте подготовленную разницу.

Пустой вывод git diff не доказывает, что в репозитории нет изменений. Всё может быть уже подготовлено к коммиту. Неотслеживаемые файлы тоже не показываются обычной разницей как полный набор их строк. Сопоставляйте результат с git status.

Сообщение коммита описывает законченную правку: «Исправлена ссылка в подвале» понятнее, чем «Ещё изменения». Разнородные правки в одном сохранении усложняют последующую проверку. Делите работу по смыслу, а не по количеству нажатий сохранения.

Как убрать файл из будущего коммита

Если в репозитории уже есть коммит, команда git restore --staged — index.html возвращает запись файла в индексе к состоянию HEAD. Рабочий файл остаётся на диске с вашими правками. Это способ снять подготовку, когда вы выбрали лишнее, но ещё хотите продолжать редактирование.

После команды снова выполните git status и git diff. Проверьте, что файл больше не находится среди выбранных изменений, а его текст сохранился. Если файл был впервые добавлен после последнего коммита, он станет неотслеживаемым: это тоже ожидаемый результат снятия подготовки.

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

Как вернуть содержимое файла из коммита

Восстановление заменяет содержимое. Перед ним прочитайте разницу и отдельно сохраните правки, которые хотите оставить. Для первого опыта используйте файл, уже входящий в последний коммит, и убедитесь, что для него нет подготовленных изменений. Внесите заведомо ненужную учебную правку и посмотрите git diff.

Команда git restore --source=HEAD — index.html вернёт рабочий файл к содержимому последнего коммита. Неподготовленная правка этого файла будет потеряна. Остальные файлы команда не должна затрагивать, потому что вы явно указали путь. После выполнения откройте документ и проверьте git status.

У обычного git restore — index.html источник по умолчанию другой — индекс. Если там лежит подготовленная версия, восстановится именно она, а не обязательно последний коммит. Явное --source=HEAD в учебном примере помогает не смешивать эти два состояния.

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

Восстановление одного документа не означает, что весь проект перешёл в прошлое. Рядом могут остаться новые стили, настройки или зависимости, несовместимые со старым файлом. Проверяйте страницу после такой операции. Для полного возврата выпуска нужен отдельный план с учётом данных и окружения.

Что не стоит включать в историю

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

Правила .gitignore помогают не замечать выбранные неотслеживаемые файлы и папки. Они не убирают уже отслеживаемый файл из истории и не делают ранее опубликованный секрет безопасным. Состав правил зависит от проекта: то, что является временным результатом сборки в одном случае, в другом может быть необходимым исходником.

Если секрет уже попал в общий репозиторий, удаления строки в новом коммите недостаточно: она может остаться в предыдущих снимках. Сначала заменяют сам скомпрометированный секрет в соответствующем сервисе, затем отдельно решают вопрос очистки истории и доступов. Это выходит за рамки первого упражнения.

Частые ошибки

• Создать репозиторий не в той папке. Тогда в область работы попадают соседние документы или вообще весь домашний каталог. Перед git init проверяйте местоположение терминала.
• Считать git add окончательным сохранением. Индекс только подготавливает состояние. В истории оно появляется после успешного коммита.
• Повторно отредактировать файл и забыть про индекс. Коммит сохранит ранее выбранную версию. Читайте подготовленную разницу перед каждой записью.
• Применять восстановление ради чистого статуса. Чистота отчёта не важнее нужных правок. Сначала разберитесь, откуда они взялись и что хотите сохранить.
• Считать репозиторий полной копией сайта. База данных, внешнее хранилище, письма и настройки сервера могут в него не входить. Их сохранность проверяют отдельно.

Как проверить

• Git работает в нужной учебной папке, а не в каталоге с посторонними файлами.
• Вы различаете рабочее содержимое, индекс и записанный коммит.
• В истории видны осмысленные сообщения, которые соответствуют сделанным правкам.
• Перед записью вы просматриваете git diff --staged и понимаете состав сохранения.
• Снятие подготовки сохраняет рабочий текст, а восстановление файла выполняется только после проверки нужных изменений.
• Секреты и личные документы не добавлены; отдельная резервная копия существует там, где она нужна.
• После восстановления файл открыт и проверен в составе проекта.

Для учебного проекта подойдут первая страница на HTML и подключение CSS. Историю кода дополняет журнал изменений сайта. Если требуется помощь с проектом, задачи для исполнителя можно разместить в разделе Разработка.

Вопросы и ответы

Можно ли пользоваться Git без GitHub?

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

Почему сохранённый в редакторе файл ещё не виден в истории?

Редактор записывает файл на диск. Чтобы новая версия попала в историю Git, нужно выбрать изменения через индекс и успешно создать коммит. Проверьте состояние: возможно, файл ещё не подготовлен или после подготовки вы продолжили редактирование.

Почему git diff ничего не показывает, хотя файл изменён?

Изменение могло уже попасть в индекс. Посмотрите git status и git diff --staged. Обычная разница сравнивает рабочую версию с индексом и не показывает все возможные состояния одним отчётом.

Можно ли снять подготовку и оставить правки?

В репозитории с существующим коммитом для этого подходит git restore --staged с явно указанным путём. Затем проверьте статус и сам файл. Снятие подготовки отличается от замены рабочего содержимого при восстановлении.

Вернёт ли Git файл, который я никогда не добавлял?

История коммитов не содержит файл, который в неё не входил. Для такого документа ищите отдельную копию, историю редактора или средства восстановления системы. Не рассчитывайте на репозиторий как на сохранение всего содержимого диска.

Нужно ли запоминать все команды сразу?

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

Git заменяет резервное копирование сайта?

Нет. История исходников не равна копии базы данных, пользовательских загрузок и серверного окружения. Держите отдельный план резервного копирования и проверяйте восстановление тех частей сайта, которые не входят в репозиторий.