Git и GitHub — разница и основные команды

Вы клонировали репозиторий, поправили пару файлов, сделали коммит и выполнили git push — а в ответ получили ! [rejected] main -> main (fetch first). Ничего не сломалось: пока вы работали, коллега отправил свои коммиты, и ваша история разошлась с удалённой. Лечится это одной командой — git pull --rebase, а затем повторным git push. Такие сообщения перестают пугать, как только понимаешь, чем Git отличается от GitHub и что делает каждая команда.

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

Git и GitHub — в чём разница

Git создал Линус Торвальдс в 2005 году для разработки ядра Linux. Git отслеживает изменения в коде, умеет работать с ветками, объединять правки разных разработчиков, откатывать состояние проекта и делать всё это офлайн — полная история проекта лежит у вас на диске.

GitHub появился в 2008 году и с 2018 года принадлежит Microsoft. Он добавляет к Git веб-интерфейс, pull requests, code review, трекер задач (issues), CI/CD (GitHub Actions), хостинг статических сайтов (GitHub Pages) и права доступа для команды. Слоган GitHub — Social Coding: это не просто хранилище кода, а платформа для открытых и закрытых проектов.

Короткий ответ на вопрос «в чём разница»: Git — это технология, GitHub — сервис, построенный вокруг этой технологии. Git можно использовать без GitHub, а вот GitHub без Git не существует.

Состояния файлов в рабочем каталоге Git

Git делит все файлы проекта на две группы: отслеживаемые и неотслеживаемые.

1. Отслеживаемые файлы — те, что попали в последний снимок состояния проекта (snapshot) или уже добавлены в индекс. Они бывают неизменёнными, изменёнными и подготовленными к коммиту (staged).
2. Неотслеживаемые файлы — всё остальное: файлы, которых не было в последнем коммите и которые вы ещё не добавили командой git add.

Файл путешествует по трём областям: рабочий каталог → индекс (staging area) → репозиторий.

Посмотреть текущее состояние всех файлов можно одной командой:

git status
git status -s   # короткий формат: ?? новый файл, M изменён, A добавлен в индекс

Основные команды git

Ниже — минимальный набор, которого хватает для повседневной работы.

Типичный цикл работы

git status              # что изменилось
git add .               # подготовить все изменения к коммиту
git commit -m "Add user validation"
git pull --rebase       # забрать чужие коммиты и наложить свои сверху
git push                # отправить на сервер

Что важно знать про commit, fetch, pull и push

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

git fetch связывается с удалённым репозиторием и забирает данные, которых у вас ещё нет. После этого появляются ссылки на все удалённые ветки (origin/main и другие), их можно просмотреть или слить. Важно: fetch не изменяет вашу рабочую копию — сливать изменения вы решаете сами.

git pull — это fetch плюс автоматическое слияние удалённой ветки в текущую. При клонировании Git сам настраивает локальную ветку на отслеживание ветки по умолчанию удалённого репозитория (обычно main), поэтому git pull без аргументов знает, откуда тянуть.

git push отправляет ваши коммиты в удалённый репозиторий. Команда сработает, только если у вас есть права на запись и если после вашего последнего fetch никто не отправил туда новые коммиты. Если коллега успел раньше, ваш push будет отклонён с ошибкой non-fast-forward — нужно сначала забрать чужие изменения и объединить их со своими.

Команды для работы с GitHub

Отдельных «команд GitHub» в терминале нет — с GitHub вы работаете теми же командами Git, просто в качестве удалённого репозитория указываете адрес на github.com.

Клонировать чужой проект

git clone https://github.com/user/project.git
cd project

Отправить локальный проект на GitHub

Создайте пустой репозиторий на GitHub (без README), затем выполните:

git init
git add .
git commit -m "Initial commit"
git branch -M main
git remote add origin https://github.com/user/project.git
git push -u origin main

Флаг -u связывает локальную ветку с удалённой, поэтому дальше достаточно писать просто git push и git pull.

Проверить и изменить адрес репозитория

git remote -v                                   # какие удалённые репозитории настроены
git remote add upstream https://github.com/original/project.git
git remote set-url origin [email protected]:user/project.git   # перейти на SSH

Ветвление, слияние и конфликты

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

git branch                      # список веток
git switch -c feature/login     # создать ветку и перейти в неё
git switch main                 # вернуться в основную ветку
git merge feature/login         # влить ветку в текущую
git branch -d feature/login     # удалить влитую ветку

Команды git switch (переключение веток) и git restore (откат изменений в файлах) появились в Git 2.23 и заменяют перегруженный git checkout, который делал и то, и другое. Старый вариант git checkout -b feature/login по-прежнему работает.

Конфликт слияния возникает, когда одна и та же строка изменена в двух ветках. Git помечает спорное место в файле маркерами <<<<<<<, =======, >>>>>>>. Нужно вручную оставить правильный вариант, убрать маркеры и завершить слияние:

git add ConflictedFile.java
git commit

Метки (tags) и релизы

Метка (tag) — это неподвижная закладка на конкретном коммите. В отличие от ветки, метка не двигается вперёд, поэтому ею отмечают выпуски стабильных версий: v1.0, v2.0.1.

git tag v1.0                          # лёгкая метка
git tag -a v1.0 -m "First release"    # аннотированная метка с автором и датой
git push origin v1.0                  # метки не уходят на сервер обычным git push

На GitHub метка становится основой для Release — страницы с описанием версии и собранными артефактами (например, JAR-файлом).

Fork и pull request

Удалённый репозиторий — это версия проекта, размещённая на сервере (например, на GitHub). Удалённых репозиториев может быть несколько и с разными правами: только чтение или чтение и запись.

Если вы хотите поучаствовать в чужом проекте, но прав на запись у вас нет, используйте fork — кнопку, которая создаёт копию репозитория в вашем аккаунте. Дальше схема такая:

1. Нажимаете Fork на странице проекта — копия появляется у вас.
2. Клонируете свою копию: git clone.
3. Создаёте ветку, вносите изменения, делаете коммит и git push.
4. Открываете pull request в оригинальный репозиторий.
5. Автор проекта просматривает код (code review) и принимает или отклоняет изменения.

Fork — стандартный способ работы с open source. GitHub сохраняет связь вашей копии с оригиналом, поэтому изменения из upstream можно подтягивать кнопкой Sync fork или командами:

git remote add upstream https://github.com/original/project.git
git fetch upstream
git merge upstream/main

На чём чаще всего спотыкаются новички

• Коммит без индексации. git commit фиксирует только то, что добавлено через git add. Изменённый, но не проиндексированный файл в коммит не попадёт.
• git add . в корне проекта. Так в репозиторий улетают папки target/, .idea/, файлы *.class и, что хуже, пароли из конфигов. Заведите .gitignore до первого коммита.
• Пуш без pull. Ошибка ! [rejected] ... (non-fast-forward) означает, что на сервере есть коммиты, которых нет у вас. Решение — git pull --rebase, а не git push --force: force-push затирает чужую работу.
• git pull с незакоммиченными изменениями. Git откажется сливать. Либо закоммитьте, либо отложите правки: git stash, затем git stash pop.
• Отсоединённый HEAD (detached HEAD). Возникает после git checkout <хеш коммита>. Коммиты, сделанные в этом состоянии, не принадлежат ни одной ветке и легко теряются — вернитесь командой git switch - или сохраните работу в новой ветке.
• Путаница в терминах. Pull request — это запрос на GitHub, а не команда git pull. Общего у них только слово.