GitHub от новичка до мастера: Полное руководство

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

Однако настоящие деньги приносят умение фильтровать информацию и способность к реализации. Если вы хотите заниматься AI, перейти в FDE (Full-stack Development Engineer) или превратить себя в OPC (One Person Company), код, документация, версии и совместная работа в конечном итоге окажутся на GitHub.

Даже если вы занимаетесь творчеством или ведете блог, на GitHub есть множество инструментов для выбора тем, проектов автоматизации и процессов создания контента. Как только количество файлов увеличится, а AI начнет вносить изменения, без Git для управления версиями всё быстро выйдет из-под контроля. Поэтому Git нужно изучать не только программистам, но и менеджерам проектов, и создателям контента; это определяет, сможете ли вы превратить идею в управляемый, воспроизводимый и готовый к передаче проект.

Я потратил больше половины месяца на шлифовку этой статьи, отрабатывая Git, GitHub, коммиты, ветки, PR и типичные ошибки с нуля. Будущие прямые эфиры также будут следовать этому же процессу. Перед официальным эфиром я публикую это руководство в открытом доступе. Вы можете сохранить его в закладки или полностью пройтись по нему.

1. Git и GitHub: Кто чем управляет?

Git — это инструмент управления версиями, установленный на вашем компьютере. Даже офлайн вы можете делать коммиты, просматривать историю, создавать ветки и сливать их. GitHub — это удаленный репозиторий и платформа для совместной работы; он принимает коммиты, отправленные Git, и предоставляет Issues, Pull Requests, Actions, ревью кода и управление правами доступа.

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

Нажатие «Сохранить» только записывает содержимое на жесткий диск. git add отвечает за отбор, git commit оставляет версию локально, а git push отправляет эти коммиты на GitHub.

Поэтому перед коммитом проверьте diff, запустите код или протестируйте его; после успешного пуша вернитесь на веб-страницу для двойной проверки. Так, если возникнет проблема, вы сразу сможете понять, на каком уровне она остановилась.

2. Перед началом: Подготовьте всего четыре вещи

Вам понадобятся Git, учетная запись GitHub, редактор и учебный проект. VS Code подойдет в качестве редактора, а проект может быть веб-страницей или Markdown-документом.

Сначала проверьте Git в терминале:

1git --version

В этом упражнении используется macOS и Git 2.49.0. Пользователи Windows могут использовать Git Bash или встроенный терминал VS Code; команды Git ниже те же самые.

Затем настройте автора коммита:

1git config --global user.name "Ваше Имя"
2git config --global user.email "Ваш Email"

Это информация об авторе, которая записывается в историю коммитов; она не отвечает за вход в GitHub. Если вы хотите настроить это только для текущего учебного проекта, замените --global на --local.

Вход в GitHub — это отдельная история. В командной строке обычно используются три метода:

• GitHub CLI, авторизация через браузер с помощью gh auth login;
• HTTPS, с использованием Personal Access Token или менеджера учетных данных;
• SSH, добавление публичного ключа в GitHub и последующая аутентификация по ключу.

Новички могут выбрать GitHub CLI или HTTPS. При использовании HTTPS, если терминал запрашивает пароль, введите Token; обычные пароли от учетной записи больше не подходят. Не записывайте Token в команды, удаленные URL, README, чаты или скриншоты.

3. Не спешите с init: Убедитесь, где на самом деле находится терминал

Это упражнение начинается с простой веб-страницы. Ее можно открыть в браузере, но у нее еще нет истории Git.

В проекте три файла:

1index.html
2style.css
3.gitignore

В VS Code выберите «Открыть папку», не кликайте просто на один HTML-файл. Затем выполните во встроенном терминале:

1pwd
2ls

pwd показывает текущую директорию, а ls выводит список файлов. Продолжайте только после того, как увидите index.html и style.css.

Эта проверка выглядит глупо, но она предотвращает самый неприятный тип аварии: когда кто-то выполняет git init на Рабочем столе, в Документах или даже в домашней директории пользователя, а затем git add . помещает тысячи ненужных файлов в область подготовки. Git не сломан; просто директория была выбрана неправильно.

4. Что делает git init?

Теперь инициализируйте репозиторий:

1git init -b main
2git status --short

git init -b main создает директорию .git в текущей папке и называет начальную ветку main. .git — это скрытая директория, где хранятся коммиты, ветки, область подготовки и удаленные адреса. Файлы проекта остаются на месте; с этого момента Git начинает за ними наблюдать.

?? на скриншоте означает неотслеживаемые файлы. Файлы существуют, но Git еще не решил, стоит ли их записывать.

Чтобы подтвердить корневую директорию репозитория, выполните:

1git rev-parse --show-toplevel

Вывод должен показать текущую папку проекта. Если выводится fatal: not a git repository, сначала проверьте директорию, затем посмотрите, был ли выполнен git init.

5. Первый коммит: Создайте надежную отправную точку

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

Затем посмотрите на .gitignore. Содержимое, используемое в этот раз:

1.env
2.env.*
3*.log
4node_modules/
5dist/
6build/

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

Начните отбор файлов для первого коммита:

1git add index.html style.css .gitignore
2git status --short
3git diff --cached --stat

Буква A в статусе означает Added (добавлен), указывая, что файл попал в область подготовки. git diff --cached --stat покажет, сколько файлов вы готовитесь закоммитить и примерно сколько строк было изменено. Чтобы увидеть конкретное содержимое, выполните:

1git diff --cached

После подтверждения сделайте коммит:

1git commit -m "chore: Инициализация страницы AI-рекрутинга для студентов"
2git log --oneline
3git status

Коммит можно понимать как снимок проекта с автором, временем, описанием и родительским коммитом. ffdf4ff — это сокращенная версия хеша этого коммита; использование его в текущем репозитории позволяет точно найти версию.

feat, fix, docs, style, chore — это распространенные типы коммитов, не обязательный синтаксис Git. Важнее префикса описание на русском (или английском) языке, которое следует за ним: что было сделано, какой объект изменен и почему.

6. Второй коммит: Относитесь к изменениям AI как к черновикам для ревью

Далее добавьте на страницу кнопку «Посмотреть способ регистрации». При использовании инструментов AI-программирования я прописываю границы в промпте:

1Измени только index.html, добавь ссылку «Посмотреть способ регистрации» под вводным текстом,
2ведущую к #apply на странице. Не изменяй style.css, не выполняй коммиты Git.
3По завершении сообщи, какой файл был изменен.

Ручное изменение тоже просто:

1<a class="cta" href="#apply">Посмотреть способ регистрации</a>

AI говорит, что готово, но не спешите с коммитом. Выполните:

1git status --short
2git diff -- index.html
3git diff --check

git diff показывает изменения в рабочей директории, которые еще не были проиндексированы. Зеленый + — это добавленная строка, красный - — удаленная. git diff --check не выводит ничего, что указывает на отсутствие очевидных проблем с форматированием, таких как пробелы в конце строк; он не проверит за вас, кликабельна ли кнопка.

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

Делайте коммит только после того, как тест пройден:

1git add index.html
2git diff --cached
3git commit -m "feat: Добавлена запись для быстрого просмотра способов подачи заявки"
4git log --oneline -2

На этом этапе в репозитории есть две четкие версии: стартовая страница и кнопка регистрации. Если позже с кнопкой возникнут проблемы, вы сможете напрямую найти коммит, который ее добавил.

Кстати, различайте два diff:

1git diff             # Разница между рабочей директорией и областью подготовки
2git diff --cached    # Разница между областью подготовки и последним коммитом

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

7. Ветки: Оставьте место для тестирования неопределенных изменений

Кнопка добавляет всего одну строку, поэтому риск невелик. Изменение всей темы с фиолетовой на оранжевую может выглядеть хорошо, а может и безвкусно; такое изменение лучше делать в ветке.

1git switch -c experiment/warm-theme
2git branch --show-current

Ветка — это, по сути, имя, указывающее на определенный коммит. Когда новая ветка только создается, она указывает на тот же коммит, что и main, поэтому файлы абсолютно одинаковы. Только когда экспериментальная ветка порождает новые коммиты, две линии расходятся.

На диаграмме синяя main все еще указывает на второй коммит, а оранжевая experiment уже указывает на третий коммит. Проект не дублировал два набора файлов; изменились только указатели для двух имен веток.

Измените переменные цвета в style.css, обновите страницу для подтверждения, затем сделайте коммит:

1git diff -- style.css
2git diff --check
3git add style.css
4git commit -m "style: Попробовать теплую тему в экспериментальной ветке"
5git log --oneline --graph --decorate --all

HEAD указывает, где вы сейчас находитесь. На скриншоте HEAD указывает на experiment/warm-theme, а main остается на коммите с кнопкой.

Решите оставить теплую тему, переключитесь обратно на main и выполните слияние:

1git switch main
2git merge experiment/warm-theme

Здесь происходит Fast-forward, потому что у main не было новых коммитов во время эксперимента. Git просто перемещает указатель main вперед, к коммиту с теплой темой; изменения успешно объединены.

Объединенные ветки можно безопасно удалить:

1git branch -d experiment/warm-theme

Строчная -d проверяет, была ли ветка объединена. Заглавная -D принудительно удалит, и коммиты в ветке, которые не были объединены, могут потерять свои ссылки; не используйте ее как команду для ежедневной очистки.

8. Конфликты не загадочны; Git просто не решает за вас

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

Маркеры конфликта делятся на три части:

1<<<<<<< HEAD
2Содержимое текущей ветки
3=======
4Содержимое ветки, которую сливаем
5>>>>>>> feature/rewrite-heading

Метод обработки: отредактируйте файл, оставьте окончательный нужный текст, удалите три набора маркеров, протестируйте, а затем выполните:

1git add index.html
2git commit

Если вы не хотите разбираться с этим сейчас, вы можете прервать слияние:

1git merge --abort

Конфликт означает, что два человека или два агента дали разные ответы для одного и того же места, и Git не может выбрать самостоятельно.

9. Отправка локального репозитория на GitHub

У проекта уже есть локальная история; теперь перейдите на GitHub, чтобы создать репозиторий. Нажмите + в правом верхнем углу, выберите «New repository» и укажите имя репозитория, например:

1campus-ai-demo

Для первой практики рекомендуется установить его как Private. Поскольку локально уже есть README, .gitignore и история коммитов, оставьте новый репозиторий GitHub пустым; не инициализируйте README, лицензию или .gitignore на веб-стороне. В противном случае у локального и удаленного репозиториев будет по кусочку начальной истории, и при первом пуше потребуется сначала разобраться с отношениями между ними. Официальная документация GitHub «Adding locally hosted code» также явно об этом предупреждает.

Скопируйте HTTPS-адрес:

1https://github.com/ВашеИмяПользователя/campus-ai-demo.git

Вернитесь в терминал проекта:

1git remote add origin https://github.com/ВашеИмяПользователя/campus-ai-demo.git
2git remote -v
3git push -u origin main

origin — это псевдоним для удаленного адреса; можно использовать и другие имена, но в сообществе принято называть основной удаленный репозиторий origin. -u устанавливает отношение отслеживания между локальным main и origin/main; последующие операции обычно выполняются просто командой git push.

На диаграмме терминала ниже использовался локальный bare-репозиторий для отработки push и clone, поэтому он не менял существующую учетную запись GitHub. При переключении на GitHub просто замените URL origin; логика передачи коммитов Git и установления отношений отслеживания та же.

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

10. Первое знакомство с репозиторием GitHub: Как читать эти вещи на странице

Ниже представлена реальная страница официального репозитория документации GitHub, скриншот от 15 августа 2026 года.

Открывая репозиторий, сначала посмотрите на эти места:

• Code: Файлы, директории, ветки и коммиты;
• Issues: Баги, требования, задачи и обсуждения;
• Pull requests: Изменения, ожидающие ревью или слияния;
• Actions: Автоматическое тестирование, сборка и развертывание;
• Security: Политики безопасности и функции, связанные с уязвимостями;
• Insights: Вклад, трафик и активность репозитория;
• README: Введение в проект и точка входа для использования;
• LICENSE: Как разрешено использовать, изменять и распространять.

Читая незнакомый проект, не смотрите сначала на Stars. Сначала ответьте на пять вопросов: Какую проблему он решает, как он запускается, от чего зависит, поддерживается ли он в последнее время и что лицензия позволяет мне делать. Stars отражают внимание; они не проверяют за вас безопасность, совместимость или авторизацию.

11. clone, fetch, pull, push: Не путайте четыре направления

Первое получение удаленного репозитория на ваш компьютер:

1git clone https://github.com/ВЛАДЕЛЕЦ/РЕПО.git

Clone приносит файлы, историю коммитов и удаленные конфигурации, обычно автоматически называя удаленный репозиторий origin. Скачивание ZIP-архива дает только снимок файлов на тот момент, без полной истории и не устанавливает удаленную связь.

Три часто используемых действия после этого:

1git fetch origin   # Загружает удаленную информацию, не изменяет текущие рабочие файлы
2git pull           # fetch и затем интеграция в текущую ветку
3git push           # Отправляет локальные коммиты на удаленный репозиторий

Чтобы сначала увидеть, что произошло на удаленном репозитории, вы можете:

1git fetch origin
2git status -sb
3git log --oneline HEAD..origin/main

Когда вы убедились, что локально нет расхождений, и хотите принять только fast-forward обновления:

1git pull --ff-only

pull сначала выполнит fetch, а затем merge или rebase в зависимости от конфигурации. Команды должны согласовать метод интеграции до первого сотрудничества и не полагаться на force push для сглаживания проблем при расхождениях.

12. От личного репозитория к совместной работе на GitHub

Pull Request — это предложение о слиянии и место, где происходит совместная работа. Обсуждения, ревью кода и автоматические проверки вращаются вокруг одного и того же набора изменений, и он сливается в main только после подтверждения.

Предположим, Issue гласит «Добавить описание времени мероприятия», локальные операции можно выполнить так:

1git switch -c feat/event-time
2# Измените и протестируйте страницу
3git add index.html
4git commit -m "feat: Добавить описание времени мероприятия"
5git push -u origin feat/event-time

После пуша GitHub обычно предлагает создать Pull Request. PR — это предложение о слиянии, которое отображает описание, коммиты, различия в файлах, комментарии, ревью и автоматические проверки. Он не попадет автоматически в main только потому, что был создан.

PR, который люди захотят ревьюить, должен объяснять как минимум три вещи: что было изменено, почему это было изменено и как это проверить. Чем более сфокусированы изменения, тем легче ревьюерам заметить проблемы.

В одной команде, если у вас есть права на запись в репозиторий, вы можете отправить PR прямо из ветки. При внесении вклада в незнакомый проект с открытым исходным кодом обычной практикой является сначала сделать Fork в свою учетную запись, а затем клонировать свой Fork:

1git clone https://github.com/ВашеИмяПользователя/ИмяПроекта.git
2cd ИмяПроекта
3git remote add upstream https://github.com/ИсходныйАвтор/ИмяПроекта.git
4git remote -v

Здесь обычно два удаленных репозитория:

1origin    Ваш собственный Fork
2upstream  Репозиторий исходного автора

Синхронизируйте исходный проект:

1git fetch upstream
2git switch main
3git merge --ff-only upstream/main
4git push origin main

Затем выполните изменения в новой ветке, отправьте в свой Fork, а затем отправьте PR в upstream. Fork, clone и ветка решают три разные задачи: Fork — это набор пространства репозитория на GitHub, clone переносит репозиторий на локальный компьютер, а ветка — это линия разработки внутри репозитория.

13. README и LICENSE определяют, посмеют ли другие этим пользоваться

README должен отвечать как минимум на эти вопросы:

1. Что это за проект;
2. Какую проблему он решает;
3. Как его установить или запустить;
4. Насколько он завершен на данный момент;
5. Где находятся основные файлы;
6. Кто авторы, материалы и источники цитирования.

Если код работает, но README расплывчато, вы сами можете не разобраться в нем через три месяца. Минимальный README не обязательно должен быть красивым; просто четко опишите проект, способ запуска и статус.

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

MIT, Apache-2.0, GPL и т.д. имеют разные обязательства. При столкновении с коммерческим использованием, распространением или смешанными лицензиями прочитайте полный файл и при необходимости проконсультируйтесь со специалистом; не спрашивайте просто у AI «Могу ли я использовать это в коммерческих целях?»

14. После ошибки: Определите, на каком уровне находится изменение

«Лекарство от сожаления» нужно выбирать в зависимости от состояния.

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

1git restore --staged имя_файла

Сообщение последнего коммита написано неправильно и еще не отправлено:

1git commit --amend -m "Новое сообщение коммита"

Коммит в общей ветке нужно отменить:

1git revert хеш_коммита

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

git restore имя_файла отменит изменения, которые не были закоммичены; git reset --hard вернет коммиты, область подготовки и рабочую директорию в указанную позицию; git push --force может перезаписать удаленные коммиты. Эти три типа операций требуют подтверждения цели и создания резервной копии перед выполнением; не относитесь к ним как к универсальным кнопкам восстановления на начальном этапе.

15. Восемь самых распространенных ошибок: Проверяйте в этом порядке

1. fatal: not a git repository

1pwd
2ls
3git status

Обычно директория не та, или для текущего проекта еще не был выполнен git init.

2. Author identity unknown

1git config --local user.name "Ваше Имя"
2git config --local user.email "Ваш Email"

3. nothing to commit

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

1git status
2git log --oneline -3

4. remote origin already exists

1git remote -v
2git remote set-url origin ПравильныйАдресGitHub

5. src refspec main does not match any

В репозитории может не быть ни одного коммита, или текущая ветка называется не main:

1git log --oneline
2git branch --show-current

6. Authentication failed or 403

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

7. rejected non-fast-forward

На удаленном репозитории есть коммиты, которых нет локально. Сначала выполните fetch и просмотрите различия; не делайте force push сразу:

1git fetch origin
2git status -sb
3git log --oneline --graph --decorate --all -10

8. Merge Conflict

Выполните git status, чтобы найти файлы с пометкой UU, вручную определите окончательное содержимое, протестируйте, затем add и commit; если пока не разбираетесь, git merge --abort.

Когда студент или коллега просто говорит «Git сломался», попросите их предоставить эти пять выводов:

1pwd
2git status
3git branch --show-current
4git log --oneline -5
5git remote -v

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

16. В эпоху ИИ Git больше похож на систему приемки

ИИ может вводить команды за вас, но он не может автоматически знать, какие изменения соответствуют бизнес-намерениям. Если промпт изменяет 20 файлов, а вы не смотрите на diff, не запускаете проект и не проверяете ключи, Git просто добросовестно запишет этот беспорядок.

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

Когда вы позволяете ИИ управлять Git, также задавайте границы:

1Пожалуйста, сначала проверьте git status и git diff, и только обобщите текущие изменения.
2Не удаляйте никакое незакоммиченное содержимое, не выполняйте reset --hard, clean или force push.
3Предоставьте результаты проверки после завершения изменений, не делайте автоматический коммит или push.

Запоминать команды уже не так важно. Вам нужно уметь читать статус, знать, что переместил ИИ, оценивать, достаточна ли проверка, и останавливаться, когда появляются опасные операции.

17. Пройдите весь процесс заново

1# 1. Подтвердите местоположение
2pwd
3ls
4
5# 2. Инициализация
6git init -b main
7git status
8
9# 3. Первый коммит
10git add index.html style.css .gitignore
11git diff --cached
12git commit -m "chore: Инициализация проекта"
13
14# 4. Изменение, проверка, тестирование, снова коммит
15git status --short
16git diff
17git diff --check
18git add index.html
19git commit -m "feat: Добавление точки регистрации"
20
21# 5. Эксперимент с веткой
22git switch -c experiment/warm-theme
23git add style.css
24git commit -m "style: Эксперимент с теплой темой"
25git switch main
26git merge experiment/warm-theme
27
28# 6. Подключение к GitHub
29git remote add origin https://github.com/YourUsername/RepoName.git
30git remote -v
31git push -u origin main
32
33# 7. Финальная проверка
34git status
35git log --oneline --graph --decorate --all
36git remote -v
37git diff --check
38git ls-files

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

Следующий шаг не требует продолжения сбора команд. Найдите реальный небольшой проект и делайте его 7 дней подряд: каждый день выполняйте только одно небольшое изменение, смотрите diff, тестируйте, коммитьте, а затем пушите на GitHub. История коммитов постепенно превратит этот набор действий в вашу рабочую привычку.

Я Майлз, эксперт по алгоритмам ИИ, перешедший из крупной компании в FDE. Я занимался разработкой алгоритмов, оптимизацией развертывания и корпоративным обучением. Подписывайтесь на меня @miles_mazy Растите вместе, зарабатывайте вместе.