Git и GitHub

Важность системы контроля версий

Система контроля версий (Version control systems (VCS)) — это инструмент, который позволяет отслеживать изменения в файлах проекта, сохранять разные версии и при необходимости возвращаться к любому предыдущему состоянию.

Проблемы разработки без системы контроля версий

При обычной работе над проектом (папкой с файлами) разработчик создаёт последовательные версии: Версия 1 → Версия 2 → Версия 3, и т. д. При таком подходе возникает ряд проблем:

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

Простое копирование папки (Ctrl+C, Ctrl+V) для сохранения версий не решает проблему:

• Много копий → хаос.
• Трудно понять, где какие изменения.
• Невозможно объединить разные версии между собой.

Возможности разработки с системой контроля версий

• Сохранение истории изменений проекта.
• Фиксирование версии в определённые моменты времени.
• Откат к любой прошлой версии при необходимости.
• Анализ изменений: смотреть, что добавилось, что удалилось и кем.
• Изолированное развитие: Позволяет создавать несколько версий одновременно (например, Версия 3 и экспериментальная Версия 4, идущая от Версии 2) или работать над независимыми функциями (ветками).
• Слияние: Позволяет слить результаты независимых работ в одну финальную версию.

GIT

Git — популярная система контроля версий. Она позволяет сохранять историю проекта, сравнивать версии, откатываться к прошлым состояниям и объединять работу нескольких разработчиков.Git защищает разработчика от множества ошибок, связанных с потерей кода, неправильными изменениями и проблемами при работе в команде. Благодаря своей надёжности, скорости и гибкости Git стал стандартом в индустрии разработки программного обеспечения.

Как работает Git:

• Git превращает папку проекта в репозиторий, за которым наблюдает.
• Внутри создаётся скрытая служебная папка .git, где сохраняются все версии, коммиты и метаданные.
• Разработчик управляет этим процессом через команды Git (init, add, commit, status и др.).

Установка приложения

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

• Скачать Git с официального сайта для Windows, macOS или Linux.
• Устанавливать по умолчанию — нажимать «Далее» везде, ничего не менять.
• Проверьте установку Git, выполнив в терминале команду:

git -v

Инициализация git-репозитория

1. Проверим, отслеживает ли Git текущую папку:

git status

Видим в консоли следующую ошибку:

Это значит, что папка ещё не связана с Git — она пока не является репозиторием.

2. Создадим следующую структуру папок:

Для примера напишем небольшие кусочки кода:

const webSite = "https://it-incubator.io"
console.log(webSite)

alert("Hello")

3. Инициализация репозитория

Чтобы Git начал следить за проектом, нужно инициализировать репозиторий. Откройте терминал в созданной папке и выполните команду:

git init

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

Рабочие Зоны Git

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

1. Untracked Files (Неотслеживаемые файлы)

Теперь, выполнив команду git status мы увидим следующее:

• Коммитов ещё нет — то есть пока ни одна версия изменений не была зафиксирована. Напомню, коммит — это сохранённая версия файлов, зафиксированная в истории Git.
• Текущая ветка — main. Пока мы работаем в этой основной ветке. Ветки (branch) позволяют вести параллельную работу без риска повредить основную версию, но подробности изучим позже.
• Untracked files — файлы, которые Git видит, но ещё не отслеживает, потому что они новые. Видим здесь созданные нами файлы (samurai JS, incubator.js) и папки (.idea). Git пока не отслеживает их изменения.
• Игнорируемые файлы и папки — .git. Git знает о них, но не отображает и не следит за ними, так как это системные или вспомогательные файлы, которые нам трекать не нужно.

На этом этапе Git также подсказывает, что для отслеживания новых файлов нужно использовать git add <имя_файла>, чтобы добавить их в индекс (Staged Area) и подготовить к коммиту.

2. Tracked Files (Отслеживаемые файлы)

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

1. Modified: Файл изменён после последнего коммита. Git предупреждает: “есть несохранённые изменения”.
2. Staged Area: Зона подготовки — файлы готовы к фиксации (коммиту). Только файлы отсюда попадут в новый коммит.
3. Clean / Unmodified: Файл без изменений, его текущее состояние уже зафиксировано в истории. После коммита файл возвращается в это состояние.

Добавим наш файл incubator.js в Staged Area:

git add incubator.js

Теперь Git отслеживает его изменения и готов включить в следующий коммит. Проверим текущее состояние:

git status

Видим, что появился раздел Changes to be committed и там лежит наш файл incubator.js. Остальные файлы так и остались в Untracked Files.

Если мы хотим вернуть файл из Staged Area обратно в untracked files (или просто убрать из готовых к коммиту), используется команда:

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

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

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

git rm --cached <имя_файла>

Например:

git rm --cached incubator.js

Эта команда не удаляет файл с диска, она только убирает его из Staged Area, возвращая в состояние untracked. После этого командой git status можно убедиться, что файл снова в зоне untracked files и не готов к коммиту.

Чтобы вернуть обратно в Staged Area используй команду git add.

git add incubator.js

✅ Проверяем статус — файл отображается как готовый к коммиту (Changes to be committed).

Фиксируем изменения с помощью коммита

Чтобы зафиксировать текущую версию файла, используем команду:

git commit -m "Описание изменений"

В -m пишем краткое сообщение, поясняющее, что изменилось.

git commit -m "add main file"

Git берёт файлы из Staged Area (индексированные, готовые к коммиту) и сохраняет их как новую версию в истории. После коммита файл больше не считается новым или изменённым — он теперь чистый относительно последнего коммита, любые новые изменения в нём будут отслеживаться отдельно.

Проверка статуса:

git status

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

Также добавим файл samurai.js в Staged Area:

git add samurai.js

Проверяем git status и видим, что добавился new file: samurai.js.

Изменения

Для демонстрации работы с изменениями добавим экспорт переменной в файл samurai.js, а затем импортируем её в incubator.js.

alert("Hello")
export const a = 10

import { a } from "./samurai.js"
 
const webSite = "https://it-incubator.io"
console.log(webSite)
console.log(a)

После внесения изменений в код и повторного выполнения команды git status мы видим, что файл samurai.js отмечен как новый и готовый к коммиту — Git знает о его существовании, потому что мы ранее добавили его через git add. Однако одновременно этот же файл отображается и в разделе changes not staged for commit — то есть у него есть новые изменения, которые ещё не были подготовлены для фиксации.

Поэтому мы снова добавляем обновлённые файлы в staged-зону:

git add samurai.js
git add incubator.js

Теперь команда git status покажет, что оба файла — samurai.js (new file) и incubator.js (modified) — готовы к коммиту. Таким образом, мы подготовили проект к фиксации всех последних изменений.

🔍 Как посмотреть изменения в файлах

Чтобы узнать, что именно было изменено, используют команду:

git  diff

Она показывает:

• какие файлы были изменены;
• какие строки добавлены+ и какие удалены -;
• иногда предупреждение No newline at end of file, если в конце файла нет пустой строки (по стандарту она должна быть).

💡 Git воспринимает изменения построчно: если строка хоть немного изменилась — старая считается удалённой, а новая добавленной.

Выполняем коммит наших изменений:

git commit -m "add samurai logic"

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

Ignored files

Папка .idea постоянно отображается в списке untracked files, подсвечивается красным и мешает работе. Есть риск случайно закоммитить её в репозиторий, хотя она не нужна в контроле версий.

Чтобы Git перестал отслеживать лишние файлы и папки, создаётся специальный файл .gitignore — текстовый файл, где перечислены объекты, которые Git должен игнорировать.

Создать его можно двумя способами:

• Tерминал:

echo ".idea" > .gitignore

• Bручную: Создайте новый текстовый файл с именем .gitignore и впишите в него .idea.

Важно помнить: сам файл .gitignore — это обычный текстовый файл, и его тоже стоит добавить в репозиторий, чтобы другие участники проекта использовали те же правила игнорирования. Для этого выполняем:

git add .gitignore
git commit -m "add .gitignore"

Когда мы убрали ненужные файлы в .gitignore, закомитили все изменения, проверяем git status и видим nothing to commit, working tree clean, что означает, что все файлы, за которыми следит git чистые и неизмененные.

Ошибки при добавлении лишних файлов

🚨 Ситуация

Иногда по невнимательности в репозиторий могут попасть лишние файлы или папки, например .idea из WebStorm. Даже если позже добавить эту папку в .gitignore, Git продолжит отслеживать те файлы, которые были закоммичены раньше.

Допустим вы создали много новых файлов и решили их все добавить в staged area с помощью одной команды:

git add .

Вместе с нужными файлами в staged-зону попадает и .idea. Не заметив этого, выполняете коммит, например:

git commit -m "Initial commit"

Теперь Git начал отслеживать содержимое .idea. Добавление папки в .gitignore на данном этапе предотвращает отслеживание новых файлов, но уже закоммиченные файлы из этой папки всё равно остаются под контролем версий.

🩹 Как исправить

Чтобы удалить уже отслеживаемую папку из Git (но не из проекта), нужно выполнить:

git rm -r --cached .idea

• rm — удалить из индекса;
• -r — рекурсивно пройтись по подпапкам;
• --cached — удалить только из кэша Git (файлы останутся на диске).

Затем зафиксировать изменения:

git add .gitignore
git commit -m "fix: remove .idea from tracking and update .gitignore"

После этого Git:

• перестанет следить за .idea;
• будет игнорировать все будущие изменения в этой папке.

GitHub

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

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

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

Удаленные репозитории могут быть:

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

Создание удалённого репозитория

Для начала работы необходимо создать аккаунт или авторизоваться на GitHub.

1. В профиле выбрать → Repositories → New repository.
2. Далее задайте имя, например youtube-lesson.
3. Выберите, какой репозиторий хотите создать(публичный или приватный).
4. Нажать Create repository.

🎉 Готово! Вы создали новый, возможно первый свой репозиторий.

GitHub покажет инструкцию с командами и ссылку на репозиторий. Чтобы отобразить ссылку, нажмите на HTTPS:

Связь локального и удалённого репозитория

Чтобы связать наш локальный репозиторий с GitHub, используем команду:

git remote add origin <URL_репозитория>

• origin — стандартное имя удалённого репозитория.

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

git remote -v

Отправка изменений на GitHub (Push)

Для первой отправки всех наших изменений из локального хранилища на GitHub используем команду:

git push -u origin main

Git требует авторизацию. Это происходит, потому что публичность дает доступ только на чтение.

В userName указываем свой ник для gitHub, а в password необходимо положить Personal Access Token (PAT). Этот токен необходимо создать в личном кабинете:

Задаем имя для нашего токена, например youtube-lesson и выбираем срок действия. Для безопасности лучше ограничить срок действия токена.

Далее выбираем доступ к нужным репозиториям (только к публичным, ко всем или какому-то конкретному) и пока предоставим все permissions из списка, открывающего при нажатии на Add permissions:

В permissions для Contents изменим read-only на read and write:

Нажимаем Generate token, токен появляется в списке и можно его скопировать:

И теперь снова пробуем запушить изменения и подставить userName и token:

git push -u origin main
userName for 'https://github.com': 'your_userName'
password for 'https://your_userName@github.com': 'your_token'

🚀 Все данные запушились на gitHub!

Проверка результата на GitHub

После успешного git push на GitHub в разделе Code появятся ваши файлы:

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

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

Самый простой способ отменить изменения — сделать новый коммит с нужными правками.

git add 'changed_file'
git commit -m "revert: reverted to previous version"
git push

История останется последовательной, но код вернётся к прежнему виду.

Клонирование репозитория

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

Открываем в нужной нам папке терминал и выполняем команду clone с указанием ссылки на репозиторий:

git clone https://github.com/username/yourRepo.git

Адрес берем не из адресной строки, а из Code:

✅ Результат:

• Создаётся новая папка с именем репозитория.
• Скачивается вся история коммитов.
• Автоматически настраивается remote origin.

Работа с IDE (WebStorm и VS Code)

IDE позволяют работать с Git через встроенный UI поверх Git, но полезно понимать, что за каждым действием стоит команда Git (git add, git commit, git push). Также IDE могут использовать разную терминологию:

Работа с файлами в Git через UI

Добавление/удаление файлов в Staged area

1. Автоматическое предложение при создании файла: WebStorm может предложить выполнить git add сразу. Рекомендуется жать Cancel / Don't ask again, чтобы вручную контролировать версионирование.

2. Индексирование вручную

• WebStorm: Через галочку в списке изменений, через контекстное меню → Git → Add.
• VS Code: Кнопка + в Changes добавляет файл в Staged Changes.

3. Отмена индексирования

• VS Code:Можно нажать на кнопку – в Staged Changes, чтобы вернуть файл в Changes.
• WebStorm: Используется команда Rollback. Она не удаляет файл, а возвращает его в категорию Unversioned files (если он новый).

Создание коммита (Commit)

• WebStorm позволяет написать сообщение коммита и сделать отдельно Commit или Commit and Push
• Автоматическое индексирование при коммите: VS Code при попытке коммита без предварительного индексирования может предложить автоматически добавить в Staged area все изменения перед коммитом.В WebStorm индексирование выполняется автоматически, если файл отмечен для коммита.
• Выбор файлов: В WebStorm можно выбрать только нужные файлы для коммита, даже если их несколько (например, измененные файлы и новые)

Просмотр истории и изменений WebStorm

WebStorm предоставляет полноценный UI для вкладки Git → Log, где:

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

Аутентификация и Push

При отправке изменений на удаленный сервер (Push) через UI, IDE проверяет авторизацию: Если пользователь не авторизован:

• Открывается окно OAuth-авторизации GitHub.
• После подтверждения IDE получает токен доступа.
• Повторная авторизация больше не потребуется.
• Все последующие push проходят автоматически без повторного ввода данных.

Таблица полезных команд

🏠 Домашнее задание

Цель задания: освоить базовые операции с Git и GitHub для эффективного управления версиями кода, работы в команде и сохранения истории разработки проектов.

Задание 1 📌

📌 Дополнительное задание. Необязательно для выполнения

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

🎞️ Посмотреть базовый плейлист по работе с гитом для новичков.

Кому будет полезен данный плейлист:

• Если впервые будешь работать с гитом и не понимаешь с чего начать
• Если боишься что-то поломать и не уверен в своих силах
• Если хочешь познакомиться с базовым функционалом при работе с гитом и в целом понимать что тебя ждет

Темы, которые будут затронуты в плейлисте:

1. Git - введение, установка, настройка, привязка ssh ключа
2. Создание Create React App
3. Добавление idea в gitignore
4. Размещение CRA на Github через консоль и webstorm
5. Git commit создание, правки, откат, отмена
6. Работа с удаленным репозиторием создание и удаление
7. Клонирование репозитория, git pull
8. Pull request
9. Ветки (branch) - создание, слияние, удаление, разрешение конфликтов
10. Git stash / Unstash
11. Локальная история в Webstorm
12. Github gist
13. Создание нескольких учетных записей GitHub на одном компьютере

Задание 2

1. Установи git. Ссылка на документацию по установке
2. Создай директорию под любым названием, например git-lesson
3. Проинициализируй директорию

git init

4. Убедись, что в директории git-lesson появилась папка .git

5. Создай в директории git-lesson новый файл под любым названием, например file1.js

6. Выполни команду git status и убедись, что файл находится в разделе untracked

7. Выполни команду git add file1.js и убедись, что файл переместится в staging area. Для этого ещё раз выполни команду git status

8. Верни обратно файл в состояние untracked git rm --cached file1.js

9. Добавь еще 1 файл под любым названием, например file2.js

10. Теперь оба файла добавь в staging area git add .

11. Создай файл .gitignore и укажи файлы и папки за которыми гит не должен следить

/.idea
.DS_Store

# Logs
logs
*.log
npm-debug.log*
yarn-debug.log*
yarn-error.log*
pnpm-debug.log*
lerna-debug.log*

node_modules
dist
dist-ssr
*.local

# Editor directories and files
.vscode/*
!.vscode/extensions.json
.idea
.DS_Store
*.suo
*.ntvs*
*.njsproj
*.sln
*.sw?

12. Закоммить файлы, выполнив команду git commit -m "first commit"
13. В файл file1.js добавь какой-нибудь код, например console.log('it incubator'), и попробуй закоммитить изменения git commit -m "add logs"

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

Changes not staged for commit:
  modified:   file1.js
no changes added to commit

Это означает, что файл file1.js был изменён, но ты не выполнил git add file1.js, чтобы поместить эти изменения в индекс (staged area). Поэтому Git не знает, что ты хочешь включить эти изменения в коммит.

❗Самостоятельно исправь эту проблему, чтобы файл стал закоммичен

14. Теперь внеси изменения в файл file2.js, например console.log('it kamasutra'). Теперь выполни команду git diff, чтобы увидеть, какие изменения внесены в файл

Сохрани и закоммить эти изменения самостоятельно

15. Добавь в файл file2.js любой код.

Часто бывает, что ты пишешь код, но потом понимаешь, что пошёл по неправильному пути и этот код нужно убрать. Можно, конечно, пойти в изменённый файл и вручную удалить внесённый код.

Но если хочется сделать это программным способом, отменить изменения в рабочей директории (вернуть файл к состоянию последнего коммита), тогда пропиши команду git restore file2.js

16. ⭐ Откат изменений

⭐ Дополнительное задание со звёздочкой. В видеоуроке такой вариант не рассматривался

Часто случается, что ты закоммитил изменения локально (git commit), но ещё не отправил их в удалённый репозиторий и понимаешь, что допустил ошибку в коммите. В таком случае есть 2 варианта:

• 1. Внести изменения в коммит и запушить уже правильную версию. В таком случае в удалённый репозиторий улетит 2 коммита.
• 2. Откатить коммит и запушить уже правильную версию. В таком случае в удалённый репозиторий улетит только 1 правильный коммит.

Твоя задача — реализовать второй сценарий и откатить предыдущий коммит

Задание 3

Работа с github

1. Зарегистрируйся на github, если ещё не сделал этого
2. Создай новый репозиторий git-lesson.
3. Следуя по шагам из видеоурока, запушь папку git-lesson, которая у тебя сохранена локально, на удалённый репозиторий
4. Таким же образом создай ещё 2 удалённых репозитория и запушь в них свой код:

• репозиторий для основного курса, по которому ты делаешь уроки и повторяешь за Димычем
• репозиторий, в котором ты выполняешь домашние задания

🤔 Зачем сохранять код из курса и домашних заданий в Git ?

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

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

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

Задание 4

Клонируй любой публичный репозиторий. Например, репозиторий, в котором пишется проект Musicfun на разных стеках.

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

Дополнительная задача — это поставить звёздочку ⭐ данному репозиторию в знак благодарности за работу Димычу и команде it-инкубатора 😊

Задание 5

Поработай с гитом в Webstorm или Visual Studio Code. Внеси изменения в файлы, сделай коммит, потом пуш на удалённый репозиторий. Попробуй откатить изменения. В общем, экспериментируй и изучай гит на учебном проекте, чтобы, когда ты столкнёшься с проблемой работы с гитом в жизни, ты знал, как её можно решить.

Бонусом тебе даем методическое пособие по git и github, которое сделал студент it-инкубатора