Git – базовые команды. Конспект. Практика с github.

Я уже несколько лет работаю разработчиком на Java, но за это время ни разу не работал в команде, поэтому всё время забываю некоторые команды гита. Чтобы их постоянно не гуглить, решил собрать все основные в конспекте.

Гит – система контроля версий, которая позволяет хранить версии кода вашего приложения. Так сказать, записывает информацию об эволюции проекта и позволяет легко откатиться к прошлой версии. Её аналогом можно считать создание нескольких папок и файлов на компьютере, типа code-final-version.java или code-now-final-version-for-sure.java.

Именно так я использую гит и github в своих проектах: как хранилище информации, трекер продуктивности (гитхаб ещё и подсвечивает особо активные дни зелёным на календаре). Но настоящая сила Git раскрывается в командной работе: общий удалённый репозиторий для нескольких разработчиков, которые могут работать параллельно в разных ветках, а потом удобно объединять изменения – всё это делает совместную разработку предсказуемой и управляемой.

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

Для начала я создал папку в проводнике и добавил туда один (пока пустой) текстовый файл. Нужно в командной строке перейти в эту папку и выполнить команду для инициализации репозитория:

git init – превратить папку в репозиторий.

git clone <url> – склонировать репозиторий с GitHub.

Можно также добавить файл .gitignore, в котором описать все адреса, которые не нужно грузить в репозиторий. Обычно это библиотеки и файлы IDE – их мы не загружаем, чтобы оставить в репозитории только сам код.

Сейчас я создам второй файл ignore.txt и добавлю его в свой .gitignore. При загрузке данных этот файл проигнорируется. Но как делать загрузку?

Загрузка нового проекта в пустой репозиторий

Чтобы загрузить проект на гитхаб, нудно создать там пустой репозиторий и скопировать на него ссылку. Потом выполнить команды:

git add .
git commit -m "Initial commit"
git remote add origin <url>
git push -u origin master

origin – имя удалённого репозитория, и командой с -u (upstream) мы говорим, чтобы нужно запомнить его адрес (тогда нам не надо будет каждый раз его прописывать для каждой команды).

Таким образом у нас будет локальный репозиторий со своими ветками и кодом в них, и удалённый, и мы сможем загружать файлы туда (тут с помощью push), или выгружать оттуда на нашу машину. Как это делать, разберёмся ниже.

Три состояния файла в Git

В гите файл перемещается между тремя состояниями:

Working Directory – файлы, с которыми работаем.

Staging Area – подготовленные для коммита.

Repository – сохранённая история (на последнее сохранение – коммит указывает HEAD).

У нас таким образом есть по три копии одного файла – по одной в каждом состоянии. И мы можем или продвигать изменения дальше по этому графу, или возвращать состояние обратно.

Для добавления всех файлов с диска в staging area используем команду:

git add .

Вместо точки можно указать имя конкретного файла или сразу нескольких, например:

git add .gitignore
git add file1.txt file2.txt notes.md

Для коммита (сохранения файла из staging в историю) используем команду с указанием описания этого коммита:

git commit -m "Add .gitignore"

После -m пишем короткое сообщение, описывая коммит. Обычно описывается не в прошедшем времени – что сделали мы, а в настоящем – что исправляет или добавляет этот коммит.

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

Если нужно отправить или получить данные с локального компьютера в удалённую папку, то используем команды:

git push – отправить историю на GitHub (например туда – я работаю с ним)

git pull – забрать обновления с GitHub (например, кто-то внёс свои изменения в ваш репозиторий и вы хотите их загрузить себе) – скачиваются изменения и заменяются файлы на диске

git fetch – забрать обновления, но не перезаписывать рабочую папку на диске (то есть данные попадают пока просто в репозиторий на локальном компьютере)

Просмотр истории и состояния

git status – показывает текущее состояние репозитория

Например, если я создам новый файл, но пока не добавлю его в гит, то получу такой статус:

Untracked files:
(use "git add <file>..." to include in what will be committed)
newfile.txt
nothing added to commit but untracked files present (use "git add" to track)

Если добавлю файл с git add ., то увижу уже такое сообщение статуса:

Changes to be committed:
(use "git restore --staged <file>..." to unstage)
new file: newfile.txt

И как только его закоммичу, то получу статус:

nothing to commit, working tree clean

git log —oneline – выводит последнюю строчку лога

git diff – показывает, что изменено до add (разница между файлами на диске и staged)

git diff —staged – что изменено после add (разница между staged и HEAD)

Если я добавлю в файл строчку Hello и попрошу показать diff, то получу:

diff --git a/initial file.txt b/initial file.txt
index e69de29..b6fc4c6 100644
--- a/initial file.txt
+++ b/initial file.txt
@@ -0,0 +1 @@
+hello
\ No newline at end of file

То же сообщение получу после выполнения git add . и git diff –staged – то же самое изменение теперь сдвинулось в другое состояние.

Откат изменений

Сейчас у нас есть слово Hello в файле, которое мы пока не закоммитили (изменения есть на диске и в staged). Что если мы хотим отменить эти изменения? Помогут следующие команды:

git restore —staged <file> – убрать файл из staging зоны, но оставить его на диске, каким он был. То есть берёт данные из последнего коммита (HEAD), и заменяем ими то что мы добавили в staging зону. Обязателен адрес или точка для всех файлов.

Выполняю это, и Hello остаётся в файле, но в staging секции уже ничего нет.

git restore <file> – вернуть файл на диск. Команда переписывает файл на диске в состояние, в котором он лежит в stage, если он там есть. Если он пуст, то берёт из HEAD.

Если я сделаю это сейчас, то файл на диске станет пустым.

Но что если мы уже закоммитили изменение и хотим его отменить?

git reset —hard <commit> – откатиться полностью. Отменяет последний коммит (перемещает HEAD на прошлое изменение), переписывает файл и в stage зоне и на диске. То есть мы жёстко откатываемся во всех трёх копиях к прошлому коммиту.

git reset —soft <commit> – отменяет последний коммит (перемещает HEAD на прошлое изменение), но не переписывает файл на диске и в stage зоне. Мы можем снова закомиттить это изменение, или отменить его, используя две команды restore.

Таким образом reset —hard по эффекту эквивалентен трём командам в этой последовательности: reset —soft, restore —staged, restore.

Но reset как бы «стирает» из истории коммит. А что если мы хотим отменить изменения, но не переписывать историю? Тогда нужна такая команда:

git revert <commit> – создать «обратный» коммит

Ещё раз пробежимся по изменениям:

введём в файл Hello
Сделаем git add ., git commit -m „hello”
введём в файл World
Сделаем git add ., git commit -m „World”
Сделаем git reset —hard head~1
Получаем снова Hello и теряем упоминание World из истории. В логах будет:

commit 21fee506ce76e024ddac10f138366cc1
Author: egor-
Date: Tue Dec 9 21:29:48 2025
Hello

Теперь попробуем сделаеть revert:

Вернём в файл World
Сделаем git add ., git commit -m „World”
Сделаем git revert head
Получаем в файле снова Hello, но в логах уже есть больше коммитов:

commit 421803449a7d3cca735292223 (HEAD -> main)
Author: egor-
Date: Tue Dec 9 21:50:36 2025
Revert "World"
This reverts commit 17dcf27fbfeb658ce8ec1f243e274aadb.

commit 17dcf27fbfeb658ce8ecd2325bc1f243e274aadb
Author: egor-
Date: Tue Dec 9 21:46:18 2025
World

commit 21fee506ce76e024de10f138366cc1
Author: egor-
Date: Tue Dec 9 21:29:48 2025
Hello

Что если мы уже что-то поменяли, но хотим отменить изменения и подтянуть данные из удалённого репозитория с гитхаба? Отменяем все изменения локально, если они есть, с restore, а потом делаем pull:

git restore .
git pull

Если локально мы уже что-то комиттили, то есть локально HEAD уже продвинулась, то нужно сделать так:

git reset --hard origin/main

В этой статье разобрались с базовыми командами, посмотрели как пушить и отменять изменения. Во второй части посмотрим на ветки, merge и более продвинутые темы.