Настройка работы системы контроля версий типов импортируемых файлов

Обновлено: 02.07.2024

Система контроля версий (англ. 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 ) - программное обеспечение сохраняющее все версии возможного файла, и дающее возможность получить к ним доступ. Система контроля версий значительно ускоряет работу команды с кодом и снижает вероятность ошибок.

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

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

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

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

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

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

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

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

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

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

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

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

Репозиторий

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

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

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

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

Коммит

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

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

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

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

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

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

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

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

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

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

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

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

Для взаимодействия с системой Git в консоль вводятся специальные команды. Не пугайтесь, работу с консолью можно будет заменить на работу с одной из программ, о которых расскажем ниже. Но чтобы лучше понимать суть, придётся запомнить несколько команд. Все они начинаются с ключевого слова git . Для синхронизации есть две основных команды: pull (англ. «тянуть») и push (англ. «толкать»).

Если работа над проектом ведётся в команде, то перед тем как начать писать код, нужно получить последнюю версию проекта. Для этого нужно выполнить команду 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 и прочие — просто нажав на кнопку.

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

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

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

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

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

Реализовать такую процедуру помогает использование системы контроля версий (СКВ), которое позволяет четко отследить историю разработки, найти стабильную версию и продолжить работу.

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

Как осуществляется контроль версий

Существует несколько моделей хранения данных:

Примитивная модель хранения версий

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

Достоинства:

Недостатки:

Локальные системы контроля версий

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

Локальные системы контроля версий

Достоинства:

Недостатки:

Централизованные системы контроля версий

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

Централизованные системы контроля версий

Достоинства:

Недостатки:

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

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

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

Достоинства:

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

Существует много систем контроля версий (Git, Darcs, Mercurial, Bazaar, Monotone и т.д), сходных по принципу работы и конечным задачам. Отличаются они друг от друга архитектурой, использованными решениями и удобством работы.

Самая популярная на сегодняшний день система контроля версий – Git.

Git

Git – распределённая система контроля версий. Что даёт ей все преимущества децентрализованной СКВ:

Для контроля версий в git используются 2 репозитория: локальный и удаленный. Локальный репозиторий (полноценный репозиторий, а не ссылки или копии отдельных ветвей) находится на компьютере разработчика, а удаленный на удалённом сервере. Доступ к удаленному репозиторию обеспечивается благодаря гит-хостингу Github, Google Code, GitLab и т.д.

Как работает git

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

Команда push копирует новые данные, содержащиеся в локальном репозитории, в удалённый репозиторий, а команда pull передает данные из удаленного репозитория в локальный.

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

Дерево проекта

Дерево файлов в системе контроля версий

В репозитории содержится «дерево» проекта, то есть все сохраненные версии файлов.

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

К появлению «веток» приводит работа с более ранними версиями и сохранение внесённых изменений.

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

Git-хостинг

Для комфортной работы с git нужно зарегистрироваться на любом git-хостинге. Их довольно много: Github, Sourceforge, Google Code, GitLab, Codebase и т.д.

Самый популярный на данный момент git-хостинг – это Github.

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

Git-клиент

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

Многие IDE предполагают возможность работы с git.

Работа с Git через IDE

Git — один из видов систем контроля версий (или СКВ). Такие системы записывают изменения в набор файлов, а позже позволяют вернуться к определенной версии.
Вам может пригодиться СКВ, если вы, например, программист, системный администратор, дизайнер (или в целом работаете с массивом изменяющихся файлов) и хотите сохранить каждую версию проекта. Вы сможете вернуться к любому из сохраненных состояний, просмотреть изменения и увидеть их авторов. Так гораздо проще исправлять возникающие проблемы.

В целом СКВ можно разделить таким образом:

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

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

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

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

Принципы работы с Git

У проектных файлов в Git есть 3 базовых состояния

Измененные (modified) — файлы в процессе рабочего редактирования.
Индексированные (staged) — та часть измененных файлов, которая уже подготовлена к фиксации после редактирования.
Зафиксированные (committed) — файлы, уже сохраненные в локальном репозитории.

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

Чаще всего работа с Git устроена примерно так:

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

Установка Git

Создать свой проект и начать пользоваться Git в нем достаточно просто. Мы будем рассматривать работу в командной строке терминала, потому что там реализован полный набор команд. Вероятно, в будущем вам будет проще воспользоваться встроенными инструментами в крупном приложении (например, в Visual Studio, если вы программист).

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

Сначала потребуется установить Git на свой компьютер.

Установка в Linux

Для дистрибутивов, похожих на Fedora, RHEL или CentOS, выполните команду dnf:

На Ubuntu и других Debian-подобных систем введите apt:

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

Один из способов установки — воспользоваться Xcode Command Line Tools. В терминале нужно ввести:

И следовать дальнейшим инструкциям.

Если вы пользуетесь Homebrew, запустите команду:

Установка в Windows

Настройка Git

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

Самый удобный способ изменения конфигурации — встроенная утилита git config. Настройки Git имеют три уровня:

Если запускать git config без параметров, будет использоваться локальный уровень, никакие из более глобальных настроек не изменятся.

Всю используемую конфигурацию можно просмотреть так:

Представимся Git, чтобы в рабочих коммитах сохранялось ваше авторство:

В Windows нужно указывать полный путь к файлу. К примеру, для установки Notepad++ нужно запустить подобную команду:

Стоит отметить, что на практике текстовый редактор в Git может и не пригодиться, особенно если вы активно используете стороннее ПО — например, в Visual Studio все текстовые заметки для Git можно писать в отдельном окне. Текстовые редакторы в командной строке отличаются своеобразным управлением, которое потребует от вас отдельного изучения.

Выбор ветки по умолчанию

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

Работа в репозитории

Как правило, есть два варианта начать работу с репозиторием Git:

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

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

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

И, наконец, нужно добавить под контроль версий все существующие файлы командой git add . (точка в конце важна!). Можно добавлять и по одному файлу, с помощью git add <имя файла>.

Заодно создадим начальный коммит командой git commit:

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

Клонирование существующего репозитория

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

Видно, что можно выбрать тип репозитория:

публичный (public) – доступ открыт для любого пользователя, однако права на редактирование выдает владелец проекта;
приватный/скрытый (private) — проект виден только владельцу, другие участники добавляются вручную.

Для нашего примера создадим приватный репозиторий под названием SomeConsoleApp и будем работать с ним далее.

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

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

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

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

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

Сразу после клонирования все файлы проекта будут отслеживаемыми. Отредактировав их и привнеся что-то новое, вы индексируете (stage) и фиксируете (commit) правки, и так для каждой версии проекта.

Проверить состояние файлов в рабочем каталоге можно командой git status. После клонирования консоль выведет примерно такую информацию:

Теперь отредактируем файлы (в этом примере было консольное демо-приложение, созданное с помощью Visual Studio) и сравним статус:

Теперь зафиксируем изменения. В коммит войдут только те файлы, которые вы изменили и добавили командой git add. Остальные будут лишь дополнительными файлами в каталоге проекта.

Стандартный способ — команда git commit, которую мы уже видели раньше. Без дополнительных аргументов она откроет встроенный текстовый редактор, поэтому для простоты рекомендуется добавить аргумент -m и вписать комментарий в кавычках:

Для удаления ненужных файлов из репозитория можно использовать команду git rm <file-name>. Файл также пропадет из рабочего каталога. Выполнить коммит необходимо и в этом случае; до тех пор структура проекта не изменится.

Файл .gitignore

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

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

Если прописать такое содержимое файла .gitignore, то репозиторий git будет полностью игнорировать папки /bin и /obj, а также любые файлы с расширениями .pdb и .exe, хранящиеся в вашем рабочем каталоге.

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

Управление удаленными репозиториями

Просмотреть список текущих онлайн-репозиториев можно командой git remote. Добавить другие — с помощью команды git remote add <shortname> <url>, например:

Отправка изменений в удаленный репозиторий (Push)

На вашем компьютере есть проект со внесенными изменениями, но вы хотите поделиться новой версией со всей командой.

Команда для отправки изменений на сервер такова: git push <remote-name> <branch-name>. Если ваша ветка называется master, то команда для отправки коммитов станет такой:

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

Следует к тому же помнить, что в разработке для промежуточных правок часто используется не главная ветка (master), а одна из параллельных (например, Dev). Работая в команде, этому обязательно нужно уделять пристальное внимание.

Получение изменений из репозитория (Pull)

Самый простой и быстрый способ получить изменения с сервера — выполнить команду git pull, которая извлечет (fetch) данные с сервера и попытается встроить/объединить (merge) их с вашей локальной версией проекта.

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

Создание веток и переключение между ними

Создадим две дополнительные ветки Dev и Test (например, одна может пригодиться для процесса разработки, а другая — для запуска в тестирование). Введем команду git branch <branch-name> дважды с разными аргументами:

Ветки созданы, но мы по-прежнему работаем в master. Для переключения на другую нужно выполнить git checkout <branch-name>:

Внесем некоторые изменения в файл README.md и зафиксируем их, чтобы они отразились в ветке Dev:

Для переключения обратно на ветку master нужно снова ввести команду git checkout master. Она не изменялась, а значит, после редактирования проекта ветки разойдутся. Это нормальная ситуация для проектов в Git. Важно только понимать, для каких целей используется каждая из веток, и не забывать вовремя переключаться между ними.

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

Работа над проектами часто ведется в несколько этапов, им могут соответствовать ветки (в нашем примере Dev → Test → master). Отдельные ветки могут создаваться для срочного исправления багов, быстрого добавления временных функций, для делегирования части работы другому отделу и т. д. Предположим, что нужно применить изменения из ветки Dev, внеся их в master. Перейдем в master и выполним команду git merge <source-branch>:

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

Для разрешения конфликтов есть консольная утилита git mergetool. Однако если файл проекта объемный, а общих частей много, пользоваться ей не слишком удобно. Общая рекомендация для таких случаев — пользоваться сторонними инструментами, как и в случае с текстовым редактором для Git.

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

Заключение

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

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

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