Система контроля версий git конспект

Обновлено: 30.06.2024

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

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

Git — это набор консольных утилит, которые отслеживают и фиксируют изменения в файлах (чаще всего речь идет об исходном коде программ, но вы можете использовать его для любых файлов на ваш вкус). С его помощью вы можете откатиться на более старую версию вашего проекта, сравнивать, анализировать, сливать изменения и многое другое. Этот процесс называется контролем версий. Существуют различные системы для контроля версий. Вы, возможно, о них слышали: SVN, Mercurial, Perforce, CVS, Bitkeeper и другие.

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

Установить git на свою машину очень просто:

Linux — нужно просто открыть терминал и установить приложение при помощи пакетного менеджера вашего дистрибутива. Для Ubuntu команда будет выглядеть следующим образом:
Windows — мы рекомендуем git for windows, так как он содержит и клиент с графическим интерфейсом, и эмулятор bash.
OS X — проще всего воспользоваться homebrew. После его установки запустите в терминале:

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

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

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

Как мы отметили ранее, git хранит свои файлы и историю прямо в папке проекта. Чтобы создать новый репозиторий, нам нужно открыть терминал, зайти в папку нашего проекта и выполнить команду init. Это включит приложение в этой конкретной папке и создаст скрытую директорию .git, где будет храниться история репозитория и настройки.
Создайте на рабочем столе папку под названием git_exercise. Для этого в окне терминала введите:

Командная строка должна вернуть что-то вроде:

Это значит, что наш репозиторий был успешно создан, но пока что пуст. Теперь создайте текстовый файл под названием hello.txt и сохраните его в директории git_exercise.

status — это еще одна важнейшая команда, которая показывает информацию о текущем состоянии репозитория: актуальна ли информация на нём, нет ли чего-то нового, что поменялось, и так далее. Запуск git status на нашем свежесозданном репозитории должен выдать:

В git есть концепция области подготовленных файлов. Можно представить ее как холст, на который наносят изменения, которые нужны в коммите. Сперва он пустой, но затем мы добавляем на него файлы (или части файлов, или даже одиночные строчки) командой add и, наконец, коммитим все нужное в репозиторий (создаем слепок нужного нам состояния) командой commit.
В нашем случае у нас только один файл, так что добавим его:

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

Проверим статус снова, на этот раз мы должны получить другой ответ:

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

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

1. Подключение к удаленному репозиторию

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

Сейчас самое время переслать наш локальный коммит на сервер. Этот процесс происходит каждый раз, когда мы хотим обновить данные в удаленном репозитории.
Команда, предназначенная для этого - push. Она принимает два параметра: имя удаленного репозитория (мы назвали наш origin) и ветку, в которую необходимо внести изменения (master — это ветка по умолчанию для всех репозиториев).

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

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

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

Новый локальный репозиторий создается автоматически с GitHub в качестве удаленного репозитория.

4. Запрос изменений с сервера

Если вы сделали изменения в вашем удаленном репозитории, другие пользователи могут скачать изменения при помощи команды pull.

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

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

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

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

Основная ветка в каждом репозитории называется master. Чтобы создать еще одну ветку, используем команду branch

Это создаст новую ветку, пока что точную копию ветки master.

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

Сейчас, если мы запустим branch, мы увидим две доступные опции:

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

3. Слияние веток

Наша “потрясающая новая фича” будет еще одним текстовым файлом под названием feature.txt. Мы создадим его, добавим и закоммитим:

Изменения завершены, теперь мы можем переключиться обратно на ветку master.

Теперь, если мы откроем наш проект в файловом менеджере, мы не увидим файла feature.txt, потому что мы переключились обратно на ветку master, в которой такого файла не существует. Чтобы он появился, нужно воспользоваться merge для объединения веток (применения изменений из ветки amazing_new_feature к основной версии проекта).

Теперь ветка master актуальна. Ветка amazing_new_feature больше не нужна, и ее можно удалить.

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

1. Отслеживание изменений, сделанных в коммитах

У каждого коммита есть свой уникальный идентификатор в виде строки цифр и букв. Чтобы просмотреть список всех коммитов и их идентификаторов, можно использовать команду log:
[spoiler title='Вывод git log']

[/spoiler]
Как вы можете заметить, идентификаторы довольно длинные, но для работы с ними не обязательно копировать их целиком — первых нескольких символов будет вполне достаточно. Чтобы посмотреть, что нового появилось в коммите, мы можем воспользоваться командой show [commit]
[spoiler title='Вывод git show']

[/spoiler]
Чтобы увидеть разницу между двумя коммитами, используется команда diff (с указанием промежутка между коммитами):
[spoiler title='Вывод git diff']

[/spoiler]
Мы сравнили первый коммит с последним, чтобы увидеть все изменения, которые были когда-либо сделаны. Обычно проще использовать git difftool, так как эта команда запускает графический клиент, в котором наглядно сопоставляет все изменения.

2. Возвращение файла к предыдущему состоянию

Гит позволяет вернуть выбранный файл к состоянию на момент определенного коммита. Это делается уже знакомой нам командой checkout, которую мы ранее использовали для переключения между ветками. Но она также может быть использована для переключения между коммитами (это довольно распространенная ситуация для Гита - использование одной команды для различных, на первый взгляд, слабо связанных задач).
В следующем примере мы возьмем файл hello.txt и откатим все изменения, совершенные над ним к первому коммиту. Чтобы сделать это, мы подставим в команду идентификатор нужного коммита, а также путь до файла:

3. Исправление коммита

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

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

4. Разрешение конфликтов при слиянии

Помимо сценария, описанного в предыдущем пункте, конфликты регулярно возникают при слиянии ветвей или при отправке чужого кода. Иногда конфликты исправляются автоматически, но обычно с этим приходится разбираться вручную — решать, какой код остается, а какой нужно удалить.
Давайте посмотрим на примеры, где мы попытаемся слить две ветки под названием john_branch и tim_branch. И Тим, и Джон правят один и тот же файл: функцию, которая отображает элементы массива.
Джон использует цикл:

Тим предпочитает forEach:

Система не смогла разрешить конфликт автоматически, значит, это придется сделать разработчикам. Приложение отметило строки, содержащие конфликт:
[spoiler title='Вывод']

[/spoiler]
Над разделителем ======= мы видим последний (HEAD) коммит, а под ним - конфликтующий. Таким образом, мы можем увидеть, чем они отличаются и решать, какая версия лучше. Или вовсе написать новую. В этой ситуации мы так и поступим, перепишем все, удалив разделители, и дадим git понять, что закончили.

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

Как вы можете заметить, процесс довольно утомительный и может быть очень сложным в больших проектах. Многие разработчики предпочитают использовать для разрешения конфликтов клиенты с графическим интерфейсом. (Для запуска нужно набрать git mergetool).

5. Настройка .gitignore

В большинстве проектов есть файлы или целые директории, в которые мы не хотим (и, скорее всего, не захотим) коммитить. Мы можем удостовериться, что они случайно не попадут в git add -A при помощи файла .gitignore

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

Вот хорошие примеры файлов, которые нужно игнорировать:

Логи
Артефакты систем сборки
Папки node_modules в проектах node.js
Папки, созданные IDE, например, Netbeans или IntelliJ
Разнообразные заметки разработчика.

Файл .gitignore, исключающий все перечисленное выше, будет выглядеть так:

Символ слэша в конце некоторых линий означает директорию (и тот факт, что мы рекурсивно игнорируем все ее содержимое). Звездочка, как обычно, означает шаблон.

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

Аннотация: Понятие GitFlow и стратегии работы с версиями, знакомство с GitHub-подобными системами, CI/CD на базе GitLab.

Git. Что такое система контроля версий?

Система контроля версий (англ. Version Control System ) - программное обеспечение хранящееся все версии возможного файла, и дающее возможность получить к ним доступ. Существуют разные системы: git, mercurial, subversion(svn), Team Foundation server (TFS) , однако наибольшую популярность завоевала система Git из-за простоты использования и внедрения в другие системы.

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

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

В текущих реалиях cистемы контроля версий являются важнейшей частью процесса Continuous integration, поскольку позволяют производить одновременную разработку, через доступное для всех разработчиков версионирование и через удалённый сервер со всеми версиями. Таким образом любой из разработчиков может получить последнюю версию рабочего кода, соединить её со своей и проверить работоспособность. Также в данный процесс тесно внедрены системы тестирования. Так, в некоторых случаях буквально на каждый коммит могут запускаться юнит-тесты и интеграционное тестирование на CI сервере, которое в автоматическом режим проверит работоспособность и совместимость кода.

Принципы Git

Разберём основные понятия git систем:

Репозиторий - обособленное хранилище кода внутри которого будут отслеживаться изменения файлов
Ветвь ( branch ) - отдельная цепочка (ветка) отслеживаемых изменений
Мастер branch - главная ветка в репозитории
Коммит - зафиксированная точка изменений
Удаленный сервер ( remote server ) - сервер на котором хранится репозиторий
Merge (слияние) - процесс слияния двух ветвей
tag - ссылка на определенный коммит

Git - это утилита для работы в командной строке (хотя есть и опции для работы через графический интерфейс)

Пример добавления локальных изменений в удаленный репозиторий:

Для того чтобы забрать изменения с удалённого сервера:

Git flow и Git стратегии

GitFlow - это методология работы с Git или, проще говоря, модель ветвления.

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

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

Существует master ветка в которой всегда находится рабочий код
Из нее в нужные моменты создаются релиз ветки, из которых собирается результирующий артефакт.
Для разработки нового компонента используется feature -ветки которые создаются из мастера, проходят стадии разработки и затем вливаются обратно в мастер. (Опционально master ветка может быть заменена на dev ветку в которой собирается весь разрабатываемый код, и которая в свою очередь перед релизом вливается в master ветку)
Для создания срочных патчей создаются Ehotfix -ветки из релиза, разрабатываются и вливаются обратно в релиз, после чего релиз ветка вливается в мастер ветку.

Github-подобные системы

Github, gitlab, bitbucket, gitea, Azure Repos и т.д. - это всё программные продукты которые предоставляют функционал удаленного сервер с веб-интерфейсом для управления git -репозиториями. Однако за последние десять лет сама концепция хостинга git репозиториев сильно разрослась, и в текущий момент это представляет собой огромные комбайны позволяющие выполнять множество действий.

Размещение кода
Создание Issue (описанных проблем)
Создание Pull/Merge Request'ов - Issue с подготовленными ветками для слияния
Wiki - база знаний основанная на разметке markdown
В некоторых системах - CI -системы для сборки, тестирования и развертывания кода.

Пример pipeline на Gitlab

Gitlab - один из лучших примеров реализации концепции Pipeline as a Code, когда вся конфигурация сборочной линии полностью представлена в виде кода, который легко читается, и есть широкий функционал для автоматизации рутинных действий.

Выводы

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

Git — система контроля версий

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

Разработчикам часто бывает нужно вернуться к предыдущей версии кода:

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

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

К базовым возможностям Git относятся:

возврат к любой предыдущей версии кода;
просмотр истории изменений;
параллельная работа над проектом;
backup кода.

Начало работы с Git

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

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

Что такое репозиторий Git?

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

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

Где хранится репозиторий?

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

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

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

Что такое коммит и коммитить?

Зачем нужен коммит, если Git и так следит за всеми изменениями? Коммиты разбивают процесс разработки, состоящий из большого количества правок, на отдельные шаги. То есть коммит — это некое логически завершенное изменение внутри проекта и понятная (в том числе и другим разработчикам) точка, к которой можно вернуться, если возникнут какие-то проблемы.

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

Как правило, рабочий процесс представляет собой цикл: коммит — изменение файлов — коммит.

Что такое ветвление?

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

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

Изучите с нуля алгоритмы и структуры данных, поработайте с Git и станьте востребованным специалистом. Дополнительная скидка 5% по промокоду BLOG.

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

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

Зачем нужен GitHub?

GitHub — это самый популярный сайт для хранения git-репозиториев и работы с ними. Также GitHub является крупнейшей площадкой для размещения проектов с открытым исходным кодом. Для просмотра и загрузки общедоступных репозиториев не требуется ни регистрации, ни оплаты аккаунта.

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

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

Где-то здесь был спрятан промокод на год доступа к тренажёрам. Вы добрались до цели, но вас опередили. Не расстраивайтесь — вот код youawesome , он даёт скидку на все профессиональные курсы Академии.

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

Версионирование

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

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

Этим всё не ограничилось, в итоге структура проекта разрослась и стала выглядеть так:

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

Для решения проблемы с сохранением новой версии файлов удобно использовать системы контроля версий. Одна из самых популярных — Git. Работу Git можно сравнить с процессом сохранения и загрузки в компьютерных играх:

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

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

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

Основные понятия

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

Репозиторий

Проект, в котором была инициализирована система Git, называется репозиторием. При инициализации в проект добавляется скрытая папка .git . Репозиторий хранит все рабочие файлы и историю их изменений.

Рабочая область и хранилище

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

Хранилище — это содержимое скрытой папки .git . В этой папке хранятся все версии рабочей области и служебная информация. Этим версиям система автоматически даёт название, состоящее из букв и цифр. В примере выше — это bea0f8e и d516600 . Не стоит проводить манипуляции с папкой .git вручную. Вся работа с системой производится командами через специальные приложения или консоль.

Коммит

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

В итоге проект работает так:

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

Система контроля версий Git

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

Работа в команде

Как синхронизовать данные репозиториев между разработчиками? Изначально Git репозитории сами могут синхронизироваться от пользователя к пользователю. Дополнительные программы для этого не нужны. Есть специальные команды в консоли, позволяющие передавать данные из одного репозитория в другой.

Репозитории можно синхронизировать между пользователями.

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

Синхронизация через удалённый репозиторий.

Этапы синхронизации

Как сделать так, чтобы разработчик смог передать актуальную версию проекта коллеге?

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

Синхронизация (push и pull) между локальными и удалённым репозиториями.

Типовой рабочий процесс с использованием Git

Разберём типовой процесс разработки сайта в команде. Представим, что Игорь и Алиса — разработчики на одном проекте. Игорь начал верстать проект и сделал первые коммиты, в которых зафиксировал изменения в файле index.html . Для схематичности названия коммитов будут простые: B1 и B2.

Коммиты B1 и B2.

Игорь запушил свои коммиты.

После пуша данные синхронизировались с удалённым репозиторием. Но как Алисе теперь получить изменения? Для этого она выполняет команду git pull и получает все изменения из облака к себе на компьютер. Таким образом, состояние проекта у Игоря и Алисы синхронизировались, и они могут дальше продолжить работать над ним.

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

Параллельные изменения

Что произойдёт, если разработчики изменят одинаковый файл и сделают push ? Предположим, что Игорь и Алиса изменили файл index.html , сделали коммит с изменениями и запушили его. Игорь оказался быстрее Алисы и сделал push первым.

Два пуша в одно время?

В этом случае Git сообщит Алисе, что нельзя пушить свои изменения, потому что она не делала pull . Дело в том, что после того как Игорь синхронизировался с удалённым репозиторием, версия проекта Алисы стала отличаться от той, что находится на удалённом репозитории, и Git это видит. Система сообщает, что перед тем, как выполнить команду push , нужно выполнить pull , чтобы забрать изменения. Алиса делает pull и ей вновь приходит уведомление от Git. В этот раз он сообщает Алисе о том, что произошёл конфликт.

Конфликт

Дело в том, что Игорь и Алиса изменили одинаковый файл и теперь Алисе предстоит решить конфликт.

Конфликт

Существуют два вида конфликтов:

Автоматически разрешаемый конфликт.
Конфликт, который нужно разрешить вручную.

Ниже рассмотрим оба варианта.

Слияние

Допустим, что на третьей строке Игорь добавил в проект шапку, а на четвёртой Алиса добавила футер.

Игорь сделал шапку и отправил коммит, а Алиса добавила подвал.

Git видит, что произведённые изменения не затрагивают друг друга. Он сам объединит две версии проектов в одну, совершив слияние. После этого Алиса спокойно синхронизируется с удалённым репозиторием, отправив новую версию проекта.

Изменения в проекте не пересекались и Git выполняет слияние сам.

Во время слияния Git не знает, в каком порядке расположить коммит В3 Игоря и коммит В4 Алисы, из-за которых случился конфликт. Поэтому Git разрешает существовать нескольким версиям проекта одновременно. Как раз для этого и нужен следующий коммит В5, в котором происходит слияние предыдущих параллельных версий. После того как Алиса запушит изменения, она отправляет все версии проектов на удалённый репозиторий. В следующий раз, когда Игорь сделает pull , он получит полную историю со слиянием конфликта.

Слияние.

Алиса и Игорь изменили один и тот же блок.

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

Версии файла.

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

Окружение Git

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

GitHub

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

Облегчить работу с Git и GitHub могут специальные программы. Такие программы в удобной форме показывают изменения в коде, список коммитов и обладают другими удобными возможностями. Обычно в подобных программах есть возможность выполнять стандартные Git команды: pull , push , commit и прочие — просто нажав на кнопку.

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

Читайте также: