Git для начинающих: Основы для работы

Введение в системы контроля версий, установка Git и базовая конфигурация

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

Что такое система контроля версий (VCS)?

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

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

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

История изменений: Вы всегда знаете, кто, когда и что изменил.

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

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

!Визуализация того, как система контроля версий хранит историю изменений и позволяет создавать ответвления.

Виды систем контроля версий

Существует два основных типа систем, и важно понимать разницу между ними, чтобы осознать преимущества Git.

Централизованные системы (CVCS)

Примеры: Subversion (SVN), Perforce.

В таких системах есть один главный сервер, где хранится вся история версий. Разработчики скачивают файлы, работают с ними и отправляют обратно на сервер.

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

Распределенные системы (DVCS)

Примеры: Git, Mercurial.

В распределенных системах клиенты не просто скачивают последнюю версию файлов. Они полностью копируют (клонируют) весь репозиторий, включая полную историю всех изменений.

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

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

Что такое Git?

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

Главное отличие Git от других систем заключается в том, как он воспринимает данные. Большинство систем хранят информацию как список изменений для каждого файла. Git же считает данные набором снимков (snapshots) небольшой файловой системы. Каждый раз, когда вы сохраняете состояние проекта (делаете коммит), Git как бы фотографирует все ваши файлы в этот момент.

Установка Git

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

Установка на Windows

Перейдите на официальный сайт Git SCM.

Загрузка начнется автоматически. Запустите скачанный .exe файл.

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

Важно: Убедитесь, что выбрана опция установки Git Bash. Это эмулятор терминала, который позволит вам использовать команды Git так же, как на Linux или macOS.

Установка на macOS

Самый простой способ — установить инструменты командной строки Xcode. Откройте терминал и введите:

Если Git не установлен, система сама предложит его установить.

Альтернативный вариант (если вы используете Homebrew):

Установка на Linux

Если вы используете дистрибутив на базе Debian (например, Ubuntu), откройте терминал и введите:

Для дистрибутивов на базе Red Hat (например, Fedora):

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

После установки откройте терминал (на Windows — Git Bash, на macOS/Linux — обычный Terminal) и введите команду:

Если вы видите что-то вроде git version 2.40.0, поздравляю — Git установлен!

Базовая конфигурация

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

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

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

Разберем эту команду: * git config — команда для настройки Git. * --global — этот флаг означает, что настройки будут применены для всех ваших проектов на этом компьютере. Если вы захотите использовать другое имя для конкретного проекта, вы сможете сделать это позже без флага --global внутри папки проекта.

Настройка окончаний строк (Line Endings)

Это технический, но важный момент. Windows и macOS/Linux используют разные символы для обозначения конца строки в текстовых файлах. Если вы работаете в команде с людьми на разных операционных системах, это может вызвать проблемы.

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

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

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

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

Вы увидите список переменных. Найдите там user.name и user.email, чтобы проверить, что они записаны верно.

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

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

* Репозиторий (Repository): Место, где хранятся ваши файлы и вся история их изменений. Обычно это папка вашего проекта с подпапкой .git. * Коммит (Commit): Фиксация изменений. Это как точка сохранения в игре. Коммит сохраняет состояние всех файлов в репозитории на текущий момент. * Ветка (Branch): Независимая линия разработки. Вы можете создать ветку, чтобы поэкспериментировать с новой функцией, не ломая основной код.

Резюме

Сегодня мы заложили фундамент для вашей работы:

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

Мы установили Git и терминал (Git Bash для Windows).

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

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

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

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

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

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

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

Рабочая директория (Working Directory): Это ваша папка с проектом. Здесь лежат файлы, которые вы видите в проводнике и редактируете прямо сейчас. Это ваша «песочница».

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

Репозиторий (Repository / .git directory): Это место, где Git хранит все сохраненные «снимки» (коммиты). Когда вы «заклеиваете коробку и отправляете её», файлы попадают сюда навсегда.

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

Создание репозитория: git init

Давайте создадим наш первый проект. Откройте терминал (Git Bash на Windows или Terminal на macOS/Linux).

Сначала создадим папку для проекта и перейдем в нее. Введите команды по очереди:

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

Если все прошло успешно, вы увидите сообщение вроде: Initialized empty Git repository in /path/to/my-first-project/.git/

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

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

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

Давайте проверим статус нашего пустого репозитория:

Вы увидите: On branch master (или main) No commits yet nothing to commit

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

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

Теперь вывод изменился. Git видит новый файл, но помечает его красным цветом под заголовком Untracked files (Неотслеживаемые файлы). Это значит, что файл существует в вашей «Рабочей директории», но Git пока не следит за его изменениями. Если вы удалите его сейчас, Git не сможет его восстановить.

Индексация файлов: git add

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

Теперь снова введите git status. Вы увидите, что hello.txt стал зеленым и находится под заголовком Changes to be committed (Изменения, готовые к коммиту).

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

Почему нельзя сразу сделать «Сохранить»? Представьте, что вы работали над двумя разными задачами: исправляли ошибку в коде и писали новую главу документации. Вы изменили 10 файлов. Если вы сохраните всё сразу, история проекта превратится в кашу. С помощью git add вы можете выбрать: сначала добавить и сохранить файлы с исправлением ошибки, а следующим шагом — файлы документации. Это позволяет делать историю изменений чистой и логичной.

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

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

Теперь, когда наш файл находится в Staging Area (зеленый в статусе), мы готовы сделать «снимок» и сохранить его в историю навсегда. Это называется коммит.

Каждый коммит обязан иметь сообщение — комментарий, объясняющий, что и зачем вы сделали.

Разберем команду: * git commit — команда фиксации. * -m — флаг (message), который позволяет написать сообщение сразу в командной строке. * "..." — само сообщение. Оно должно быть кратким, но информативным.

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

> Совет: Пишите сообщения коммитов в повелительном наклонении: «Добавить файл», «Исправить ошибку», «Обновить стили». Это стандарт индустрии.

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

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

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

Этот длинный набор символов (хеш) — уникальный идентификатор вашего коммита. По нему Git отличает одно состояние проекта от другого.

Полный цикл работы

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

Изменяем файл: Откройте hello.txt и добавьте вторую строку, или сделайте это командой:

Проверяем статус:

Git скажет: modified: hello.txt (красным). Он видит, что файл изменился по сравнению с последним коммитом.

Добавляем в индекс:

Делаем коммит:

Смотрим историю:

Теперь вы увидите два коммита, идущих друг за другом.

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

Иногда в проекте появляются файлы, которые мы не хотим сохранять в Git. Это могут быть: * Временные файлы системы. * Логи (журналы ошибок). * Папки с настройками редактора (например, .vscode). * Скомпилированные файлы (.exe, .class).

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

Внутри этого файла мы просто пишем названия файлов или папок, которые нужно игнорировать.

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

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

Резюме

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

git init — создает новый репозиторий (делается один раз для проекта).

git status — показывает текущее состояние файлов (делается постоянно).

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

git commit -m "сообщение" — сохраняет подготовленные изменения в историю.

git log — показывает список сохраненных изменений.

Эти команды — это алфавит Git. В следующем уроке мы узнаем, как путешествовать во времени: отменять изменения и возвращаться к старым версиям файлов.

Ветвление и слияние: создание веток, переключение и объединение истории

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

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

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

Представьте, что вы пишете научно-фантастический роман. У вас есть основная сюжетная линия. В какой-то момент вы решаете: «А что, если главный герой не пойдет в пещеру, а полетит в космос?». Вы не хотите переписывать уже написанные главы, поэтому вы делаете копию рукописи и начинаете писать альтернативный сюжет.

В Git ветка — это и есть такая альтернативная линия развития проекта.

По умолчанию в каждом репозитории есть одна главная ветка. Раньше она называлась master, сейчас всё чаще используется название main. Это ствол вашего дерева. Когда вы создаете новую ветку, вы создаете ответвление от этого ствола, чтобы работать над новой функцией, исправлять ошибку или просто экспериментировать, не боясь сломать основной код.

!Визуализация структуры веток в Git, показывающая параллельную разработку.

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

Изоляция: Вы работаете над новой функцией в отдельной ветке. Если код окажется нерабочим, вы просто удалите ветку. Основной проект (в ветке main) останется чистым и рабочим.

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

Контекст: Каждая ветка имеет имя, например add-login-form или fix-header-bug. Это сразу говорит о том, какая работа ведется в этом направлении.

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

Давайте перейдем к практике. Откройте ваш терминал в папке с проектом.

Просмотр веток

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

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

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

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

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

Эта команда создает новую ветку, но не переключает вас на неё. Если вы снова введете git branch, то увидите:

Звездочка все еще на master. Мы создали «параллельную вселенную», но пока остались в старой.

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

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

Git ответит: Switched to branch 'readme-update'.

Теперь любые изменения файлов и новые коммиты будут попадать только в ветку readme-update, не затрагивая master.

> Совет: Существует команда, которая объединяет создание и переключение. Это очень удобно и используется чаще всего: > git checkout -b имя-новой-ветки > Флаг -b говорит Git: «Создай ветку и сразу переключись на неё».

Работа в ветке

Давайте сымитируем бурную деятельность. Убедитесь, что вы находитесь в ветке readme-update (команда git branch должна показать звездочку напротив неё).

Создайте новый файл README.md.

Напишите в нем текст: «Это инструкция к проекту».

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

Теперь в ветке readme-update есть этот файл. А что в master?

Переключимся обратно:

Посмотрите в папку проекта. Файл README.md исчез!

Не пугайтесь. Это и есть магия Git. Когда вы переключаетесь на master, Git восстанавливает состояние файлов именно для этой ветки. В master мы еще не создавали этот файл, поэтому его там нет. Переключитесь обратно (git checkout readme-update), и файл снова появится.

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

Мы закончили работу над инструкцией в ветке readme-update. Мы протестировали её и решили, что она достойна попасть в основной проект. Нам нужно выполнить слияние (merge).

Процесс слияния всегда происходит по правилу: «Я стою в ветке-приемнике и затягиваю в неё изменения из другой ветки».

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

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

Вы увидите сообщение Fast-forward, и информацию о том, что файл README.md был добавлен. Теперь изменения из readme-update стали частью master.

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

После успешного слияния ветка readme-update нам больше не нужна. Сами изменения уже в master, а указатель ветки стал лишним. Удалим его:

Флаг -d (delete) удаляет ветку. Если ветка не была слита (вы потеряете данные), Git не даст её удалить и попросит использовать -D (большую букву) для принудительного удаления.

Конфликты слияния

Жизнь не всегда так проста, как Fast-forward. Иногда два человека (или вы сами в разных ветках) меняют одну и ту же строку в одном и том же файле.

Когда вы попытаетесь объединить такие ветки, Git запаникует. Он не знает, чей вариант правильный: ваш или коллеги. Это называется конфликт слияния (Merge Conflict).

Как выглядит конфликт?

Предположим, в master в файле hello.txt написано «Привет, Мир». В ветке feature вы исправили это на «Привет, Git». А в ветке fix вы исправили это на «Привет, Вселенная».

При попытке слить эти ветки, Git выдаст сообщение: CONFLICT (content): Merge conflict in hello.txt Automatic merge failed; fix conflicts and then commit the result.

Если вы откроете файл hello.txt, вы увидите специальные пометки, которые оставил Git:

* <<<<<<< HEAD: Начало вашей текущей версии (куда вливаем). * =======: Разделитель. * >>>>>>> fix: Конец версии из вливаемой ветки (откуда вливаем).

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

Разрешение конфликта — это ручная работа. Вам нужно:

Открыть файл в редакторе.

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

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

Например, мы решаем оставить «Привет, Вселенная»:

Сохранить файл.

Добавить файл в индекс (это скажет Git, что конфликт решен):

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

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

!Процесс ручного разрешения конфликта слияния в текстовом файле.

Что такое HEAD?

Вы могли заметить слово HEAD в выводе команд или при конфликтах. Это важный термин.

HEAD — это указатель на «то место, где вы сейчас находитесь». Обычно HEAD указывает на имя текущей ветки (например, master). Когда вы делаете новый коммит, ветка master сдвигается вперед, и HEAD движется вместе с ней.

Когда вы делаете git checkout <ветка>, вы просто переставляете указатель HEAD на другую ветку. Именно поэтому переключение происходит так быстро — Git просто меняет одну ссылку.

Резюме

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

Основные команды урока:

* git branch — показать список веток. * git branch <имя> — создать новую ветку. * git checkout <имя> — переключиться на ветку. * git checkout -b <имя> — создать и переключиться. * git merge <имя> — влить изменения из указанной ветки в текущую. * git branch -d <имя> — удалить ветку.

В следующем уроке мы поговорим о том, как работать с удаленными репозиториями (GitHub/GitLab) и как делиться своим кодом со всем миром.

Работа с удаленными репозиториями: клонирование, отправка (push) и получение (pull) данных

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

В этой статье мы выходим в интернет. Мы разберем, как работать с удаленными репозиториями (remote repositories), как скачивать чужой код и как публиковать свой.

Что такое удаленный репозиторий?

Удаленный репозиторий — это версия вашего проекта, которая хранится в интернете или на другом сетевом сервере. По сути, это та же папка .git, только она лежит не у вас, а на сервере GitHub, GitLab или Bitbucket.

Работа с удаленным репозиторием похожа на работу с облачным хранилищем (как Google Drive или Dropbox), но с важным отличием: синхронизация не происходит автоматически. Вы должны явно приказывать Git отправить данные («загрузить») или получить их («скачать»).

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

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

Резервное копирование: Ваш код в безопасности, даже если сгорит ноутбук.

Командная работа: Десятки людей могут отправлять свой код в одно место и скачивать обновления друг друга.

Публикация: Вы можете показать свой код всему миру (Open Source).

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

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

Команда git clone создает точную копию удаленного репозитория на вашем компьютере. Она скачивает не только файлы, но и всю историю изменений (все коммиты и ветки).

Синтаксис прост:

Пример:

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

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

Связывание существующего проекта: git remote

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

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

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

Разберем эту команду: * git remote add — добавить новое удаленное соединение. * origin — это имя соединения. По традиции основной удаленный сервер называют origin (источник). Вы можете назвать его как угодно (например, backup или github), но origin — это стандарт. * https://... — ссылка на репозиторий.

Чтобы проверить, какие удаленные серверы подключены к вашему проекту, используйте команду с флагом -v (verbose — подробно):

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

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

Когда вы сделали несколько коммитов локально и готовы сохранить их на сервере, вы используете команду push (толкать).

Эта команда говорит Git: «Возьми ветку main и отправь её на сервер origin».

Первый Push

Если вы отправляете ветку в первый раз, Git может попросить вас установить связь между локальной и удаленной веткой (upstream). Рекомендуется использовать флаг -u:

Флаг -u запоминает параметры. В будущем вы сможете писать просто git push, и Git сам поймет, что вы хотите отправить текущую ветку в origin.

> Примечание: При первом пуше GitHub попросит вас ввести логин и пароль (или специальный токен). Это мера безопасности, чтобы никто другой не мог менять ваш код.

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

Представьте, что ваш коллега Василий тоже работает над этим проектом. Он исправил ошибку, сделал коммит и выполнил git push. Теперь эти изменения лежат на сервере, но их нет у вас.

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

Или просто git pull, если вы настроили связь ранее.

Что происходит внутри?

На самом деле git pull — это комбинация двух команд:

git fetch — скачивает данные с сервера в скрытую папку, но не меняет ваши файлы.

git merge — берет скачанные данные и сливает их с вашей текущей работой.

Обычно новичкам достаточно знать только про git pull. Это самый простой способ синхронизироваться с командой.

!Иллюстрация того, как команда pull объединяет скачивание и слияние.

Типичный рабочий процесс (Workflow)

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

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

Работа: Вы пишете код, создаете файлы, исправляете баги.

Фиксация: Вы сохраняете результаты.

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

Конфликты при отправке

Иногда при попытке сделать git push вы можете получить ошибку:

error: failed to push some refs to ... Hint: Updates were rejected because the remote contains work that you do not have locally.

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

Решение:

Сначала скачайте изменения Василия: git pull.

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

Сделайте новый коммит.

Теперь вы можете безопасно сделать git push.

Резюме

Сегодня мы превратили Git из инструмента для одиночек в мощное средство командной работы.

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

Теперь вы владеете полным набором базовых навыков Git. Вы можете создавать проекты, ветвить их, сливать и синхронизировать с удаленными серверами. Это тот фундамент, на котором строится вся современная разработка программного обеспечения.

Для более глубокого изучения вы можете обратиться к официальной документации Git SCM.

Разрешение конфликтов слияния и отмена ошибочных действий в истории

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

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

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

Мы уже касались темы конфликтов в уроке про ветвление, но теперь разберем её детально. Конфликт слияния (Merge Conflict) происходит, когда Git не может автоматически решить, как объединить изменения из двух веток.

Чаще всего это случается в одной ситуации: две ветки изменили одну и ту же строку в одном и том же файле, но по-разному.

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

Как Git сообщает о конфликте?

Представьте, что вы находитесь в ветке main и пытаетесь слить в неё ветку feature-login:

Если возникнет конфликт, Git остановит процесс и выдаст сообщение:

Git говорит: «Я попытался, но не смог. Файл index.html теперь содержит конфликт. Исправь его вручную и скажи мне, когда закончишь».

Маркеры конфликта

Если вы откроете конфликтный файл в текстовом редакторе, вы увидите, что Git добавил туда специальные маркеры. Они выглядят пугающе, но их структура очень логична:

Разберем по строкам:

<<<<<<< HEAD: Эта метка показывает начало изменений в вашей текущей ветке (в той, в которую вы вливаете, то есть main).

Содержимое между <<<<<<< и ======= — это то, что было у вас до слияния.

=======: Это разделитель. Всё, что выше — ваше. Всё, что ниже — пришло из другой ветки.

Содержимое между ======= и >>>>>>> — это код из вливаемой ветки (feature-login).

>>>>>>> feature-login: Конец блока конфликта с указанием имени ветки-источника.

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

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

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

Пример решения (объединение):

Индексация: После сохранения файла нужно сообщить Git, что конфликт исчерпан. Для этого просто добавьте файл в индекс:

Фиксация: Завершите слияние созданием коммита. Обычно сообщение генерируется автоматически:

Теперь конфликт разрешен, и история слияния сохранена.

Отмена локальных изменений

Ошибки случаются не только при слиянии. Часто бывает, что вы начали редактировать файл, испортили его и хотите вернуть «как было». До того как вы сделали коммит, это очень легко исправить.

Восстановление файла: git restore

Если вы изменили файл, но еще не добавляли его в индекс (не делали git add), используйте команду restore:

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

> Примечание: В старых руководствах вы можете встретить команду git checkout -- index.html. Она делает то же самое, но git restore — это более современный и понятный способ.

Отмена индексации: git restore --staged

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

Файл снова станет «красным» в git status, то есть вернется в статус Modified, но не Staged.

Исправление последнего коммита: --amend

Это классическая ситуация: вы сделали коммит `git commit -m