Меняем файл и делаем второй коммит

Один коммит — это начало, но настоящая ценность контроля версий проявляется, когда версий несколько и между ними можно увидеть разницу. В этом уроке мы изменим файл из прошлого урока, посмотрим, что именно поменялось, сделаем второй коммит и прочитаем историю из двух версий. Никакой новой теории — закрепляем цикл «изменил -> add -> commit» и добавляем одну новую команду: git diff.

Продолжаем в той же папке:

cd ~/git-sandbox/my-first-repo
git status

Ожидаемый вывод (с прошлого урока всё сохранено):

On branch main
nothing to commit, working tree clean

working tree clean — несохранённых изменений нет. Хорошая отправная точка.

Шаг 1. Меняем файл

Допишем строку в наш README.md. Двойная угловая скобка >> добавляет текст в конец файла, не стирая то, что было:

echo "Учебный проект для курса Git." >> README.md

Теперь спросим Git, что изменилось:

git status

Ожидаемый вывод:

On branch main
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
	modified:   README.md

no changes added to commit but untracked files present (use "git add" to track)

Ключевое слово теперь modified (изменён), а не «untracked», как было с новым файлом. Разница важная: Git уже знает этот файл (мы коммитили его раньше) и заметил, что внутри что-то поменялось. Раздел называется Changes not staged for commit — изменения есть, но к коммиту они ещё не подготовлены.

Шаг 2. git diff — что именно изменилось

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

git diff

Ожидаемый вывод:

diff --git a/README.md b/README.md
index 1d2e3f4..5a6b7c8 100644
--- a/README.md
+++ b/README.md
@@ -1 +1,2 @@
 # Мой первый проект
+Учебный проект для курса Git.

Главное здесь — последние строки. Строка, начинающаяся с пробела, не менялась. Строка со знаком + в начале — добавлена. Если бы вы что-то удалили, перед строкой стоял бы знак -. Вот и весь ответ на вопрос «что я тут поменял» — без открывания двух файлов рядом и сравнивания глазами. Git нашёл разницу за вас.

tip Верхние строки вывода (index 1d2e..., @@ -1 +1,2 @@) — служебные: они говорят Git, к какому месту файла относятся изменения. Сейчас их можно не читать. Смотрите на строки с + и - — это и есть смысл.

Шаг 3. Второй коммит — повторяем цикл

Изменение нас устраивает — сохраняем его. Тот же ритм, что и в прошлом уроке: сначала add, потом commit.

git add README.md
git commit -m "Добавил описание проекта в README"

Ожидаемый вывод:

[main 4b5c6d7] Добавил описание проекта в README
 1 file changed, 1 insertion(+)

Заметьте: на этот раз нет пометки (root-commit) — это уже не первый коммит, у истории появилось продолжение. После коммита git diff снова ничего не покажет (выведет пустоту), потому что несохранённых изменений больше нет: всё, что было в рабочем файле, теперь зафиксировано.

git status

Ожидаемый вывод:

On branch main
nothing to commit, working tree clean

Шаг 4. Читаем историю из двух версий

Теперь в истории два коммита. Посмотрим компактно:

git log --oneline

Ожидаемый вывод:

4b5c6d7 (HEAD -> main) Добавил описание проекта в README
9f2a3c1 Первый коммит: добавил README

Читается сверху вниз — от свежего к старому. Самый новый коммит наверху, помечен HEAD -> main (грубо говоря, «вы сейчас здесь»). Под ним — наш первый коммит. У каждого свой короткий идентификатор и своё сообщение. Это и есть история проекта: цепочка подписанных версий, по которой видно, что и когда менялось.

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

git log -p

Она покажет тот же список коммитов, но под каждым — его diff (что именно поменялось). Для двух коммитов это удобно; нажмите q, чтобы выйти из просмотра.

Что вы умеете теперь

Вы дважды прошли цикл Git и впервые увидели разницу между версиями:

• меняете файл -> git status показывает modified;
• git diff показывает построчную разницу (+ добавлено, - удалено);
• git add -> git commit -m "..." сохраняет новую версию;
• git log --oneline показывает всю историю как список коммитов.

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

Мостик: что дальше

Возможно, у вас накопились вопросы, которые мы намеренно отложили:

• Что это за набор символов вроде 9f2a3c1 у каждого коммита и откуда он берётся?
• Git каждый раз сохраняет файл целиком или только разницу? Что именно лежит в папке .git?
• Как отправить коммиты на GitHub, чтобы они не пропали вместе с ноутбуком, и при чём тут SSH-ключи?

Все эти вопросы законные — и на все будут ответы. Но отвечать на них сейчас было бы рано: чтобы понять, как Git хранит коммиты (это называется снимки, snapshots) и откуда берётся идентификатор (его считает хеш-функция), сначала нужна вот эта самая практика, которую вы только что прошли. А связь с удалёнными серверами и настройка SSH — это вообще отдельная большая тема, к которой мы вернёмся, когда базовый цикл станет привычным.

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

Попробуй сам

Закрепите цикл самостоятельно, без подсказок по командам:

1. Создайте в репозитории новый файл notes.txt с любой строкой.
2. Посмотрите git status — в каком он разделе и почему именно в этом?
3. Добавьте его и закоммитьте с осмысленным сообщением.
4. Измените README.md ещё раз, посмотрите git diff перед коммитом.
5. Сделайте коммит и выведите git log --oneline — у вас должно быть четыре коммита.

Если все четыре коммита на месте и каждый с понятным сообщением — вы освоили базовый цикл Git. Дальше будет только интереснее.