Совместная разработка ПО с использованием GIT
Joint development of software using GITУДК 004.45 02.02.2017 Выходные сведения: Авторы: Тимошина Н. В., кандидат педагогических наук, доцент кафедры информатики и информационных технологий КГУ им К.Э. Циолковского. Authors: Timoshina N. V., Candidate of Pedagogic Sciences, Associate Professor at the Department of Computer Science and Information Kaluga State University named after K. E. Tsiolkovsky. Ключевые слова: Keyword: Аннотация: В статье дана характеристика основных команд, которые используются при работе с Git, приведены отличия в принципах работы по сравнению с другими системами контроля версий, рассмотрен механизм «веток» – мощнейшего инструмента созданий разных версий проекта, который особенно важен при разработке больших проектов. Рассмотрен веб-сервис GitHub, который имеет непосредственное отношение к самой системе Git. Annotation: The article provides a description of basic commands that are used when working with the Git, given the differences in the principles of operation in comparison with other version control systems, the mechanism of «branches» — the most powerful tool for creating different versions of the project, which is especially important in the development of large projects. Consider a Web service GitHub, which is directly related to the most Git system. Практически любой программный продукт – это труд не одного человека. Если проект начинал разрабатываться программистом-одиночкой, то однажды настанет момент, когда для его поддержки и дальнейшего развития понадобится целая команда разработчиков. В связи с этим встает вопрос о правильной и, главное, эффективной организации совместной разработки систем, а также контролем всего процесса разработки [12]. Появляется необходимость отслеживания всех манипуляций с файлами проекта и, при необходимости, возврат их до определенного состояния [10]. Системы, решающие эту проблему, были названы системами контроля версий (Version Control System, VCS). Под системой контроля версий понимается механизм сохранения промежуточных состояний кода разрабатываемого приложения [13]. Однако, с момента появления первых версий подобных систем прошло достаточно много времени, вместе с тем выросли и потребности: сейчас системы контроля версий позволяют вести совместную разработку, производить синхронизацию с сервером и многое другое. Системы контроля версий актуальны не только в области разработки ПО. Например, всем известный Microsoft Office – офисный пакет приложений – также позволяет контролировать версии документа: с некоторым промежутком времени документ автоматически сохраняется, что позволяет в будущем вернутся к определенной версии. Это наиболее примитивная реализация системы контроля версий, однако для MS Office этого вполне достаточно. Существует несколько различных систем контроля версий, которые отличаются принципами работы, областью их использования и концепциями в целом. Какие-то их них более популярны, какие-то – менее, однако каждая их них выполняет свою главную задачу – контролирует версии разрабатываемой системы. Системы контроля версий делят на распределенные и централизованные. В централизованных системах есть единое хранилище кода, управляемое специальным сервером, который и выполняет большую часть функций по управлению версиями [7]. Однако при таком подходе есть и несколько серьёзных недостатков. Наиболее очевидный — централизованный сервер является уязвимым местом всей системы. Если сервер выключается на час, то в течение часа разработчики не могут взаимодействовать, и никто не может сохранить новой версии своей работы [8]. Распределенные системы работают иначе: здесь не просто выгружается последняя версия файлов с сервера, а полностью копируется репозиторий. Это позволяет вести работу с системой вне зависимости от того, что происходит с самой системой. Наиболее популярной системой контроля версий в данный момент является Git. Она была разработана Линусом Торвальдсом, создателем операционной системы с открытым исходным кодом Linux, в 2005 году. По сей день Git используется для управления разработкой ядра GNU/Linux, а также для множества других проектов. Чтобы понять необходимость использования систем контроля версий, необходимо выяснить, что они контролируют, какие проблемы решают и насколько упрощают разработку. Системы контроля версий позволяют отслеживать любые изменения в коде разрабатываемого приложения и фиксировать их как отдельную версию всего приложения. Это позволяет в любой момент времени откатится на любую из предыдущих версий приложения, отменить определенные изменения и просто отслеживать процесс разработки. Системы контроля версий хранят большие объемы информации о том, когда и какие изменения в коде были сделаны [11]. Контроль изменения файлов – базовая функциональность систем контроля версий, которая исходит из их названия. Современные системы контроля версий позволяют разрабатывать приложение в команде, а также производить синхронизацию всех изменений с репозиторием. Как говорилось ранее, существует несколько различных систем контроля версий: SVN, Mercurial, Bazaar и др. Git имеет ряд преимуществ перед своими аналогами. Во-первых, Git отличается принципом хранения информации об изменениях. Большинство других систем контроля версий, таких как Subversion, для хранения новых версий используют дельта-компрессию, т.е. система находит отличия новой версии от предыдущей и записывает только их, избегая дублирования данных [4]. Git же считает хранимые данные набором слепков небольшой файловой системы. При каждой операции фиксации изменений Git, по сути, сохраняет слепок того, как выглядят все файлы проекта на текущий момент. Это позволяет экономить память, а также дает возможность иметь на локальной машине всю историю изменений всего проекта, при этом не требуя доступа к репозиторию, что является важным аспектом использования систем контроля версий, и чего другие системы не предоставляют. В-вторых, Git работает локально. Для совершения большинства операций необходимы только локальные ресурсы. Это позволяет добиться высокой скорости работы с Git: например, при просмотре изменений файла, Git не будет запрашивать какие-либо данные у сервера: все изменений хранятся на локальном компьютере и доступны в любой момент, а благодаря уникальным принципам хранения этих изменений Git занимает меньше памяти на жестком диске. Git оперирует большим количеством команд, но для повседневной работы с ним достаточно всего нескольких. Рассмотрим их по порядку. Git clone – команда клонирования удаленного репозитория на локальную машину. Git add – команда добавления рабочей директории в индекс (staging area) для последующего коммита. Git status позволяет узнать, в каком состоянии находятся файлы в рабочей директории: изменения, ожидание коммита и т.д. Git commit фиксирует изменения файлов, добавленных в индекс с помощью git add. При этом, по сути, создается новая версия системы. Важно понимать, что файлы в Git могут находится в одном из трех состояний (рис 1).
Рисунок 1. Состояние файлов в Git
Рабочий каталог (Working Directory) – это копия определенной версии проекта. Именно рабочий каталог копируется из репозитория при выполнении команды git clone. Область подготовленных файлов (Staging area) – это файл, который хранит информацию о изменениях, которые войдут в следующий коммит. Репозиторий (Repository) – место хранения зафиксированных измененй. Git push отправляет зафиксированные изменения в главный репозиторий. Git pull – наоборот, забирает с удаленного репозитория все новые изменения. Git merge производит слияние изменений нескольких «веток» (branches). Ветки – это мощный инструмент в разработке. Чтобы понять всю его суть, представим ситуацию, когда есть задача по разработке некого функционала, которая займет довольно много времени. Однако, вместе с тем, на протяжении всего этого времени есть необходимость вносить другие, мелкие изменения в проект, но при этом не затрагивая все данные нового функционала. В таких ситуациях используют ветки: под разработку новых модулей создается новая ветвь, и вся разработка ведется в ней. Между ветвями можно переключаться, таким образом появляется несколько различных версий проекта, разработка которых может вестись параллельно. Ветки, как правило, создаются для отдельных фаз разработки проекта и для предрелизных версий, в которых ведется устранение ошибок [5]. При выполнении операции слияния ветвей Git сравнивает содержимое соответствующих фиксаций, затем объединяет состояния репозитория разных версий проекта, формируя новую версию [2]. Для распределенных систем контроля версий ветки разработки являются одной из основополагающих концепций – в большинстве случаев каждая копия хранилища версий является веткой разработки [3].
Рисунок 2. Ветвление и слияние веток в Git
Когда новые модули разработаны и протестированы, ветки сливаются: все изменения заносятся в главную ветку (master). При этом, конечно, могут возникать конфликты, в случае если один и тот же файл был одновременно изменен несколькими разработчиками. Обычно в таких случаях система не в состоянии самостоятельно обновить проект и требует вмешательства со стороны разработчика. [1] Также, Git решает проблему обновления (деплоя, развертывания) на сервере, где система непосредственно работает (production). Для этого сервере так же устанавливается Git и обновляет данные из репозитория командой git pull. Для того, чтобы автоматизировать этот процесс, многие сервисы для хранения проектов, работающие с Git, предоставляют механизм веб-хуков (WebHooks). Работает это следующим образом: при любом изменении в репозитории отправляется HTTP-запрос на сервер приложения, где заранее настроенный скрипт запускает команду обновления данных с основного репозитория. На базе Git создана социальная сеть для разработчиков под названием GitHub. Это не просто сервис хранения кода: участники сети могут участвовать в разработке любого открытого проекта, получать сообщениях об ошибках от участников сообщества и предлагать свои решения. GitHub предоставляет доступ к проектам как для группы разработчиков, так и для контролирующей группы. При этом зоны действия полномочий обеих групп не пересекаются [6]. Git – популярнейшая система контроля версий среди разработчиков. Такие корпорации, как Google, Microsoft и другие используют его для части своих проектов. Кроме того, для контроля версий популярнейшего движка для отображения веб страниц под названием Webkit, который используется в большинстве современных веб-браузеров, разработчики используют именно Git, а его исходные коды размещены на GitHub. Стоит сказать, что репозиторий Webkit – один из наиболее популярных по количеству коммитов на Github, количество которых достигло 180 тысяч. Команды разработчиков, использующие Git, освобождены от большого количества проблем командной разработки проектов. Можно сказать, что Git решает большинство проблем еще до их появления, ускоряет и удешевляет процесс разработки [9]. Каждый разработчик изолированно работает над своей задачей, не мешая остальным. Git делает резервные копии проекта, позволяя вернуться в исходное состояние при возникновении ошибок, а деплой приложения становится задачей, решаемой всего несколькими git-командами. Все это экономит время разработчиков на выполнение рутинных (и не очень) операций, позволяя сосредоточиться непосредственно на разработке. Git, по сравнению с другими системами контроля версий, сложнее в освоении, поэтому разработчики боятся начать им пользоваться. Однако, перейдя на него и поработав с ним некоторое время, приходит понимание того, что git – это не просто модная тенденция современной разработки информационных систем, а инструмент, позволяющий вести разработку правильно.
Библиографический список 1.Алексеевский П. И. Применение средств управления версиями для коллективной работы студентов над проектом компьютерной игры // Педагогическое образование в России. 2012. №6. URL: http://cyberleninka.ru/article/n/primenenie-sredstv-upravleniya-versiyami-dlya-kollektivnoy-raboty-studentov-nad-proektom-kompyuternoy-igry (дата обращения: 15.12.2016). References 1.Alekseevskij P. I. Primenenie sredstv upravlenija versijami dlja kollektivnoj raboty studentov nad proektom komp’juternoj igry // Pedagogicheskoe obrazovanie v Rossii. 2012. No. 6. URL: http://cyberleninka.ru/article/n/primenenie-sredstv-upravleniya-versiyami-dlya-kollektivnoy-raboty-studentov-nad-proektom-kompyuternoy-igry (accessed: 15.12.2016). |
