Основы Git и GitHub: от установки до командной разработки

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

Добро пожаловать в курс «Основы Git и GitHub». Если вы когда-либо сохраняли файлы с именами диплом_финал.docx, диплом_финал_точно_последний.docx и диплом_исправленный_v2.docx, то вы уже пытались создать свою систему контроля версий. К сожалению, такой подход быстро приводит к хаосу. Сегодня мы познакомимся с инструментом, который решает эту проблему профессионально — Git.

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

Git — это распределенная система контроля версий (Version Control System, VCS). Она позволяет отслеживать изменения в файлах, возвращаться к предыдущим состояниям проекта и работать над кодом совместно с другими людьми, не боясь перезаписать чужую работу.

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

!Визуализация процесса работы Git: линейная история изменений и ветвление.

Git против GitHub

Важно сразу разграничить два понятия, которые новички часто путают:

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

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

Установка Git

Прежде чем начать, нам нужно установить Git. Процесс зависит от вашей операционной системы.

Windows

Для пользователей Windows самым простым способом является установка Git Bash.

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

Скачайте установочный файл.

Запустите установку. Вы можете оставить все настройки по умолчанию, нажимая «Next», пока установка не завершится.

После установки у вас появится программа Git Bash — это терминал, в котором мы будем вводить команды.

macOS

На компьютерах Mac Git часто уже установлен. Откройте терминал и введите:

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

Linux (Ubuntu/Debian)

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

Чтобы убедиться, что установка прошла успешно, введите команду проверки версии в терминале (или Git Bash на Windows):

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

Глобальная настройка Git

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

Мы будем использовать команду git config с флагом --global, что означает применение настроек для всех ваших проектов.

Настройка имени и почты

Введите в терминале следующие команды, подставив свои данные:

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

Настройка ветки по умолчанию

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

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

Чтобы убедиться, что все настроено верно, выведите список всех конфигураций:

Вы должны увидеть введенные вами user.name и user.email в списке.

Инициализация локального репозитория

Теперь, когда инструмент готов к работе, давайте создадим наш первый проект под управлением Git.

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

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

Команда mkdir создает папку, а cd осуществляет переход внутрь нее.

Команда git init

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

После выполнения вы увидите сообщение: Initialized empty Git repository in...

Что произошло? В вашей папке появилась скрытая подпапка .git. Именно в ней Git хранит всю историю изменений, конфигурации и служебную информацию. Если вы удалите папку .git, вы потеряете всю историю версий, и проект снова станет обычной папкой с файлами.

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

Чтобы понимать, как сохранять изменения, нужно разобраться в фундаментальной концепции Git — трех состояниях (или трех зонах).

!Схема движения файлов: из рабочей директории в индекс, а затем в репозиторий.

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

Индекс (Staging Area): Это зона подготовки. Сюда мы помещаем файлы, которые хотим включить в следующее сохранение. Представьте, что вы собираете посылку: вы кладете вещи в коробку (Staging Area), но еще не заклеили её скотчем и не отправили.

Репозиторий (Repository): Место, где Git навсегда сохраняет «снимки» ваших файлов. Это уже «отправленная посылка».

Первый цикл работы: Status, Add, Commit

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

1. Проверка статуса

Команда git status — ваш лучший друг. Она показывает, в каком состоянии находятся файлы.

Сейчас она скажет, что коммитить нечего (nothing to commit).

2. Создание файла

Создадим простой текстовый файл hello.txt:

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

Теперь Git видит файл hello.txt, но он помечен красным цветом (в большинстве терминалов) и находится в секции Untracked files (неотслеживаемые файлы). Git видит файл, но пока не следит за его изменениями.

3. Добавление в индекс (git add)

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

Если файлов много, можно добавить все сразу командой git add . (точка означает «текущая папка»).

Снова проверим git status. Файл стал зеленым и находится в секции Changes to be committed. Он в «Индексе» (Staging Area).

4. Создание коммита (git commit)

Теперь зафиксируем изменения. Это и есть создание «точки сохранения». Каждый коммит обязательно должен иметь сообщение, описывающее, что было сделано.

Флаг -m позволяет написать сообщение сразу в командной строке.

5. Просмотр истории (git log)

Чтобы убедиться, что сохранение прошло успешно, посмотрим историю:

Вы увидите уникальный идентификатор коммита (хеш), автора (ваше имя и email, которые мы настроили), дату и сообщение коммита.

Резюме

В этой статье мы:

Установили Git.

Выполнили глобальную настройку (git config).

Инициализировали репозиторий (git init).

Разобрали цикл работы: изменение git add git commit.

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

Базовые команды: жизненный цикл файлов, создание коммитов и работа с историей изменений

В предыдущей статье мы установили Git, настроили его и инициализировали наш первый репозиторий. Теперь у нас есть пустая папка с скрытой директорией .git, готовая к работе. Но как именно Git отслеживает файлы? Почему нельзя просто нажать «Сохранить» как в текстовом редакторе?

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

Жизненный цикл файлов

Главное отличие Git от простого копирования файлов — это понятие статуса файла. Каждый файл в вашей рабочей директории может находиться в одном из двух глобальных состояний: отслеживаемый (tracked) и неотслеживаемый (untracked).

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

Неизмененные (Unmodified): файл не менялся с момента последнего коммита.

Измененные (Modified): файл был отредактирован, но изменения еще не зафиксированы.

Подготовленные (Staged): измененный файл отмечен для включения в следующий коммит.

!Схема жизненного цикла файла: переходы между состояниями.

Понимание этой схемы критически важно. Многие новички совершают ошибку, думая, что команда git commit сохраняет все изменения. На самом деле она сохраняет только то, что находится в состоянии Staged.

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

Команда git status — это ваша приборная панель. Она показывает, что происходит в репозитории прямо сейчас. Давайте посмотрим на примере.

Предположим, у нас есть файл README.md, который мы только что создали.

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

Git сообщает, что файл README.md является Untracked. Это значит, что Git видит файл, но пока не несет за него ответственности. Если вы удалите его сейчас, Git не сможет его восстановить.

Индексация изменений: git add

Чтобы Git начал отслеживать файл или чтобы зафиксировать изменения в уже отслеживаемом файле, используется команда git add. Она переносит файл из рабочей директории в область подготовленных файлов (Staging Area).

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

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

Файл теперь находится в секции Changes to be committed (изменения, подлежащие фиксации). Он Staged.

Массовое добавление

В реальной работе мы редко добавляем файлы по одному. Если вы изменили 10 файлов, писать git add для каждого утомительно. Используйте точку . для добавления всех изменений в текущей папке:

> Будьте осторожны с командой git add .. Она добавляет абсолютно все файлы, включая те, которые вы, возможно, не хотели бы коммитить (например, временные файлы настроек или логи).

Просмотр конкретных изменений: git diff

Часто бывает так: вы изменили файл, добавили его в индекс (git add), а потом снова отредактировали. В каком состоянии он находится?

Давайте изменим README.md еще раз после добавления в индекс:

Теперь Git покажет файл README.md в двух местах одновременно: и в Changes to be committed, и в Changes not staged for commit. Это происходит потому, что Git индексирует файл в том состоянии, в котором он был в момент выполнения команды git add.

Чтобы увидеть, что именно изменилось, используется команда git diff.

* git diff (без аргументов): показывает разницу между рабочей директорией и индексом (то, что вы изменили, но еще не добавили). * git diff --staged: показывает разницу между индексом и последним коммитом (то, что вы уже добавили и собираетесь закоммитить).

Это мощный инструмент самопроверки перед созданием коммита.

Фиксация изменений: git commit

Когда вы подготовили все необходимые файлы в Staging Area, пришло время создать «снимок» — коммит.

Правила хорошего тона при написании сообщений

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

Будьте кратки, но информативны. «Исправил баг» — плохо. «Исправил ошибку деления на ноль в калькуляторе» — хорошо.

Используйте повелительное наклонение. Традиционно в Git сообщения пишут так, будто они приказывают: «Add file» (Добавить файл), «Fix bug» (Исправить баг), а не «Added» или «Fixed».

Не пишите пустые сообщения. Git по умолчанию даже не позволит создать коммит без сообщения.

Пропуск индексации: флаг -a

Если вы работаете с уже отслеживаемыми файлами и хотите пропустить этап git add, можно использовать флаг -a в команде коммита:

Эта команда автоматически найдет все измененные (Modified) файлы, добавит их в индекс и создаст коммит. Однако она не добавит новые (Untracked) файлы.

Игнорирование файлов: .gitignore

В любом проекте есть файлы, которые не должны попадать в репозиторий: временные файлы, логи, скомпилированные бинарные файлы, папки с зависимостями (например, node_modules или venv).

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

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

Файлы, описанные в .gitignore, не будут отображаться в git status как Untracked.

Просмотр истории: git log

После того как вы сделали несколько коммитов, вам захочется посмотреть историю проекта. Для этого служит команда git log.

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

Вы увидите: * Хеш коммита (длинная строка из цифр и букв, например commit ca82a6d...). Это уникальный идентификатор. * Автор: имя и почта. * Дата. * Сообщение.

Полезные флаги для git log

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

Краткий формат:

Выводит каждый коммит одной строкой: сокращенный хеш и сообщение.

Статистика изменений:

Показывает, какие файлы были изменены и сколько строк добавлено/удалено.

Отображение патча:

Показывает полный diff для каждого коммита (что конкретно менялось внутри файлов).

Граф истории (полезно при наличии веток):

!Визуализация истории изменений в консоли с помощью флага --graph.

Удаление и перемещение файлов

Можно удалять и переименовывать файлы через проводник операционной системы, но тогда Git увидит это как два действия: удаление старого файла и создание нового (при переименовании). Чтобы сделать это «чисто», используйте команды Git.

Удаление: git rm

Команда git rm удаляет файл из индекса и с жесткого диска:

Если вы хотите удалить файл только из под контроля Git (убрать из индекса), но оставить на диске (например, вы забыли добавить его в .gitignore), используйте флаг --cached:

Перемещение и переименование: git mv

Git не отслеживает перемещение файлов явно, но команда git mv упрощает процесс:

Это эквивалентно последовательности команд: mv (в системе), git rm (старого файла) и git add (нового файла).

Отмена изменений (Базовый уровень)

Что делать, если вы ошиблись?

Отмена изменений в рабочей директории

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

Внимание: эта команда безвозвратно удаляет ваши незакоммиченные изменения в файле.

Исключение из индекса (Unstaging)

Если вы случайно добавили файл через git add, но не хотите его коммитить:

Файл вернется из состояния Staged в состояние Modified (или Untracked, если он был новым).

Заключение

Сегодня мы освоили фундамент работы с Git. Мы разобрали: * Как файлы путешествуют между состояниями Untracked, Modified и Staged. * Как использовать git status для контроля ситуации. * Как фиксировать изменения с git commit. * Как просматривать историю через git log. * Как настраивать игнорирование файлов через .gitignore.

Эти команды покрывают 90% ежедневной работы разработчика. В следующей статье мы перейдем к одной из самых мощных возможностей Git — ветвлению (branching), которое позволяет работать над разными задачами параллельно, не мешая основной версии проекта.

Полезные ссылки

* Официальная документация Git (на русском) * Интерактивный тренажер Git

Ветвление и слияние: стратегии работы с ветками и разрешение конфликтов в коде

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

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

Для решения этой проблемы в Git существует механизм ветвления (branching). Это одна из самых мощных возможностей Git, которая позволяет создавать параллельные версии проекта.

Что такое ветка в Git?

Технически, ветка (branch) в Git — это просто подвижный указатель на один из коммитов. Когда вы создаете коммиты, этот указатель автоматически сдвигается вперед.

По умолчанию в каждом репозитории есть одна главная ветка, которая обычно называется main (или master в старых версиях). Но вы можете создать сколько угодно дополнительных веток.

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

!Визуализация концепции ветвления: основная ветка и ответвление для новой задачи.

Управление ветками

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

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

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

Вы увидите список, где текущая ветка отмечена звездочкой * и часто выделена цветом.

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

Допустим, мы хотим начать работу над новой функцией — формой регистрации. Создадим для этого ветку feature-registration:

Эта команда создает новый указатель на текущий коммит, но не переключает вас на него. Вы все еще находитесь в ветке main.

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

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

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

> Совет: Чтобы создать ветку и сразу переключиться на нее одной командой, используйте флаг -c (create): > git switch -c feature-registration

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

Вы закончили работу над функцией в отдельной ветке. Вы написали код, протестировали его и сделали несколько коммитов. Теперь эти изменения нужно вернуть в основную ветку main. Этот процесс называется слиянием или мержем (merge).

Процесс слияния всегда состоит из двух шагов:

Переключиться на ветку, в которую вы хотите принять изменения (обычно это main).

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

Существует два основных сценария того, как пройдет слияние.

Сценарий 1: Fast-forward (Перемотка)

Если вы создали ветку feature, сделали в ней коммиты, а в ветке main за это время не появилось новых коммитов, Git просто перенесет указатель main вперед, к последнему коммиту ветки feature. Это называется Fast-forward.

В этом случае история остается линейной, просто «удлиняется».

Сценарий 2: Recursive Merge (Рекурсивное слияние)

Ситуация становится интереснее, если история разошлась. Например:

Вы создали ветку feature и сделали там коммит A.

Ваш коллега в это же время сделал коммит B в ветку main.

Теперь main не может просто «догнать» feature, потому что у них разные пути развития.

!Схема рекурсивного слияния, когда истории веток разошлись.

В этом случае Git создаст специальный коммит слияния (merge commit). У этого коммита будет два родителя: последний коммит из main и последний коммит из feature. Git автоматически объединит изменения из обеих веток.

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

Иногда Git не может объединить ветки автоматически. Это происходит, когда в обеих ветках была изменена одна и та же строка в одном и том же файле.

Git останавливает процесс слияния и сообщает о конфликте:

Как разрешить конфликт?

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

* Всё, что между <<<<<<< HEAD и ======= — это то, что сейчас в вашей текущей ветке (main). * Всё, что между ======= и >>>>>>> feature... — это то, что пришло из вливаемой ветки.

Ваша задача — вручную отредактировать файл:

Удалить маркеры (<<<<<<<, =======, >>>>>>>).

Оставить тот вариант кода, который вы считаете правильным (или объединить их).

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

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

После того как вы исправили все конфликтные файлы, нужно сообщить об этом Git:

Добавьте исправленные файлы в индекс:

Создайте коммит слияния:

Обычно сообщение для такого коммита генерируется автоматически, вам достаточно просто сохранить его.

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

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

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

Стратегии работы (Git Flow)

В профессиональных командах хаотичное создание веток не приветствуется. Существуют стандарты, описывающие, как именовать ветки и когда их сливать. Самый популярный подход — Git Flow или его упрощенная версия GitHub Flow.

Основные правила хорошего тона: * main — всегда содержит рабочий, готовый к релизу код. Нельзя коммитить сырой код прямо в main. * feature/ — ветки для новых функций (например, feature/login-page). Создаются от main, сливаются обратно в main. * bugfix/ — ветки для исправления ошибок.

Резюме

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

Создавать «параллельные вселенные» для безопасной работы над кодом (git branch, git switch).

Объединять результаты работы (git merge).

Разрешать конфликты, когда Git не может выбрать правильный вариант кода сам.

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

Интеграция с GitHub: работа с удаленными репозиториями, клонирование и синхронизация изменений

До этого момента мы работали с Git исключительно на вашем локальном компьютере. Вы создавали коммиты, ветки и сливали их, но всё это происходило в пределах одной папки на жестком диске. Это отлично защищает от случайных ошибок (Ctrl+Z на стероидах), но не спасает от поломки жесткого диска и не позволяет работать в команде.

Сегодня мы сделаем следующий большой шаг: подключим наш локальный проект к удаленному репозиторию (remote repository) на GitHub. Это позволит вам создавать резервные копии кода в «облаке» и синхронизировать работу между разными компьютерами.

Локальный и удаленный репозитории

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

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

* Локальный репозиторий (Local): Находится на вашем компьютере. Здесь вы работаете, делаете коммиты и экспериментируете. * Удаленный репозиторий (Remote): Находится на сервере (в нашем случае — на GitHub). Это «общая правда» проекта. Сюда вы отправляете готовые изменения и отсюда забираете чужой код.

Подключение существующего проекта к GitHub

Предположим, у вас уже есть локальный проект (тот самый, который мы создавали в прошлых уроках), и вы хотите загрузить его на GitHub.

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

Зайдите на сайт GitHub и авторизуйтесь.

В правом верхнем углу нажмите на иконку + и выберите New repository.

Придумайте имя репозитория (например, my-first-project). Оно может совпадать с именем папки на компьютере, но это не обязательно.

Выберите тип: Public (виден всем) или Private (виден только вам).

Важно: Не ставьте галочки напротив «Add a README file», «Add .gitignore» или «Choose a license». Мы импортируем существующий репозиторий, поэтому нам нужен абсолютно пустой проект на сервере.

Нажмите Create repository.

Шаг 2: Связывание репозиториев (git remote)

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

Скопируйте ссылку на ваш репозиторий. Она выглядит примерно так: https://github.com/ваш-логин/my-first-project.git.

Теперь откройте терминал в папке вашего проекта и введите команду:

Разберем эту команду: * git remote add: команда добавления удаленного сервера. * origin: это псевдоним (короткое имя) для длинной ссылки. Исторически принято называть основной удаленный репозиторий именно origin, хотя технически вы можете назвать его хоть potato. * https://...: собственно адрес репозитория.

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

Вывод покажет адреса для скачивания (fetch) и загрузки (push).

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

Теперь, когда Git знает, куда отправлять файлы, давайте загрузим наши коммиты на сервер. Для первой отправки используется команда:

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

После ввода команды Git может попросить ввести логин и пароль (или токен) от GitHub. После успешной авторизации вы увидите процесс загрузки объектов.

Обновите страницу на GitHub — вы увидите свои файлы и историю коммитов!

Клонирование репозитория (git clone)

Рассмотрим обратную ситуацию. Вы пришли на работу, вам дали новый компьютер, или вы хотите скачать интересный Open Source проект, чтобы изучить его код. У вас нет локальной копии, но есть репозиторий на GitHub.

В этом случае git init и git remote add не нужны. Используется одна команда — git clone.

Что делает эта команда:

Создает папку с именем проекта (в примере — react).

Инициализирует в ней Git (.git).

Автоматически добавляет удаленный репозиторий под именем origin.

Скачивает все файлы и всю историю изменений.

Переключает вас на актуальную ветку (обычно main).

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

Синхронизация изменений

Когда вы работаете с удаленным репозиторием, ваш рабочий процесс немного меняется. Теперь это цикл: Получил изменения Поработал Отправил изменения.

!Цикл синхронизации кода: получение, работа, отправка.

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

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

Если вы не настраивали связь через -u при первом пуше, придется писать полностью: git push origin main.

Получение изменений (git pull)

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

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

Скачивает новые данные с сервера.

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

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

Разница между git fetch и git pull

Иногда вам нужно просто посмотреть, что происходит на сервере, не сливая изменения со своим кодом. Для этого есть команда git fetch.

* git fetch: Скачивает информацию о новых коммитах с сервера, но не меняет ваши файлы в рабочей директории. Это безопасно. * git pull: Это комбинация git fetch + git merge. Она скачивает и сразу применяет изменения.

Для новичков git pull удобнее, но профессионалы часто используют fetch, чтобы сначала проверить изменения, а потом решить, когда делать слияние.

Работа с ветками на удаленном сервере

В предыдущей статье мы создавали ветки локально. Как поделиться веткой с коллегой?

Отправка новой ветки

Если вы создали ветку feature-login локально, команда git push по умолчанию может не сработать, так как на сервере такой ветки еще нет. Git подскажет вам правильную команду:

После этого ветка появится на GitHub, и другие разработчики смогут её увидеть.

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

Если ветка слита и больше не нужна, её можно удалить и с сервера:

Резюме

Теперь ваш арсенал Git почти полон. Мы научились:

Связывать локальный проект с GitHub (git remote add).

Скачивать чужие проекты (git clone).

Отправлять свои наработки в облако (git push).

Получать обновления (git pull).

Чек-лист повседневной работы

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

Работаем: git add + git commit.

Вечером (или после завершения задачи): git push.

В следующей, заключительной статье курса, мы рассмотрим командную работу через Pull Requests, узнаем, что такое Fork, и обсудим правила хорошего тона в Open Source сообществе.

Командная работа: использование Fork, создание Pull Request и основы Code Review

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

Представьте, что вы нашли ошибку в популярной библиотеке (например, React или Django) или хотите добавить функцию в проект с открытым исходным кодом (Open Source). Вы не можете просто сделать git push в чужой репозиторий — у вас нет прав доступа. Как же тогда тысячи разработчиков по всему миру работают над одним проектом, не мешая друг другу?

Ответ кроется в трех понятиях: Fork (форк), Pull Request (пул-реквест) и Code Review (код-ревью).

Концепция Fork: ваша личная копия

В мире GitHub Fork (вилка, ответвление) — это полная копия чужого репозитория, созданная в вашем аккаунте.

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

!Треугольник взаимодействия Git: Upstream, Origin и Local.

Как сделать Fork

Откройте страницу любого публичного репозитория на GitHub.

В правом верхнем углу найдите кнопку Fork.

Нажмите её. GitHub на несколько секунд задумается (появится анимация ксерокса), и вуаля — у вас в профиле появится репозиторий с таким же именем.

Теперь у вас есть права на запись (Write access) в этот репозиторий, потому что он находится в вашем пространстве имен.

Настройка локального окружения

Чтобы начать работу, нужно склонировать ваш форк (не оригинал!) на компьютер.

Проблема синхронизации

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

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

Проверим текущие удаленные репозитории:

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

Теперь у вашего локального Git есть два источника правды:

origin — ваш форк (куда вы отправляете свои изменения).

upstream — оригинал (откуда вы забираете обновления).

Алгоритм внесения вклада (Contribution Workflow)

Работа над чужим проектом всегда следует стандартному циклу.

1. Синхронизация с оригиналом

Перед тем как начать писать код, убедитесь, что у вас свежая версия проекта. Мы скачиваем изменения из upstream и вливаем их в нашу локальную ветку main.

Или одной командой (если вы понимаете, что делаете):

Затем обновите и ваш форк на GitHub:

2. Создание тематической ветки

Никогда не работайте в ветке main! Это золотое правило Open Source. Если вы сделаете изменения в main, вам будет очень сложно потом обновить свой форк. Всегда создавайте новую ветку под конкретную задачу:

3. Работа и отправка изменений

Вы пишете код, тестируете его и делаете коммиты, как мы учились ранее:

Когда работа закончена, отправьте ветку в свой форк (origin):

Pull Request (PR): Запрос на слияние

Теперь ваш код находится на GitHub в вашем форке. Но цель — попасть в оригинальный проект. Для этого мы создаем Pull Request.

Название часто сбивает новичков с толку. Почему Pull (тянуть), если я хочу отдать код? Потому что вы просите владельца оригинального репозитория: «Пожалуйста, подтяни (pull) мои изменения к себе».

Как создать PR

Зайдите на страницу вашего форка на GitHub.

Обычно GitHub сам видит, что вы недавно запушили новую ветку, и показывает желтую плашку с кнопкой Compare & pull request.

Если кнопки нет, перейдите на вкладку Pull requests и нажмите New pull request.

Убедитесь, что направление слияния выбрано верно:

* base repository: оригинал (ветка main) * head repository: ваш форк (ветка feature-new-button)

Описание PR

Откроется форма создания. Это ваше «сопроводительное письмо».

Заголовок: Четко опишите, что делает этот PR (например, «Исправление ошибки валидации email»*). Описание: Объясните, зачем нужны эти изменения и как* вы их проверяли. Если ваш PR решает какую-то известную проблему (Issue), укажите её номер (например, Closes #42).

Нажмите Create Pull Request.

Code Review: Взгляд со стороны

После создания PR начинается этап Code Review (обзор кода). Владельцы проекта (мейнтейнеры) получают уведомление и приходят смотреть ваш код.

Code Review — это не экзамен и не попытка унизить вас. Это процесс обеспечения качества и обмена знаниями. Даже у самых опытных программистов находят ошибки.

Что происходит во время ревью?

Мейнтейнер может оставить комментарии к конкретным строкам кода: «Здесь возможна утечка памяти»*. «Переменная названа непонятно»*. «Пожалуйста, добавь тесты»*.

Как реагировать на замечания?

Не принимайте критику на свой счет. Критикуют код, а не вас.

Отвечайте вежливо. Если вы не согласны, аргументируйте свою позицию.

Вносите правки.

Самый частый вопрос новичков: «Я исправил код по замечаниям, как мне обновить PR? Нужно создавать новый?»

Нет! Pull Request в GitHub — это не статичный снимок, а ссылка на вашу ветку. Чтобы обновить PR, просто сделайте новые коммиты на своем компьютере в ту же ветку и снова выполните git push.

PR на сайте обновится автоматически.

Слияние (Merge)

Когда все замечания устранены и мейнтейнеры довольны, они нажимают заветную кнопку Merge Pull Request. Поздравляем! Ваш код стал частью проекта.

После этого вы можете:

Удалить ветку feature-new-button в своем форке.

Переключиться на main локально.

Сделать git pull upstream main, чтобы получить свой же код, но уже как часть официальной истории проекта.

Резюме курса

Мы прошли долгий путь от установки Git до участия в Open Source проектах. Давайте вспомним ключевые этапы:

Git init — начало истории.

Git commit — фиксация момента.

Git branch — параллельные миры.

Git remote — выход в интернет.

Fork & PR — глобальное сотрудничество.

Git — это стандарт индустрии. Эти знания будут служить вам фундаментом в любой IT-профессии, будь то разработка, тестирование или аналитика данных. Не бойтесь экспериментировать, ошибаться и исправлять ошибки — ведь именно для этого и создана система контроля версий.

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