зачем нужен удаленный репозиторий
Работа с удалёнными репозиториями
Для того, чтобы внести вклад в какой-либо Git-проект, вам необходимо уметь работать с удалёнными репозиториями. Удалённые репозитории представляют собой версии вашего проекта, сохранённые в интернете или ещё где-то в сети. У вас может быть несколько удалённых репозиториев, каждый из которых может быть доступен для чтения или для чтения-записи. Взаимодействие с другими пользователями предполагает управление удалёнными репозиториями, а также отправку и получение данных из них. Управление репозиториями включает в себя как умение добавлять новые, так и умение удалять устаревшие репозитории, а также умение управлять различными удалёнными ветками, объявлять их отслеживаемыми или нет и так далее. В данном разделе мы рассмотрим некоторые из этих навыков.
Вполне возможно, что удалённый репозиторий будет находиться на том же компьютере, на котором работаете вы. Слово «удалённый» не означает, что репозиторий обязательно должен быть где-то в сети или Интернет, а значит только — где-то ещё. Работа с таким удалённым репозиторием подразумевает выполнение стандартных операций отправки и получения, как и с любым другим удалённым репозиторием.
Просмотр удалённых репозиториев
Если у вас больше одного удалённого репозитория, команда выведет их все. Например, для репозитория с несколькими настроенными удалёнными репозиториями в случае совместной работы нескольких пользователей, вывод команды может выглядеть примерно так:
Это означает, что мы можем легко получить изменения от любого из этих пользователей. Возможно, что некоторые из репозиториев доступны для записи и в них можно отправлять свои изменения, хотя вывод команды не даёт никакой информации о правах доступа.
Обратите внимание на разнообразие протоколов, используемых при указании адреса удалённого репозитория; подробнее мы рассмотрим протоколы в разделе Установка Git на сервер главы 4.
Добавление удалённых репозиториев
В предыдущих разделах мы уже упоминали и приводили примеры добавления удалённых репозиториев, сейчас рассмотрим эту операцию подробнее. Для того, чтобы добавить удалённый репозиторий и присвоить ему имя (shortname), просто выполните команду git remote add :
Получение изменений из удалённого репозитория — Fetch и Pull
Как вы только что узнали, для получения данных из удалённых проектов, следует выполнить:
Данная команда связывается с указанным удалённым проектом и забирает все те данные проекта, которых у вас ещё нет. После того как вы выполнили команду, у вас должны появиться ссылки на все ветки из этого удалённого проекта, которые вы можете просмотреть или слить в любой момент.
Когда вы клонируете репозиторий, команда clone автоматически добавляет этот удалённый репозиторий под именем «origin». Таким образом, git fetch origin извлекает все наработки, отправленные на этот сервер после того, как вы его клонировали (или получили изменения с помощью fetch). Важно отметить, что команда git fetch забирает данные в ваш локальный репозиторий, но не сливает их с какими-либо вашими наработками и не модифицирует то, над чем вы работаете в данный момент. Вам необходимо вручную слить эти данные с вашими, когда вы будете готовы.
Начиная с версии 2.27, команда git pull выдаёт предупреждение, если настройка pull.rebase не установлена. Git будет выводить это предупреждение каждый раз пока настройка не будет установлена.
Отправка изменений в удаленный репозиторий (Push)
Когда вы хотите поделиться своими наработками, вам необходимо отправить их в удалённый репозиторий. Команда для этого действия простая: git push
. Чтобы отправить вашу ветку master на сервер origin (повторимся, что клонирование обычно настраивает оба этих имени автоматически), вы можете выполнить следующую команду для отправки ваших коммитов:
Просмотр удаленного репозитория
Это был пример для простой ситуации и вы наверняка встречались с чем-то подобным. Однако, если вы используете Git более интенсивно, вы можете увидеть гораздо большее количество информации от git remote show :
Удаление и переименование удалённых репозиториев
Если по какой-то причине вы хотите удалить удаленный репозиторий — вы сменили сервер или больше не используете определённое зеркало, или кто-то перестал вносить изменения — вы можете использовать git remote rm :
При удалении ссылки на удалённый репозиторий все отслеживаемые ветки и настройки, связанные с этим репозиторием, так же будут удалены.
Что такое Git и для чего он используется
Рассказываю про Git – популярнейшую систему контроля версий для разработчиков.
Что такое Git?
Git – это три сервиса в одном. Целый комплекс программных решений, используемых в различных сферах деятельности для отслеживания итераций разрабатываемого продукта.
Чаще всего Git используется в разработке приложений и сайтов, но он также находит применение и в других сферах, например в переводах книг.
Объяснить в двух словах всю систему почти нереально, потому что Git включает в себя настолько разношерстные функции и возможности, что подогнать общую идею под один с ходу понятный термин не представляется возможным. Поэтому начнем с базового определения и постепенно перейдем к конкретным функциям.
Система контроля
Под системой контроля в контексте Git подразумевается программный механизм для работы с контентом. В «работу» также входит хранение, передача данных, отслеживание изменений и прочие аспекты.
Система контроля версий
Как я уже отмечал выше, обычно Git используют для работы с программным кодом. Кодеры ведут разработку своих продуктов, используя систему контроля версий, чтобы иметь полный контроль над своим детищем, над каждой его версией и вариацией.
То есть в любой момент времени можно вернуться в прошлое и восстановить предыдущую версию программы, если новый релиз все поломал. Или когда срочно нужно посмотреть, как выглядел код до рефакторинга.
И это касается не только кода. Переводы больших книг, дизайнерские работы, рисунки и прочее. Правилам работы в системе контроля версий можно подчинить почти любой продукт, и везде от этого будет только польза.
Распределенная система контроля версий
Также Git позволяет вести параллельную разработку, когда несколько программистов одновременно вносят изменения в одно приложение или сайт, но при этом не мешают друг другу и спокойно дополняют продукт, не вызывая сбоев в работе сервиса/сайта/приложения, которое использует их клиент.
Для этого используются удаленные файловые хранилища, где лежат различные вариации кода. Например:
основное приложение со всеми нужными функциями,
его версия с новым дизайном,
новая версия с дополнительными возможностями.
И пока основное приложение остается нетронутым, две его вариации активно развиваются, пока не станут частью основы. Впрочем, этот аспект Git мы еще разберем более подробно.
Зачем нужен Git?
Затем, чтобы не случился апокалипсис в мире разработки (и не только, но мы будем оперировать именно областью IT). Сейчас трудно представить себе мало-мальски крупное приложение, над которым работал бы один человек. За проектом всегда стоит целая команда создателей. И чтобы им всем было комфортно работать вместе, нужна распределенная система контроля версий. Это гарантия отсутствия конфликтов в коде и возможность вести разработку нескольких функций ПО, не соприкасаясь друг с другом и общим кодом.
Более того, в разработке часто меняются требования к проекту, видение заказчика и стандарты дизайна. Поэтому полный контроль над всеми итерациями приложения позволяет легко «откатывать» любые изменения и вносить поверх них новые.
Подробнее о внутреннем строении Git
Репозитории
Репозиторий (репо, реп) – это хранилище файлов проекта. То есть все компоненты, относящиеся к одному приложению (код, изображения, конфигурационные файлы, стили, скрипты и т.п.). С ним как раз и работают люди, ведущие совместную работу над одним продуктом.
Коммиты, пуши и стейджинг
Коммит – это единица контента, хранящая в себе информацию о том, какие компоненты репозитория были изменены на текущий момент времени.
Стейджинг-зона – это временное пристанище измененных файлов. Отправляясь в стейджинг-зону (git add), они помечаются как «в разработке», но при этом из них все еще можно выбрать готовые файлы, чтобы непосредственно их закоммитить. Файлы хранятся в стейджинг-зоне (git add) до тех пор, пока пользователь не сделает коммит и не запушит (git push) изменения на сервер, то есть не выгрузит с локального репозитория в удаленный.
Удаленные репозитории (GitHub, GitLab и т.п.)
Большинство разработчиков хранят репозитории не на локальных машинах, а в хранилищах наподобие GitHub, BitBucket, GitLab и в их аналогах. Это специализированные веб-ресурсы, поддерживающие все функциональные особенности git и позволяющие работать десяткам разработчиков над одним проектом параллельно, используя единое пространство для хранения всех файлов, их версий и прочих компонентов приложения или сайта.
Коммиты остаются в локальном репо, но с помощью команды push можно отправить их в GitHub. А при помощи команды pull можно вытащить их в локальный реп, чтобы иметь под рукой самую новую версию проекта для дальнейшей разработки новых функций.
Ветви и мерджинг
Две функции, вокруг которых строится параллельная разработка.
Ветви (branches) – это разные состояния одной программы. Например, есть ветка master (иногда ее называют main) – в ней обычно хранится приложение с полным набором функций и дизайном, готовое к деплою (то есть публикации в App Store или загрузке на сервер). Есть ветка develop, в которой программисты корпят над нововведениями. Веток может быть неограниченное количество, хоть по одной для каждой функции.
С помощью ветвей можно избежать изменений в программе до того, как новшества будут протестированы. А еще это помогает вносить срочные изменения в main-ветку, не добавляя при этом в программу недоделанные функции или изменения в дизайне.
Мерджинг (merging) – это процесс объединения одной ветки с другой. Чаще всего – ветки develop с веткой main.
Пул-реквесты
Pull Request – это запрос на проверку и одобрение кода. Когда один из программистов заканчивает свою работу, он отправляет PR своим коллегам. Те проводят аудит кода и выносят вердикт, публикуется этот код или нет.
При этом сам пул-реквест является не просто оповещением о готовности куска кода – это целая система взаимодействия и обсуждения. Один PR может превратиться в десятки комментариев и правок кода. После «обработки» PR превращается в мердж.
Разработчики также стали использовать функцию Pull Request Preview, позволяющую подключить к процессу проверки кода дизайнеров, начальство и заказчиков.
С чего начать работу в Git?
Скачиваем git последней версии с официального сайта. Затем создаем директорию для репозитория и переходим в нее с помощью команды cd.
Создаем новый репо:
Теперь можно работать с git. Вот список основных команд:
На этом все. Вас можно поздравить – теперь вы знаете, что такое git и как работать с системой контроля версий.
Синхронизация в Git
В системе SVN используется единый централизованный репозиторий, служащий центром связи для разработчиков. Совместная работа ведется путем передачи наборов изменений между рабочими копиями разработчиков и центральным репозиторием. Однако модель распределенной совместной работы в Git предполагает, что каждый разработчик использует собственную копию репозитория со своей локальной историей и структурой веток. Обычно пользователи делятся не отдельными наборами изменений, а сериями коммитов. Вместо того чтобы выполнять коммит одного набора изменений из рабочей копии в центральный репозиторий, Git позволяет передавать между репозиториями целые ветки.
git remote
Команда git remote позволяет создавать, просматривать и удалять подключения к другим репозиториям. Удаленные подключения скорее похожи на закладки, чем на прямые ссылки на другие репозитории. Они служат удобными именами, с помощью которых можно сослаться на не очень удобный URL-адрес, а не предоставляют доступ к другому репозиторию в режиме реального времени.
Например, на следующем рисунке изображены два удаленных подключения из вашего репозитория к центральному репозиторию и репозиторию другого разработчика. Вместо того, чтобы ссылаться на них по их полным URL-адресам, вы можете передавать командам Git только ярлыки origin и john.
Обзор использования git remote
По сути, команда git remote — это интерфейс для управления списком записей об удаленных подключениях, которые хранятся в файле /.git/config репозитория. Для просмотра текущего состояния списка удаленных подключений используются следующие команды.
Просмотр конфигураций удаленных репозиториев Git
Список ваших удаленных подключений к другим репозиториям.
Аналогично команде выше, но включает URL-адрес каждого подключения.
Создание и изменение конфигураций удаленных репозиториев Git
Команда git remote также предоставляет удобный способ изменения файла /.git/config репозитория. Перечисленные ниже команды позволяют управлять подключениями к другим репозиториям и изменять файл /.git/config репозитория. Такого же результата можно достичь, напрямую отредактировав файл /.git/config с помощью текстового редактора.
Создание нового подключения к удаленному репозиторию. После добавления удаленного репозитория имя ＜name＞ можно использовать в качестве удобного ярлыка для адреса ＜url＞ в других командах Git.
Обсуждение git remote
Git предоставляет каждому разработчику полностью изолированную среду разработки. Информация не передается между репозиториями автоматически. Вместо этого разработчикам нужно вручную загружать вышестоящие коммиты в локальный репозиторий или вручную отправлять локальные коммиты обратно в центральный репозиторий. Команда git remote представляет собой простой способ передачи URL-адресов в эти команды обмена.
Удаленное подключение к origin
В процессе клонирования с помощью команды git clone автоматически создается удаленное подключение к исходному репозиторию (такое соединение называется origin). Это позволяет разработчикам, создающим локальную копию центрального репозитория, легко загружать вышестоящие изменения или публиковать локальные коммиты. Именно поэтому большинство проектов на основе Git называют свой центральный репозиторий origin.
URL-адреса репозиториев
Git поддерживает различные способы ссылки на удаленный репозиторий. Два наиболее простых способа доступа к удаленному репозиторию: протоколы HTTP и SSH. Протокол HTTP — простой способ разрешить к репозиторию анонимный доступ только для чтения. Пример ниже.
Однако HTTP-адрес, как правило, не позволяет отправлять коммиты (в любом случае вы не захотите разрешать анонимную отправку изменений с помощью команды push). Чтобы использовать доступ для чтения и записи следует использовать протокол SSH:
Вам понадобится лишь действующий аккаунт SSH на хост-машине, а в остальном Git поддерживает аутентифицированный доступ через SSH по умолчанию. Необходимые URL-адреса предоставляются современными безопасными решениями для хостинга от сторонних провайдеров, например Bitbucket.com.
Команды git remote
Вывод URL-адресов для записи об удаленном репозитории.
Удаляет из репозитория ＜NAME＞ все локальные ветки, которые отсутствуют в удаленном репозитории.
Примеры git remote
Доступа к индивидуальным репозиториям разработчиков позволяет вести совместную работу за пределами центрального репозитория. Это может быть очень полезно для небольших команд, работающих над большим проектом.
Просмотр удаленных репозиториев
По умолчанию команда git remote отображает ранее сохраненные удаленные подключения к другим репозиториям. Создается однострочный список закладок с именами удаленных репозиториев.
Добавление удаленных репозиториев
Проверка удаленного репозитория
Для получения подробного вывода о конфигурации удаленного репозитория к команде git remote можно добавить подкоманду show. Вывод будет содержать список веток, связанных с удаленным репозиторием, а также конечных точек, подключенных для извлечения (fetch) и отправки (push).
Получение и извлечение данных из удаленных репозиториев Git
Отправка данных в удаленные репозитории Git
Переименование и удаление удаленных репозиториев
Введение в Git: настройка и основные команды
Введение
Git — один из видов систем контроля версий (или СКВ). Такие системы записывают изменения в набор файлов, а позже позволяют вернуться к определенной версии.
Вам может пригодиться СКВ, если вы, например, программист, системный администратор, дизайнер (или в целом работаете с массивом изменяющихся файлов) и хотите сохранить каждую версию проекта. Вы сможете вернуться к любому из сохраненных состояний, просмотреть изменения и увидеть их авторов. Так гораздо проще исправлять возникающие проблемы.
В целом СКВ можно разделить таким образом:
Очевидно, что Git — не единственная система контроля версий, однако по многим параметрам самая удобная и популярная на сегодняшний день. Благодаря распределенной структуре репозитории Git хранятся на всех клиентских компьютерах, что защищает от потерь данных и позволяет полноценно управлять версиями проекта оффлайн.
Главная отличительная черта Git состоит в подходе к обработке данных. Каждый раз при сохранении данных проекта (коммите) система фиксирует состояние файла (делает снимок) и создает ссылку на этот снимок. Последующие изменения отражаются через ссылки на более ранние версии файла. Нет необходимости снова сохранять файл целиком. К тому же, основываясь на контрольных hash-суммах, система снимков обеспечивает целостность всей истории изменений. На практике это означает, что невозможно (либо крайне трудно) полностью удалить данные из рабочего каталога и утратить к ним любой доступ. В большинстве случаев данные можно восстановить из ранней версии проекта.
Таким образом, систему контроля версий в Git проще всего представлять как поток снимков (сохраненных состояний проекта).
Принципы работы с Git
У проектных файлов в Git есть 3 базовых состояния
У Git есть рабочий каталог, где хранятся метаданные и локальная база рабочего проекта. Именно эта часть копируется, когда вы клонируете проект (репозиторий) с сервера.
Чаще всего работа с Git устроена примерно так:
Установка Git
Создать свой проект и начать пользоваться Git в нем достаточно просто. Мы будем рассматривать работу в командной строке терминала, потому что там реализован полный набор команд. Вероятно, в будущем вам будет проще воспользоваться встроенными инструментами в крупном приложении (например, в Visual Studio, если вы программист).
Однако командная строка все равно удобна для тонкой настройки и «нестандартных» действий, поэтому полезно представлять себе, как управлять проектом через нее.
Сначала потребуется установить Git на свой компьютер.
Установка в Linux
Для дистрибутивов, похожих на Fedora, RHEL или CentOS, выполните команду dnf:
На Ubuntu и других Debian-подобных систем введите apt:
Более подробные сведения можно получить по ссылке: https://git-scm.com/download/linux.
Установка на Mac
Один из способов установки — воспользоваться Xcode Command Line Tools. В терминале нужно ввести:
И следовать дальнейшим инструкциям.
Если вы пользуетесь Homebrew, запустите команду:
Установка в Windows
Новейшая сборка доступна на официальном сайте Git по ссылке: https://git-scm.com/download/win (загрузка запустится автоматически).
Настройка Git
Настроить рабочую среду нужно только один раз — после обновлений параметры не сбросятся. Если понадобится, в любое время можно изменить ваши настройки.
Самый удобный способ изменения конфигурации — встроенная утилита git config. Настройки Git имеют три уровня:
Если запускать git config без параметров, будет использоваться локальный уровень, никакие из более глобальных настроек не изменятся.
Всю используемую конфигурацию можно просмотреть так:
Представимся Git, чтобы в рабочих коммитах сохранялось ваше авторство:
Также можно выбрать и текстовый редактор, введя команду git config —global core.editor. Например, чтобы выбрать Emacs, выполните:
В Windows нужно указывать полный путь к файлу. К примеру, для установки Notepad++ нужно запустить подобную команду:
Стоит отметить, что на практике текстовый редактор в Git может и не пригодиться, особенно если вы активно используете стороннее ПО — например, в Visual Studio все текстовые заметки для Git можно писать в отдельном окне. Текстовые редакторы в командной строке отличаются своеобразным управлением, которое потребует от вас отдельного изучения.
Общий список текущих настроек просматривается с помощью команды git config —list. Проверить, что записано в любой из доступных настроек, можно командой с ключом git config :
Выбор ветки по умолчанию
Итак, наконец можно создать репозиторий в выбранном каталоге командой git init. Основная ветка автоматически будет названа master. Изменить это (в нашем случае задав ветку main) можно так:
Работа в репозитории
Как правило, есть два варианта начать работу с репозиторием Git:
Если у вас на компьютере уже есть рабочий проект, но еще не назначен контроль версий, то нужно сначала перейти в каталог проекта.
Команда создаст каталог с именем .git, в котором будут храниться структурные файлы репозитория.
Заодно создадим начальный коммит командой git commit:
Команду git add можно гибко настраивать с помощью дополнительных параметров (флагов), которые подробно описаны в официальной документации: https://git-scm.com/docs/git-add. К примеру, команда git add —force добавит даже игнорируемые файлы, а git add —update позволит обновить отслеживаемые файлы.
В этом репозитории вы можете продолжать работать и дальше, со временем обновляя его и отправляя рабочие версии на сервер.
Клонирование существующего репозитория
Когда вы работаете в команде, разрабатываемые проекты часто размещают на сервере. Это один из самых распространенных сценариев. Вам нужно получить копию проекта последней версии на свой компьютер, чтобы далее вносить в него свой вклад.
Видно, что можно выбрать тип репозитория:
Для нашего примера создадим приватный репозиторий под названием SomeConsoleApp и будем работать с ним далее.
Самые удобные способы клонирования проекта — через протоколы HTTP и SSH, прочесть обо всех более развёрнуто можно по ссылке: https://git-scm.com/book/en/v2/Git-on-the-Server-The-Protocols.
Для наших целей воспользуемся протоколом https и следующей командой:
После получения проекта обычно начинается более рутинный рабочий процесс — правки, добавление функционала и т. д. Далее в какой-то момент вы захотите сохранить прогресс в новой версии проекта.
Правила и периодичность обновления могут быть почти любыми, но хорошим тоном обычно считается сохранять рабочую (или промежуточно завершенную) версию. Важное требование для команд разработчиков — возможность сборки проекта, иначе другие участники команды будут вынуждены тратить время на борьбу с ошибками компиляции.
Сохранение снимков и просмотр статуса проекта
Как упоминалось ранее, часть файлов в рабочем каталоге может и не находиться под контролем версий. За отслеживаемыми файлами «наблюдает» Git, они были как минимум в прошлом снимке состояния проекта. Неотслеживаемыми могут быть, например, вспомогательные файлы в рабочем проекте, если они не зафиксированы в прошлой версии проекта и не готовы к коммиту. Их можно выделить в отдельную категорию для Git, о чем будет рассказано далее.
Сразу после клонирования все файлы проекта будут отслеживаемыми. Отредактировав их и привнеся что-то новое, вы индексируете (stage) и фиксируете (commit) правки, и так для каждой версии проекта.
При этом нужно внимательно следить, чтобы вспомогательные файлы, особенно объемные, оставались вне контроля версий. Если по недосмотру добавить их в коммит и отправить на сервер — вероятнее всего, ваши правки придется частично откатывать.
Проверить состояние файлов в рабочем каталоге можно командой git status. После клонирования консоль выведет примерно такую информацию:
Теперь отредактируем файлы (в этом примере было консольное демо-приложение, созданное с помощью Visual Studio) и сравним статус:
Теперь зафиксируем изменения. В коммит войдут только те файлы, которые вы изменили и добавили командой git add. Остальные будут лишь дополнительными файлами в каталоге проекта.
Стандартный способ — команда git commit, которую мы уже видели раньше. Без дополнительных аргументов она откроет встроенный текстовый редактор, поэтому для простоты рекомендуется добавить аргумент -m и вписать комментарий в кавычках:
Как упоминалось ранее, в рабочий каталог могут попадать файлы, которые вам бы не хотелось отправлять на сервер. Это и документы с вашими экспериментами или образцами, и автоматически генерируемые части проекта, актуальные только на вашем компьютере. Git может полностью игнорировать их, если создать в рабочем каталоге файл с названием .gitignore и внести в него все имена ненужных файлов и папок.
Открывать файл можно в любом текстовом редакторе. Обычно удобнее не перечислять абсолютно все имена (которые к тому же всегда известны), а воспользоваться подобными инструкциями:
Управление удаленными репозиториями
Отправка изменений в удаленный репозиторий (Push)
На вашем компьютере есть проект со внесенными изменениями, но вы хотите поделиться новой версией со всей командой.
Команда для отправки изменений на сервер такова: git push
. Если ваша ветка называется master, то команда для отправки коммитов станет такой:
Она сработает, если у вас есть права на запись на том сервере, откуда вы клонировали проект. Также предполагается, что другие участники команды за это время не обновляли репозиторий.
Следует к тому же помнить, что в разработке для промежуточных правок часто используется не главная ветка (master), а одна из параллельных (например, Dev). Работая в команде, этому обязательно нужно уделять пристальное внимание.
Получение изменений из репозитория (Pull)
Самый простой и быстрый способ получить изменения с сервера — выполнить команду git pull, которая извлечет (fetch) данные с сервера и попытается встроить/объединить (merge) их с вашей локальной версией проекта.
На этом этапе могут возникать конфликты версий, когда несколько человек поработали над одними и теми же файлами в проекте и сохранили свои изменения. Избежать этого можно, если изолировать части проекта, поручив работу над одной частью только одному человеку. Разумеется, на практике это не всегда выполнимо, поэтому в Git есть инструменты для разрешения конфликтов версий. Они будут рассмотрены далее.
Создание веток и переключение между ними
Создадим две дополнительные ветки Dev и Test (например, одна может пригодиться для процесса разработки, а другая — для запуска в тестирование). Введем команду git branch
дважды с разными аргументами:
Ветки созданы, но мы по-прежнему работаем в master. Для переключения на другую нужно выполнить git checkout
:
Внесем некоторые изменения в файл README.md и зафиксируем их, чтобы они отразились в ветке Dev:
Если теперь отправить их на сервер, то можно убедиться в появившемся отличии веток:
Для переключения обратно на ветку master нужно снова ввести команду git checkout master. Она не изменялась, а значит, после редактирования проекта ветки разойдутся. Это нормальная ситуация для проектов в Git. Важно только понимать, для каких целей используется каждая из веток, и не забывать вовремя переключаться между ними.
Слияние веток (merge)
Работа над проектами часто ведется в несколько этапов, им могут соответствовать ветки (в нашем примере Dev → Test → master). Отдельные ветки могут создаваться для срочного исправления багов, быстрого добавления временных функций, для делегирования части работы другому отделу и т. д. Предположим, что нужно применить изменения из ветки Dev, внеся их в master. Перейдем в master и выполним команду git merge :
Изменения успешно перенесены. В наших упрощенных условиях команда завершилась без ошибок, не найдя конфликтов в файлах. Если же над общими участками какого-либо файла успели поработать несколько человек, с этим нужно разбираться вручную. При возникновении ошибок Git помечает общие части файлов из разных веток и сообщает о конфликте.
Для разрешения конфликтов есть консольная утилита git mergetool. Однако если файл проекта объемный, а общих частей много, пользоваться ей не слишком удобно. Общая рекомендация для таких случаев — пользоваться сторонними инструментами, как и в случае с текстовым редактором для Git.
Когда спорные участки всех файлов приведены к итоговому состоянию, нужно повторить стандартную процедуру: создать коммит и отправить их командой push в нужную ветку в репозитории.
Дальнейшая работа с проектом из репозитория Git, как правило, повторяется по алгоритму:
Заключение
Мы рассмотрели, как устанавливать и настраивать Git в различных ОС, создавать новые и клонировать существующие репозитории, получать и отправлять новые версии проекта, а также ознакомились с базовыми концепциями ведения веток.
Этой информации обычно хватает для повседневных задач, связанных с хранением рабочих проектов.