T.M. SoftStudio

feci quod potui, faciant meliora potentes

Купить полную версию книги "Среда разработки Eclipse 4: Руководство разработчика"

  • Командная разработка кода

    Git

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

    Цикл работы в системе Git с новым проектом состоит из следующих этапов:

    1. Создание нового локального проекта.

    2. Создание локального Git-репозитория и размещение в нем нового проекта.

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

    4. Редактирование ресурсов локального проекта с сохранением изменений в локальном репозитории.

    5. Отправка изменений из локального репозитория в удаленный репозиторий.

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

    Цикл работы в системе Git с уже имеющимся в удаленном репозитории проектом состоит из следующих этапов:

    1. Создание локальной копии удаленного репозитория.

    2. Редактирование ресурсов локального проекта с сохранением изменений в локальном репозитории.

    3. Отправка изменений из локального репозитория в удаленный репозиторий.

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

    Локальный Git-репозиторий представляет собой каталог, содержащий папку проекта – рабочий каталог с ресурсами, над которыми идет текущая работа, и папку .git, включающую в себя всю историю и метаданные проекта.

    Каталог .git содержит следующие файлы и папки:

    • Файл index – в рассмотренных выше системах CVS и SVN файлы проекта могут находиться в двух состояниях – измененном локальном состоянии и сохранившим изменения в репозитории. В системе Git существует промежуточное состояние – файл был изменен и подготовлен к сохранению в репозитории. Так вот файл index хранит информацию о таких файлах, т.е. о наборе изменений, которые будут зафиксированы в репозитории. Таким образом, файл index представляет область подготовленных файлов (staging area).

    • Файл HEAD – содержит указатель на ветвь проекта, над которой идет текущая работа в рабочем каталоге.

    • Файл FETCH_HEAD – содержит информацию о полученных изменениях из удаленного репозитория в локальный репозиторий.

    • Файл config – содержит Git-конфигурацию проекта.

    • Папка refs – другое отличие системы Git от рассмотренных выше систем CVS и SVN заключается в том, что система Git не оперирует номерами версий, а использует SHA1 хеши, таким образом, обеспечивая одновременно с идентификацией целостность данных. Каталог refs включает в себя три папки heads, remotes и tags, содержащие файлы с именами локальных ветвей, удаленных ветвей и релизов проекта. В свою очередь каждый такой файл содержит SHA1 хеш последней фиксации (commit) соответствующей ветви.

    Примечание

    Файл HEAD содержит путь в каталоге refs к файлу ветви проекта, над которой идет текущая работа в рабочем каталоге. Файл FETCH_HEAD указывает SHA1 хеши фиксаций, содержащиеся также в файлах папки remotes каталога refs.

    • Папка objects – содержит объекты системы Git. Существует три типа Git-объектов – Blob-объекты, деревья (tree) и фиксации (commit). Объект Blob (Binary Large Object) системы Git – это файл, содержащий бинарные данные заголовка плюс содержимого версии файла проекта, с именем, состоящим из SHA1 хеша содержимого файла Blob-объекта, за исключением первых двух символов. Первые два символа SHA1 хеша содержимого файла Blob-объекта используются для именования папки, в которой содержится Blob-объект. Заголовок содержимого Blob-объекта – это строка «blob [размер] null». Дерево – это файл, содержащий сжатый заголовок плюс одна или несколько записей, с именем, состоящим из SHA1 хеша содержимого файла дерева, за исключением первых двух символов. Первые два символа SHA1 хеша содержимого файла дерева используются для именования папки, в которой содержится дерево. Заголовок содержимого дерева – это строка «tree [размер] null». Запись содержимого дерева – это строка, состоящая из кода доступа, типа объекта (Blob-объект или дерево), SHA1 хеша объекта и имени объекта (имя файла или имя директории). Таким образом, дерево представляет содержимое каталога. Фиксация – это файл, содержащий сжатый заголовок (строка «commit [размер] null») плюс запись, состоящую из указателей на дерево проекта, автора, родительскую и дочернюю фиксации, ветвь проекта и комментария, с именем, состоящим из SHA1 хеша содержимого файла фиксации, за исключением первых двух символов. Первые два символа SHA1 хеша содержимого файла фиксации используются для именования папки, в которой содержится фиксация. Таким образом, фиксация представляет историю. Помимо Blob-объектов, деревьев и фиксаций существует еще специальный объект Tag, представляющий релиз проекта. Объект Tag – это файл, содержащий сжатый заголовок (строка «tag [размер] null») плюс запись, состоящую из указателей на фиксацию проекта, автора, имя релиза и комментария, с именем, состоящим из SHA1 хеша содержимого файла релиза, за исключением первых двух символов. Первые два символа SHA1 хеша содержимого файла релиза используются для именования папки, в которой содержится релиз.

    • Папка logs – содержит историю изменений папки refs.

    • Папка hooks – предназначена для хранения скриптов, вызываемых до или после Git-команд.

  • Интеграцию системы контроля версий Git со средой Eclipse обеспечивает проект Eclipse Git Team Provider (EGit) (http://projects.eclipse.org/projects/technology.egit).

    Проект EGit предоставляет инструменты работы с системой Git для среды Eclipse, созданные на основе проекта JGit.

    Проект JGit представляет Java-реализацию системы контроля версий Git, обеспечивающую:

    • Сommand Line Interface (CLI) – интерфейс командной строки с такими командами как создание пустого репозитория, создание копии удаленного репозитория, фиксация изменений в репозитории, создание ветвей и релизов, передача и получение изменений из удаленного репозитория и др.

    • JGit API – программный интерфейс, позволяющий программным способом из Java-кода выполнять работу с Git-репозиторием.

    • Ant-задачи создания пустого репозитория, создания копии удаленного репозитория, переключения между ветками, извлечения файлов.

    Набор Eclipse-плагинов EGit уже включен в рассмотренный в главе 1 продукт Eclipse Standard.

    В среде Eclipse набор Eclipse-плагинов EGit предоставляет перспективу Git Repository Exploring, которая содержит представления:

    • Git Repositories – обеспечивает управление Git-репозиториями.

    • Properties – позволяет просматривать и редактировать конфигурацию Git-репозитория.

    • History – отображает историю ресурсов.

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

    • Git Reflog – отображает журнал истории Git-репозитория.

    • Git Staging – отображает изменения, добавленные и не добавленные в область подготовленных файлов (файл index).

  • Помимо вышеперечисленных представлений плагин EGit добавит представление Git Tree Compare, доступное с помощью команды Show View | Git меню Window и обеспечивающее сравнение двух фиксаций.

    Кроме того, EGit-плагин добавит в команду File | New мастер Git | Git Repository, помогающий создать Git-репозиторий.

    Общая настройка конфигурации инструментария EGit осуществляется в разделе Team | Git команды Preferences меню Window Workbench-окна.

    При формировании истории изменений в Git-репозитории автоматически добавляется информация об авторе изменений, содержащая имя и e-mail адрес. Для определения имени и e-mail адреса откроем раздел Team | Git | Configuration команды Preferences меню Window и нажмем кнопку Add Entry. В появившемся диалоговом окне в поле Key введем user.name, а в поле Value – свое имя и нажмем кнопку OK. Еще раз нажмем кнопку Add Entry и в поле Key введем user.email, а в поле Value – свой адрес почты и нажмем кнопку OK. Закроем окно Preferences кнопкой OK.

    В процессе работы EGit-плагин ищет переменную HOME для указания каталога, в котором хранятся пользовательские Git-установки. Поэтому в операционной системе Windows полезно создать такую переменную в наборе переменных среды.

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

    Откроем среду Eclipse с установленным EGit-плагином и в перспективе Java в меню File выберем команду New | Other | Java | Java Project, нажмем кнопку Next, введем имя проекта HelloGit и нажмем кнопку Finish. В окне Package Explorer нажмем правой кнопкой мышки на узле проекта и в контекстном меню выберем команду New | Other | Java | Class, нажмем кнопку Next, введем имя пакета main, имя класса Main, отметим флажок public static void main(String[] args) и нажмем кнопку Finish.

    В окне Package Explorer нажмем правой кнопкой мышки на узле проекта и в контекстном меню выберем команду Team | Share Project. В окне мастера Share Project выберем Git и нажмем кнопку Next – появится окно Configure Git Repository, в котором предлагается создать Git-репозиторий в папке каталога проекта, что не рекомендуется, или создать отдельный Git-репозиторий, что соответственно рекомендуется. Поэтому в списке Repository: нажмем кнопку Create, введем имя репозитория hellogit и нажмем кнопки Finish и Finish.

  • В результате проект HelloGit будет перемещен из каталога workspace в каталог git\hellogit, в котором также будет создана папка .git для хранения истории и метаданных проекта в системе Git.

    С помощью команды Show View | Other | Git меню Window откроем представление Git Staging, в котором увидим, что ресурсы проекта не добавлены в область подготовленных файлов (рис. 3.32).

    Рис. 3.32. Представление Git Staging плагина EGit, отображающее неподготовленные к фиксации файлы проекта

    В окне Package Explorer нажмем правой кнопкой мышки на узле проекта и в контекстном меню выберем команду Team | Add to Index. При необходимости обновим представление Git Staging кнопкой Refresh панели инструментов представления и увидим, что файлы проекта переместились в stage-область (рис. 3.33).

    Рис. 3.33. Представление Git Staging плагина EGit, отображающее подготовленные к фиксации файлы проекта

    Для создания первой фиксации в поле Commit message введем комментарий фиксации и нажмем кнопку Commit представления Git Staging. В результате окно Git Staging очистится, так как файлы из stage-области переместятся в область фиксаций.

    Другой способ создать фиксацию – это применить команду Team | Commit контекстного меню окна Package Explorer.

    При создании первой фиксации будет создана головная ветвь проекта master, что соответственно отобразится в каталоге .git\refs\heads, а в каталоге .git\objects будет создан набор Git-объектов.

    Если в контекстном меню окна Package Explorer выбрать команду Team | Show in History, тогда откроется представление History, в котором отобразится информация о фиксации (рис. 3.34).

    Рис. 3.34. Представление History, отображающее фиксации проекта

  • Если в контекстном меню окна Package Explorer выбрать команду Team | Show in Repositories View, тогда откроется представление Git Repositories, в котором отобразится структура репозитория (рис. 3.35).

    Рис. 3.35. Представление Git Repositories, отображающее структуру созданного репозитория

    Если с помощью команды Show View | Other | Git меню Window открыть представление Git Reflog, тогда можно увидеть журнал истории репозитория (рис. 3.36).

    Рис. 3.36. Представление Git Reflog, отображающее журнал истории репозитория

    Создать Git-репозиторий можно также другим способом. С помощью команды Open Perspective | Other меню Window откроем перспективу Git Repository Exploring и в представлении Git Repositories нажмем кнопку Create a new Git Repository and add it to this view панели инструментов представления.

    В окне мастера Create a New Git Repository в поле Name: введем имя репозитория и нажмем кнопку Finish.

    В окне Package Explorer нажмем правой кнопкой мышки на узле проекта и в контекстном меню выберем команду Team | Share Project. В окне мастера Share Project выберем Git и нажмем кнопку Next, в списке Repository: выберем созданный репозиторий и нажмем кнопку Finish. В результате проект будет перемещен из каталога workspace в каталог репозитория.

  • Мастер Create a New Git Repository также предлагает создать bare-репозиторий с помощью флажка Create as bare repository. Такой репозиторий не содержит рабочего каталога, а включает в себя только ресурсы каталога .git. Поэтому bare-репозиторий может использоваться как центральный репозиторий с которым работают другие Git-репозитории, передавая и получая изменения проекта.

    Для создания удаленного Git-репозитория воспользуемся созданным аккаунтом на сайте CloudForge. Зайдем на сайт CloudForge под зарегистрированным логином и паролем и нажмем кнопку Create Project страницы управления.

    В разделе set project info введем имя нового проекта mygit, в разделе add repository отметим флажок Git и нажмем кнопку Create Project (рис. 3.37).

    Рис. 3.37. Создание удаленного Git-репозитория

    На странице проекта в разделе Services раскроем узел Git и увидим адреса соединения с репозиторием по HTTP/SSL и SSH протоколам:

    https://tmsoftstudio@tmsoftstudio.git.cloudforge.com/mygit.git

    ssh://git_tmsoftstudio@tmsoftstudio.git.cloudforge.com/mygit.git

    Другим популярным Git-хостингом является сайт GitHub (https://github.com/), позволяющий бесплатно размещать публичные проекты для совместной работы над ними.

    Для определения конфигурации удаленного репозитория в среде Eclipse в окне Git Repositories нажмем правой кнопкой мышки на узле Remotes структуры репозитория hellogit и в контекстном меню выберем команду Create Remote.

  • В окне мастера New Remote в поле Remote name: введем имя удаленного репозитория CloudForge и нажмем кнопку OK – откроется окно мастера Configure Push.

    В окне мастера Configure Push в поле URI: нажмем кнопку Change и в окне мастера Select a URI в поле URI: введем адрес удаленного репозитория, а в поля User: и Password: введем логин и пароль удаленного репозитория и нажмем кнопку Finish. В окне мастера Configure Push нажмем кнопку Save (рис. 3.38).

    Рис. 3.38. Мастер настройки конфигурации соединения с удаленным Git-репозиторием для передачи ему изменений из локального Git-репозитория

    В результате в окне Git Repositories в узле Remotes структуры репозитория hellogit появится дочерний узел mygit.

    Для передачи проекта HelloGit из локального репозитория в удаленный репозиторий в окне Package Explorer нажмем правой кнопкой мышки на узле проекта и в контекстном меню выберем команду Team | Remote | Push. В окне мастера Push to Another Repository нажмем кнопку Next, в списке Source ref: выберем HEAD, нажмем кнопку Add All Branches Spec, отметим флажок refs/heads/* и нажмем кнопку Finish (рис. 3.39).

    Рис. 3.39. Мастер передачи изменений из локального Git-репозитория в удаленный Git-репозиторий

    В результате будет произведена закачка проекта HelloGit на сайт CloudForge, что можно будет проверить, перейдя по ссылке Browse with GitWeb раздела Git страницы проекта.

  • Передачу изменений из локального репозитория в удаленный репозиторий также можно осуществить с помощью команды Push контекстного меню представления Git Repositories.

    Для централизованного хранения изменений проекта также можно использовать bare-репозиторий.

    Создадим bare-репозиторий, используя кнопку Create a new Git Repository and add it to this view панели инструментов представления Git Repositories и флажок Create as bare repository мастера Create a New Git Repository.

    В окне Git Repositories нажмем правой кнопкой мышки на узле Remotes структуры репозитория hellogit и в контекстном меню выберем команду Create Remote.

    В окне мастера New Remote в поле Remote name: введем имя bare-репозитория и нажмем кнопку OK – откроется окно мастера Configure Push.

    В окне мастера Configure Push ниже поля Push URIs: нажмем кнопку Add и в окне мастера Select a URI в поле URI: нажмем кнопку Local File, выберем каталог bare-репозитория и нажмем кнопку Finish. Закроем окно мастера Configure Push кнопкой Save. С помощью команды Push передадим master-ветвь проекта HelloGit в bare-репозиторий.

    Для настройки конфигурации соединения с удаленным Git-репозиторием для получения из него изменений в локальный Git-репозиторий в окне Git Repositories нажмем правой кнопкой мышки на узле Remotes | mygit структуры репозитория hellogit и в контекстном меню выберем команду Configure Fetch.

    В окне мастера в поле URI: нажмем кнопку Change и в окне мастера Select a URI в поле URI: введем адрес удаленного репозитория, а в поля User: и Password: введем логин и пароль удаленного репозитория и нажмем кнопку Finish.

    В окне мастера Configure Fetch нажмем кнопку Advanced – появится мастер Fetch Ref Specifications. В окне мастера Fetch Ref Specifications в списке Source ref: выберем master, нажмем кнопку Add All Branches Spec, отметим флажок refs/heads/* и нажмем кнопку Finish. Закроем окно мастера Configure Fetch кнопкой Save.

    В результате в окне Git Repositories в узле mygit появится дочерний узел Fetch-соединения, нажав правой кнопкой мышки на котором и в контекстном меню выбрав команду Fetch – в локальный репозиторий из удаленного репозитория загрузится фиксация master-ветви проекта, что отобразится в окне Git Repositories узлом Fetch_Head раздела References. Если нажать правой кнопкой мышки на узле Fetch_Head и в контекстном меню выбрать команду Checkout, тогда в рабочий каталог проекта загрузится фиксация, полученная из удаленного репозитория.

    Кнопка Clone a Git Repository and add the clone to this view представления Git Repositories позволяет создать локальную копию удаленного репозитория, а команда Import | Git | Projects from Git меню File обеспечивает импорт проекта из клонированного локального репозитория в Workspace-пространство среды Eclipse.

    Команда Team контекстного меню окна Package Explorer содержит следующие операции:

    • Commit – фиксация изменений в репозитории.

    • Remote | Fetch From – загрузка фиксаций из удаленного репозитория в локальный репозиторий.

    • Remote | Fetch from Gerrit – загрузка изменений из сервера Gerrit Code Review Server. Gerrit – это система ревизии кода, разработанная Google и интегрированная с системой Git. Система Gerrit позволяет отправить патч на Gerrit-сервер, проголосовать за изменения, которые отправленный патч представляет, и применить патч к ветви проекта.

    • Remote | Push – отправка изменений из локального репозитория в удаленный репозиторий.

    • Remote | Push to Gerrit – загрузка изменений на сервер Gerrit Code Review Server.

    • Switch To – переключение рабочего каталога на другую ветвь проекта.

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

    • Pull – выполняет операцию Fetch с последующим выполнением операции Merge, поэтому для выполнения операции Pull в файл config Git-репозитория, в рассматриваемом примере, должна быть включена строка «remote = mygit merge = refs/heads/master[remote "mygit"]», с указанием, конечно, url-адреса удаленного репозитория (тоже самое – определены свойства branch.master.merge, branch.master.remote и remote.mygit.url в окне Properties для репозитория hellogit).

    • Synchronize Workspace – синхронизация рабочего каталога с репозиторием.

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

    • Merge Tool – разрешить конфликты с помощью инструмента Merge Tool.

    • Reset – сбрасывает stage-область, HEAD-область и рабочее дерево.

    • Rebase – обеспечивает слияние ветвей с созданием линейной истории.

    • Create Patch – создать патч изменений.

    • Apply Patch – применить патч изменений.

    • Ignore – добавляет файлы в список .gitignore для вывода их из-под контроля версий.

    • Add to Index – добавляет изменения в stage-область и новые ресурсы под контроль версий.

    • Remove from Index – удаляет изменения из stage-области.

    • Show in Repositories View – показывает ресурс в представлении Git Repositories.

    • Show in History – показывает историю ресурса в представлении History. Контекстное меню представления History позволяет загрузить фиксацию, создать ветвь, релиз и патч, отменить и сбросить изменения, произвести слияние и добавить в контекст Mylyn-задачи.

    • Disconnect – разъединяет с репозиторием.


Mercurial