Основы Git и GitHub: от консоли до удаленного репозитория

Введение в Git: установка, базовая настройка и инициализация проекта

Добро пожаловать в курс «Основы Git и GitHub: от консоли до удаленного репозитория». Если вы когда-либо сохраняли файлы с именами diploma_final.doc, diploma_final_v2.doc, diploma_final_FINAL_REAL.doc, то вы уже интуитивно понимаете, зачем нужна система контроля версий. В этой статье мы разберемся, как превратить хаос из копий файлов в стройную историю изменений, которую невозможно потерять.

Что такое Git и зачем он нужен?

Git — это распределенная система контроля версий (Version Control System, VCS). Звучит сложно, но давайте представим это проще. Представьте, что вы пишете книгу или код программы. Git — это ваша «машина времени». Он позволяет:

Сохранять «снимки» вашего проекта в определенные моменты времени.

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

Работать параллельно над разными функциями, не ломая основной код.

Видеть историю: кто, когда и зачем внес конкретное изменение.

Git был создан Линусом Торвальдсом (создателем Linux) в 2005 году. Сегодня это стандарт де-факто в мире разработки программного обеспечения.

!Сравнение хаотичного хранения версий файлов и структурированной истории в Git

Git против GitHub: в чем разница?

Новички часто путают эти понятия. Давайте раз и навсегда проведем черту.

* Git — это инструмент, программа, которая устанавливается на ваш компьютер. Это «движок», который следит за файлами. Он работает локально, даже без интернета. * GitHub (а также GitLab, Bitbucket) — это веб-сервис, «хостинг» для ваших проектов Git. Это как социальная сеть для кода, где вы храните копии своих репозиториев, чтобы работать в команде или показывать код другим.

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

В этом курсе мы начнем именно с Git (консольной утилиты), так как без понимания основ работы локально невозможно эффективно использовать GitHub.

Установка Git

Прежде чем начать, нам нужно установить Git на ваш компьютер. Процесс немного отличается для разных операционных систем.

Для пользователей Windows

Перейдите на официальный сайт git-scm.com.

Скачайте установочный файл (обычно сайт сам определяет разрядность вашей системы).

Запустите установщик. Важно: в процессе установки вам будет предложено множество опций. Для новичков рекомендуется оставлять все галочки по умолчанию, нажимая «Next», за одним исключением:

* На этапе выбора текстового редактора (Choosing the default editor used by Git), если вы не умеете пользоваться Vim, выберите Nano или Visual Studio Code, если он у вас установлен. Это сбережет вам нервы в будущем.

После установки у вас появится программа Git Bash. Это эмулятор терминала, который позволяет использовать команды Linux на Windows. Мы будем работать именно в нем.

Для пользователей macOS

Чаще всего Git уже установлен в macOS (как часть инструментов разработчика Xcode). Чтобы проверить это, откройте Терминал (Command + Space, введите «Terminal») и напишите:

Если система предложит установить инструменты разработчика — соглашайтесь. Альтернативный и более гибкий способ — использовать пакетный менеджер Homebrew. Если у вас есть Homebrew, введите:

Для пользователей Linux (Ubuntu/Debian)

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

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

Вы должны увидеть что-то вроде git version 2.34.1 (цифры могут отличаться).

Консоль: краткий ликбез

Вы просили помочь изучить git(cmd). Git — это консольная утилита. Хотя существуют графические интерфейсы (кнопки и меню), настоящий профессионал должен уметь работать через командную строку (терминал). Это дает полный контроль и понимание процессов.

Вот несколько базовых команд терминала (Bash), которые нам понадобятся для навигации перед тем, как мы вызовем Git:

* pwd (Print Working Directory) — показывает, в какой папке вы сейчас находитесь. * ls (List) — показывает список файлов и папок в текущей директории. (На Windows в Git Bash это тоже работает). * cd <название_папки> (Change Directory) — переход в другую папку. * mkdir <название_папки> (Make Directory) — создание новой папки.

Попробуйте открыть терминал (или Git Bash на Windows) и попрактиковаться:

Базовая настройка Git

После установки Git нужно «представиться». Каждый раз, когда вы будете сохранять изменения (делать коммит), Git будет записывать ваше имя и email как автора этих изменений. Это критически важно для истории проекта.

Эти настройки делаются один раз для всего компьютера (флаг --global).

1. Настройка имени пользователя

Введите команду, подставив свое имя (на латинице):

2. Настройка email

Введите свой реальный email (тот же, который вы планируете использовать для регистрации на GitHub):

3. Настройка ветки по умолчанию (опционально, но рекомендуется)

Исторически главная ветка в Git называлась master. В последние годы индустрия перешла на название main. Чтобы Git сразу создавал ветку main при инициализации новых проектов, выполните:

Проверка настроек

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

Вы увидите список, в котором должны быть строки user.name=... и user.email=.... Если вы ошиблись, просто введите команду настройки (git config ...) заново с правильными данными — старое значение перезапишется.

Инициализация проекта: git init

Теперь самое интересное. Давайте создадим наш первый репозиторий. Репозиторий (или «репо») — это папка с вашим проектом, которую отслеживает Git.

Предположим, мы уже находимся в папке git-course, которую создали ранее.

Команда инициализации

Чтобы сказать Git: «Эй, начни следить за этой папкой», нужно выполнить всего одну команду:

Если все прошло успешно, вы увидите сообщение:

Initialized empty Git repository in /путь/к/вашей/папке/.git/

Что произошло?

Визуально в папке ничего не изменилось. Ваши файлы (если бы они там были) остались на месте. Но на самом деле магия случилась. Git создал скрытую подпапку с именем .git.

!Скрытая папка .git — это «мозг» вашего репозитория

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

Важное правило: Никогда не удаляйте и не меняйте файлы внутри папки .git вручную, если не знаете точно, что делаете. Удаление этой папки превратит ваш проект обратно в обычную папку, и вся история изменений будет потеряна навсегда.

Чтобы увидеть эту скрытую папку в терминале, используйте команду ls с флагом -a (all):

Вы увидите . (текущая папка), .. (родительская папка) и .git.

Проверка состояния: git status

Это команда, которую вы будете использовать чаще всего. Она отвечает на вопрос: «Что сейчас происходит в моем репозитории?».

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

Вывод будет примерно таким:

Давайте разберем, что нам сказал Git:

On branch main: Мы находимся на главной ветке main.

No commits yet: В истории пока нет ни одного сохранения (коммита).

nothing to commit: Нет новых или измененных файлов, за которыми нужно следить (папка пуста).

Практическое задание: создаем первый файл

Давайте создадим простой текстовый файл, чтобы увидеть, как отреагирует Git.

Создайте файл hello.txt с любым текстом. Можно сделать это через обычный редактор или командой в терминале:

Снова проверьте статус:

Теперь вывод изменится:

Git увидел новый файл, но пометил его как Untracked (неотслеживаемый). Это значит, что Git видит файл, но пока не сохраняет его изменения в своей базе данных. Он ждет вашей команды, чтобы начать это делать.

Итоги

Поздравляю! Вы сделали первый шаг в мир профессиональной разработки.

Что мы узнали: * Git — это система для управления версиями файлов (машина времени). * Git работает локально, а GitHub — это облако для хранения репозиториев. * Настройка user.name и user.email обязательна для идентификации автора. * Команда git init создает репозиторий (скрытую папку .git). * Команда git status показывает текущее состояние проекта.

В следующей статье мы разберем, как именно сохранять изменения: мы изучим концепцию Staging Area (индекса), научимся делать коммиты и смотреть историю изменений.

Подготовьтесь, дальше будет еще интереснее!

Основы фиксации изменений: команды add, commit и просмотр истории

В предыдущей статье мы установили Git, настроили имя пользователя и инициализировали наш первый репозиторий. Мы даже создали файл hello.txt, и Git заметил его, пометив как Untracked (неотслеживаемый). Но сам файл всё ещё находится в «подвешенном» состоянии: Git видит его, но не хранит его историю.

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

Трехступенчатая архитектура Git

Прежде чем вводить команды, важно понять философию Git. В отличие от обычного сохранения в текстовом редакторе (Ctrl+S), где файл просто перезаписывается на диске, Git использует более сложную, но гибкую систему.

Процесс работы с файлами проходит через три основные зоны:

Рабочая директория (Working Directory). Это ваша папка с проектом, где вы пишете код, создаете и удаляете файлы. Это то, что вы видите в проводнике или редакторе кода.

Область подготовленных файлов (Staging Area / Index). Это промежуточная зона, «черновик» будущего сохранения. Сюда вы помещаете только те изменения, которые хотите сохранить в данный момент.

Репозиторий (Repository / .git directory). Это база данных Git, где навсегда хранятся ваши зафиксированные изменения (коммиты).

!Диаграмма, показывающая поток данных в Git от рабочей папки через индекс в репозиторий

Зачем нужен промежуточный этап?

Новички часто спрашивают: «Зачем мне делать git add, а потом git commit? Почему нельзя просто сохранить всё одной кнопкой?»

Представьте, что вы делаете покупки в онлайн-магазине: * Рабочая директория — это полки магазина. Вы ходите и смотрите товары. * Staging Area — это ваша корзина. Вы кладете туда только то, что собираетесь купить прямо сейчас. * Репозиторий — это оформленный заказ (чек). Это факт покупки, который уже нельзя изменить.

Этот промежуточный этап (корзина) позволяет вам гибко управлять тем, что попадет в историю. Вы можете изменить 10 файлов, но в один коммит добавить только 2 из них, которые относятся к исправлению конкретной ошибки, а остальные оставить для следующего коммита.

Команда git add: подготовка к сохранению

Вернемся к нашему файлу hello.txt, который мы создали в прошлой статье. Если вы введете git status, вы увидите его в разделе Untracked files.

Чтобы сказать Git: «Я хочу, чтобы этот файл попал в следующее сохранение», используется команда git add.

Добавление конкретного файла

Теперь снова проверим статус:

Вывод изменится:

Файл перешел из красного цвета (в большинстве терминалов) в зеленый. Он находится в Staging Area. Git сделал «снимок» этого файла и готов записать его в историю.

Добавление всех файлов сразу

В реальных проектах файлов могут быть сотни. Добавлять каждый по имени неудобно. Чтобы добавить в индекс все текущие изменения (новые, измененные и удаленные файлы) в текущей папке, используется точка:

> Важный нюанс: Команда git add фиксирует состояние файла на момент выполнения команды. Если после git add hello.txt вы снова откроете файл и допишете туда строчку, то в индекс (Staging Area) эта новая строчка не попадет автоматически. Вам нужно будет выполнить git add еще раз.

Команда git commit: фиксация изменений

Когда вы наполнили «корзину» (Staging Area) нужными файлами, пора оформлять «заказ». Это делается командой git commit.

Коммит (Commit) — это объект в базе данных Git, который содержит:

Снимок всех файлов проекта на данный момент.

Информацию об авторе (имя, email, время).

Ссылку на предыдущий коммит (родителя).

Уникальный идентификатор (хеш).

Сообщение (комментарий) автора.

Создание первого коммита

Самый простой способ сделать коммит — использовать флаг -m (message), чтобы сразу написать комментарий в кавычках:

Если команда прошла успешно, вы увидите примерно такой вывод:

Поздравляю! Вы создали свою первую точку сохранения.

Правила хорошего тона для сообщений коммитов

Сообщение коммита — это послание вашим коллегам (и вам будущему). Сообщение "fix" или "update" не несет никакой информации.

Хорошее сообщение должно отвечать на вопрос: «Что сделает этот коммит, если его применить?»

* Плохо: исправил баг, изменения, 123 * Хорошо: Исправить ошибку валидации email, Добавить кнопку входа на главную, Обновить документацию API

Принято использовать повелительное наклонение (Imperative mood): «Добавить», «Удалить», «Исправить», а не «Добавил» или «Исправлено». Но главное — чтобы было понятно.

Цикл работы: Edit -> Add -> Commit

Давайте закрепим материал практикой. Изменим наш файл.

Откройте hello.txt и измените текст на «Привет, Git! Это моя вторая версия.». Сохраните файл (Ctrl+S).

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

Вы увидите modified: hello.txt красным цветом. Git видит, что файл изменился относительно последнего коммита.

Добавьте изменения в индекс:

Сделайте коммит:

Теперь у нас в истории два «снимка» проекта.

Команда git log: просмотр истории

Как увидеть, что мы натворили? Для этого существует команда git log. Она показывает список всех коммитов в обратном хронологическом порядке (сверху — самые новые).

Введите в терминале:

Вы увидите что-то подобное:

Разбор вывода git log

Хеш коммита (commit hash): Длинная строка из цифр и букв (например, c5f6e7...). Это уникальный идентификатор коммита (SHA-1). По нему Git отличает одно состояние от другого.

HEAD -> main: Указатель HEAD говорит нам: «Вы сейчас находитесь здесь». Он указывает на последний коммит в ветке main.

Author и Date: Кто и когда сделал работу.

Сообщение: Текст, который вы писали после флага -m.

Компактный вид истории

Если коммитов много, полный вывод занимает слишком много места. Используйте флаг --oneline для краткого обзора:

Результат:

Здесь мы видим только сокращенный хеш (первые 7 символов, которых обычно достаточно для идентификации) и сообщение.

Что делать, если забыли -m?

Если вы введете просто git commit без -m и нажмете Enter, Git решит, что вы хотите написать длинное и подробное сообщение, и откроет текстовый редактор по умолчанию.

* Если это Vim (страшный сон новичка): вы увидите экран с тильдами ~. Чтобы выйти, не сохраняясь, нажмите Esc, затем наберите :q! и нажмите Enter. Чтобы сохранить: нажмите i (режим вставки), напишите текст, нажмите Esc, наберите :wq и Enter. * Если это Nano: просто напишите текст, нажмите Ctrl+O (сохранить), Enter, и Ctrl+X (выйти).

Именно поэтому в первой статье мы рекомендовали настроить редактор заранее.

Резюме

Сегодня мы освоили фундаментальный цикл работы в Git:

Изменяем файлы в рабочей директории.

git status — проверяем, что изменилось.

git add <файл> или git add . — переносим изменения в Staging Area (индекс).

git commit -m "Сообщение" — фиксируем изменения в истории репозитория.

git log — любуемся историей своей работы.

Теперь вы умеете создавать историю проекта. Но что делать, если вы совершили ошибку и хотите вернуться назад? Или как работать над новой функцией, не ломая старую? Об этом мы поговорим в следующих статьях курса, когда будем разбирать отмену изменений и ветвление.

Магия ветвления: создание, переключение и слияние веток

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

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

Звучит как кошмар, верно? Здесь на сцену выходит главная суперсила Git — ветвление.

Что такое ветки и зачем они нужны?

Ветвление (Branching) — это возможность отклониться от основной линии разработки, чтобы поработать над чем-то другим, не затрагивая основной код. Представьте это как создание параллельной вселенной.

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

!Визуализация того, как ветка feature ответвляется от main, развивается параллельно, а затем сливается обратно.

По умолчанию в каждом репозитории есть одна главная ветка. Раньше она называлась master, сейчас стандартом стало имя main.

Управление ветками: создание и просмотр

Давайте вернемся к нашему проекту из прошлых уроков. Откройте терминал в папке проекта.

Просмотр существующих веток

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

Скорее всего, вы увидите:

Звездочка * указывает на текущую активную ветку. Сейчас она одна.

Создание новой ветки

Допустим, мы хотим написать новый раздел для нашей книги или добавить новую функцию в программу. Назовем эту ветку new-feature.

Если вы снова введете git branch, вы увидите:

Ветка создана! Но обратите внимание: звездочка всё ещё стоит напротив main. Команда git branch только создает ветку, но не переключает вас на неё автоматически.

Переключение между ветками

Чтобы начать работать в новой ветке, нужно в неё перейти. Для этого исторически использовалась команда checkout, но в современных версиях Git (начиная с 2.23) появилась более интуитивная команда switch.

Использование git switch

Терминал ответит: Switched to branch 'new-feature'.

Теперь любые коммиты, которые вы сделаете, будут записываться в историю ветки new-feature, а ветка main останется нетронутой на том месте, где мы её оставили.

> Примечание для любознательных: Вы часто будете встречать в старых инструкциях команду git checkout new-feature. Она делает то же самое. Однако checkout — это «швейцарский нож», который умеет делать слишком много вещей (и ветки менять, и файлы восстанавливать), поэтому разработчики Git решили разделить этот функционал. Для переключения веток лучше использовать switch.

Лайфхак: создание и переключение одной командой

Очень часто нам нужно создать ветку и сразу перейти в неё. Чтобы не писать две команды, используйте флаг -c (create):

Эта команда создаст ветку experiment и сразу переключит вас на неё.

Практика: работа в параллельных вселенных

Давайте убедимся, что это действительно работает как магия.

Убедитесь, что вы в новой ветке (например, new-feature): git branch должен показать звездочку у new-feature.

Создайте новый файл feature.txt:

Зафиксируйте изменения:

Проверьте список файлов:

Вы увидите hello.txt (из прошлых уроков) и feature.txt.

А теперь — фокус. Вернемся в главную ветку:

Снова проверьте список файлов:

Файл feature.txt исчез!

Не пугайтесь. Git просто убрал его из вашей рабочей папки, потому что в ветке main этого файла никогда не существовало. Вы вернулись в прошлое (или в параллельную реальность), где этой работы еще не было сделано.

Если вы снова введете git switch new-feature, файл волшебным образом появится на месте.

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

Слияние веток (Merge)

Предположим, мы закончили работу над новой функцией в ветке new-feature. Мы протестировали её, и она нам нравится. Теперь мы хотим перенести эти изменения в главную ветку main.

Этот процесс называется слиянием (merging).

Золотое правило слияния

> Чтобы слить ветку B в ветку A, вы должны находиться в ветке A.

То есть, мы «втягиваем» изменения в ту ветку, на которой стоим.

Перейдите в ветку, в которую хотите добавить изменения (обычно это main):

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

Типы слияния

Git умен. В зависимости от ситуации, слияние может пройти по двум сценариям.

#### 1. Fast-forward (Перемотка)

Если вы создали ветку new-feature от main, сделали в ней пару коммитов, а в ветке main за это время ничего не происходило, Git просто «передвинет» указатель ветки main вперед, на тот же коммит, где заканчивается new-feature.

Это самый простой вариант. История остается линейной.

#### 2. Трехстороннее слияние (3-way merge)

Если пока вы работали в new-feature, кто-то (или вы сами) успел сделать другие коммиты в main, истории разошлись.

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

В этом случае Git:

Берет последний коммит ветки main.

Берет последний коммит ветки new-feature.

Находит их общего предка (место, где ветки разошлись).

Пытается объединить изменения и создает специальный коммит слияния (Merge Commit).

При таком слиянии Git попросит вас ввести сообщение для коммита (обычно оно подставляется автоматически: Merge branch 'new-feature').

Удаление веток

После того как вы успешно слили ветку new-feature в main, сама ветка new-feature больше не нужна. Код уже сохранен в main. Чтобы не засорять список веток, хорошей практикой считается удалять отработанные ветки.

Флаг -d (delete) безопасен: Git не даст удалить ветку, если в ней есть изменения, которые еще не были слиты в текущую ветку. Если вы точно знаете, что делаете, и хотите удалить ветку принудительно (например, эксперимент не удался), используйте заглавную -D.

Итоги

Сегодня мы освоили мощнейший инструмент Git.

Что мы узнали: * git branch — показывает список веток. * git branch <имя> — создает новую ветку. * git switch <имя> — переключает на другую ветку. * git switch -c <имя> — создает и сразу переключает. * git merge <имя> — сливает указанную ветку в текущую. * git branch -d <имя> — удаляет ветку.

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

Однако, идиллия бывает не всегда. Иногда Git не может сам решить, как объединить изменения (например, если в двух ветках вы изменили одну и ту же строку кода по-разному). Это называется конфликтом слияния. О том, как разрешать такие конфликты и не паниковать при виде странных символов <<<<<<< HEAD, мы поговорим в следующей статье.

Работа с GitHub: подключение удаленного репозитория, push и pull

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

Представьте, что ваш жесткий диск внезапно вышел из строя. Или вы хотите показать свой код другу. Или, что еще интереснее, вы хотите работать над проектом вместе с командой. Локальный Git здесь не поможет. Нам нужно выйти в интернет.

В этой статье мы свяжем наш локальный репозиторий с GitHub — самым популярным в мире хостингом для IT-проектов. Мы разберем, как отправлять свой код в «облако» и как забирать его оттуда.

Локальный и удаленный репозитории: в чем суть?

До этого момента ваш репозиторий (папка .git) жил только у вас. Удаленный репозиторий (Remote Repository) — это копия вашего проекта, которая хранится на сервере (в нашем случае — на серверах GitHub).

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

!Визуализация процесса обмена данными между локальным и удаленным репозиториями.

Основные операции, которые мы сегодня изучим:

Push (Толкать) — отправка ваших локальных коммитов на сервер.

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

Шаг 1: Создание репозитория на GitHub

Прежде чем что-то отправлять, нужно подготовить место назначения.

Зайдите на сайт github.com и войдите в свой аккаунт.

В правом верхнем углу найдите значок + и выберите New repository (Новый репозиторий).

Вы попадете на форму создания:

* Repository name: Придумайте имя (например, git-course-project). Оно должно быть уникальным в рамках вашего аккаунта. * Description: Опциональное описание (например, «Мой учебный проект по Git»). * Public/Private: Выберите Public, если хотите, чтобы код видели все (бесплатно), или Private, если хотите скрыть его. * Initialize this repository with: ВАЖНО! Оставьте все галочки (Add a README, .gitignore, License) пустыми.

Почему пустыми? Потому что у нас уже есть локальный проект с файлами. Если мы создадим пустой репозиторий на GitHub, нам будет проще их связать. Если же мы создадим там файлы сразу, возникнет конфликт историй, который новичку разрешить сложно.

Нажмите кнопку Create repository.

Шаг 2: Связывание локального и удаленного репозитория

После создания GitHub покажет вам страницу с инструкциями. Нас интересует блок с заголовком …or push an existing repository from the command line.

Там будет команда, похожая на эту:

Давайте разберем, что это значит.

Анатомия команды git remote

* git remote — команда для управления списком удаленных соединений. * add — добавить новое соединение. * origin — это имя (псевдоним) для удаленного репозитория. Исторически сложилось, что основной удаленный сервер называют origin. Вы могли бы назвать его github, server или cloud, но origin — это стандарт. * https://... — это URL-адрес, по которому Git будет искать ваш репозиторий.

Скопируйте эту команду со страницы GitHub, вставьте в свой терминал (находясь в папке проекта) и нажмите Enter.

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

Флаг -v (verbose) покажет подробности. Вы должны увидеть что-то вроде:

Это значит, что Git теперь знает: «Когда хозяин говорит origin, он имеет в виду вот этот адрес».

Шаг 3: Отправка изменений (git push)

Теперь самое волнительное. Отправим нашу историю коммитов (которую мы создавали в прошлых уроках) на сервер.

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

Разберем её: * push — отправить изменения. * origin — куда отправляем (мы только что настроили это имя). * main — какую ветку отправляем. * -u (или --set-upstream) — этот флаг очень важен для первого раза. Он связывает вашу локальную ветку main с веткой main на удаленном сервере.

Благодаря флагу -u, в будущем вам не придется писать длинную команду. Достаточно будет писать просто git push, и Git сам поймет, что main нужно толкать в origin.

Вопрос аутентификации

При выполнении этой команды Git попросит подтвердить, что вы — это вы.

Важное примечание: С 2021 года GitHub отключил поддержку обычных паролей от аккаунта в консоли ради безопасности.

Если Git просит пароль, у вас есть два пути:

Personal Access Token (PAT). В настройках GitHub (Settings -> Developer settings -> Personal access tokens) можно сгенерировать токен (длинный набор символов). Его нужно вставлять вместо пароля.

SSH-ключи. Это более профессиональный способ. Вы генерируете пару ключей на компьютере и добавляете публичный ключ в настройки GitHub. Тогда Git будет узнавать ваш компьютер автоматически без ввода паролей.

Если вы используете Windows и устанавливали Git с настройками по умолчанию, скорее всего, всплывет окно браузера или специальное окошко Git Credential Manager, где можно просто нажать «Sign in with browser» и авторизоваться привычным способом.

Если всё прошло успешно, терминал выдаст отчет о передаче объектов, и в конце будет сказано:

Branch 'main' set up to track remote branch 'main' from 'origin'.

Теперь обновите страницу вашего репозитория на сайте GitHub. Вы увидите свои файлы (hello.txt и другие) и историю коммитов!

Шаг 4: Получение изменений (git pull)

Представьте ситуацию: вы поработали над кодом с домашнего компьютера и отправили изменения (git push). Пришли на работу (или в университет), сели за другой компьютер. Как продолжить работу?

Клонирование (git clone)

Если на втором компьютере проекта еще нет, его нужно клонировать. Это делается один раз.

На странице репозитория GitHub нажмите зеленую кнопку Code и скопируйте ссылку.

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

Git создаст папку с именем проекта, скачает туда все файлы и всю историю изменений (папку .git). Проект полностью готов к работе.

Подтягивание изменений (git pull)

Теперь другая ситуация. Вы работаете в команде с коллегой Василием.

Василий сделал коммит и выполнил git push.

На GitHub код обновился.

Но у вас на компьютере код старый.

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

Эта команда делает две вещи:

Скачивает новые данные с сервера (аналог команды git fetch).

Пытается слить (merge) их с вашей текущей веткой.

Если вы не меняли те же строки, что и Василий, обновление пройдет гладко. Если меняли — возникнет конфликт, который нужно будет решить (так же, как мы обсуждали при слиянии веток).

Идеальный рабочий цикл (Workflow)

Теперь, когда у нас подключен GitHub, наш цикл разработки выглядит так:

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

Работаем — пишем код, меняем файлы.

git add . — добавляем изменения в индекс.

git commit -m "..." — фиксируем изменения локально.

git push — отправляем изменения на сервер, чтобы их увидели другие (или чтобы сохранить резервную копию).

Решение частых проблем

Ошибка "rejected - non-fast-forward"

Если вы пытаетесь сделать git push, а Git ругается красным текстом:

! [rejected] main -> main (fetch first) error: failed to push some refs to...

Это значит, что на сервере есть изменения, которых нет у вас. Кто-то (или вы с другого компьютера) уже успел обновить ветку. Git запрещает вам перезаписывать историю, чтобы не потерять чужой код.

Решение: Сначала сделайте git pull, чтобы забрать изменения и объединить их со своими, и только потом делайте git push.

Итоги

Поздравляю! Теперь ваш код живет не только на вашем ноутбуке, но и в надежном облачном хранилище.

Что мы узнали: * git remote add origin <url> — подключает удаленный репозиторий. * git push -u origin main — отправляет ветку на сервер и запоминает связь. * git push — отправляет новые коммиты. * git clone <url> — скачивает репозиторий целиком (для старта на новом месте). * git pull — скачивает обновления и сливает их с текущей веткой.

В следующей статье мы углубимся в командную работу и узнаем, что такое Pull Requests — главный инструмент вежливого внесения изменений в чужие проекты.

Командная разработка: разрешение конфликтов, .gitignore и Pull Requests

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

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

В этой статье мы разберем три кита командной разработки: файл .gitignore, разрешение конфликтов слияния и культуру Pull Requests.

Гигиена репозитория: файл .gitignore

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

* Логи (файлы с расширением .log). * Временные файлы системы (например, печально известный .DS_Store на macOS или Thumbs.db на Windows). * Папки с зависимостями (огромная папка node_modules в JavaScript или venv в Python). * Файлы с настройками редактора (папка .idea или .vscode). * Файлы с секретными ключами и паролями (например, .env).

Запомните правило: В репозитории должен храниться только исходный код и ресурсы, необходимые для запуска проекта. Мусору там не место.

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

Как работает .gitignore?

Git использует специальный текстовый файл с именем .gitignore (точка в начале обязательна), чтобы знать, какие файлы нужно игнорировать. Этот файл должен лежать в корне вашего проекта.

!Визуализация принципа работы .gitignore как фильтра для файлов

Создание и настройка

Создайте файл .gitignore в корневой папке проекта (там же, где лежит папка .git).

Откройте его в любом текстовом редакторе.

Впишите правила игнорирования.

Пример содержимого .gitignore:

После сохранения этого файла, если вы введете git status, Git перестанет показывать перечисленные файлы как Untracked. Он просто сделает вид, что их не существует.

> Важный нюанс: .gitignore работает только для файлов, которые еще не отслеживаются Git. Если вы уже успели закоммитить файл secret.txt, а потом добавили его в игнор, Git продолжит следить за ним. Чтобы убрать его из истории, потребуется специальная команда удаления из индекса (git rm --cached). Поэтому создавайте .gitignore в самом начале проекта.

Конфликты слияния: не так страшен черт

Теперь перейдем к самому большому страху новичков. Вы работаете в ветке main, ваш коллега работает в ветке feature. Вы оба решили исправить заголовок на главной странице. Вы написали «Добро пожаловать», а коллега — «Привет всем».

Вы пытаетесь сделать git merge, и Git впадает в ступор. Он не может выбрать, чей вариант правильный. Это и есть конфликт слияния (Merge Conflict).

Как распознать конфликт?

При попытке слияния (git merge или git pull) терминал выдаст сообщение:

Git говорит: «Я пытался, но не смог. Человек, помоги мне».

Если вы введете git status, вы увидите:

Анатомия конфликта

Откройте конфликтный файл (index.html) в редакторе. Вы увидите, что Git добавил туда специальные маркеры:

Давайте расшифруем эти иероглифы:

<<<<<<< HEAD: Начало ваших изменений (то, что было в текущей ветке).

Содержимое между HEAD и ======= — это ваш код.

=======: Разделитель. Экватор конфликта.

Содержимое между ======= и >>>>>>> — это код, который пришел из другой ветки (входящие изменения).

>>>>>>> feature-branch: Конец блока конфликта с указанием имени входящей ветки.

!Разбор структуры маркеров конфликта Git

Алгоритм разрешения конфликта

Git не может решить за вас, какой заголовок лучше. Это должны сделать вы.

Редактирование: Прямо в редакторе удалите маркеры (<<<<, ====, >>>>) и оставьте тот текст, который считаете правильным. Вы можете оставить свой вариант, вариант коллеги или объединить их.

Было: Стало (вы решили объединить):

Добавление в индекс: Сохраните файл и скажите Git, что конфликт решен:

Фиксация: Завершите слияние созданием коммита:

Обычно сообщение коммита генерируется автоматически («Merge branch...»), можно просто оставить его как есть.

Вот и всё! Конфликт исчерпан, история продолжилась.

Pull Requests: этикет командной работы

Если вы работаете в команде, прямой push в главную ветку main часто запрещен. Почему? Потому что любой может случайно сломать рабочий проект.

Вместо этого используется механизм Pull Request (PR, Пул-реквест) на GitHub (в GitLab это называется Merge Request).

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

Жизненный цикл Pull Request

Представим, что вы хотите добавить новую функцию.

Создайте ветку: Всегда начинайте с новой ветки.

Работайте: Пишите код, делайте коммиты.

Отправьте ветку на GitHub:

Откройте PR:

Зайдите на страницу репозитория на GitHub. Обычно вы сразу увидите желтую плашку «new-feature had recent pushes». Нажмите кнопку Compare & pull request.

!Интерфейс создания Pull Request на GitHub

Опишите изменения: В открывшейся форме напишите заголовок и описание. Объясните, что вы сделали и зачем. Это поможет коллегам быстрее проверить вашу работу.

Code Review (Проверка кода):

Это самый важный этап. Ваши коллеги заходят в вкладку «Files changed», смотрят ваш код и оставляют комментарии. * «Здесь можно оптимизировать». * «Ты забыл точку с запятой». * «Отличная работа!» Вы исправляете замечания (делаете новые коммиты в ту же ветку и снова push), и PR обновляется автоматически.

Merge:

Когда все проверки пройдены и коллеги поставили «Approve» (Одобрено), кнопка Merge pull request становится зеленой. Нажав её, вы сливаете изменения в main на сервере.

Зачем это нужно?

* Качество кода: Одна голова хорошо, а две лучше. Коллеги могут заметить ошибки, которые вы пропустили. * Безопасность: Главная ветка всегда остается стабильной. * Обмен знаниями: Читая чужой код, вы учитесь новым приемам.

Итоги курса

Поздравляем! Вы прошли путь от инициализации первого репозитория до профессионального рабочего процесса с Pull Requests.

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

Git — это инструмент с огромными возможностями. Мы изучили фундамент, на котором строится 90% ежедневной работы любого программиста. Дальше вас ждет только практика. Не бойтесь ошибаться, ведь Git для того и создан, чтобы всегда можно было всё исправить.

Удачи в ваших коммитах!