Giggle: графический интерфейс для Git

Библиотека сайта или "Мой Linux Documentation Project"

Оригинал: "Giggle: A Git GUI"
Автор: Jake Edge
Дата публикации: June 2nd, 2010
Перевод: Н.Ромоданов
Дата перевода: июнь 2010 г.

В течение примерно пяти лет, пока повсюду шло распространение распределенной системы контроля версий Git, она получила достаточное количество приверженцев. Но по своей сути, Git ориентирована на использование в командной строке, что не всегда нравится всем его пользователям. В течение всего этого времени для Git создавались различные графические интерфейсы, в том числе два инструментальных средства на базе Tcl/Tk. которые поставляется совместно с Git. Пакет Giggle является графической оболочкой для Git, созданной на основе GTK+, версия с номером 0.5 которой была выпущена в апреле этого года.

Вместе с Git поставляются два инструментальных пакета, которые предназначены для выполнения двух различных задач: gitk предназначен для просмотра репозитария, тогда как git-gui предоставляет возможность изменять содержимое репозитария с помощью операций закоммичивания файлов, слияния, создания версий и т.д. Их комбинация обеспечивает достаточно полные функциональные возможности доступа к Git, но из-за того, что его пользовательский интерфейс, сделан на основе Tcl/Tk, не хватает наглядности. Кроме того, эти пакеты не интегрирутся с рабочим столом GNOME, как визуально, так и функционально, что пытается сделать пакет Giggle (и другие пакеты).

В Giggle сочетаются в одной программе средства просмотра репозитария и функции его изменения, но набор функций, используемых для изменения, все еще отстает от имеющихся в git-gui. В Giggle есть два режима: "Browse" ("Обзор") - для дерева исходных кодов и "History" ("История") - для просмотра операций коммит, выполняемых в репозитарии.

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

В режиме просмотра также есть возможность использовать другие операции, такие как редактирование или коммит файлов, создание ветви или патча и т.д. Двойной щелчок по имени файла вызовет переход в режим редактирования, хотя, как выбирается конкретный редактор, напоминает головоломку. Для репозитария ядра Linux в качестве подходящего выбирается редактор Emacs, но для кода для сайта LWN, в качестве подходящего выбирается редактор KWrite. Можно предположить, что последний берется из недр настроек KDE как вариант редактора, используемого по умолчанию, но неясно откуда берется Emacs — возможно, сыграло свою роль использование различных языков реализации (Python вместо C).

Это указывает на еще одну из причин, из-за которой Giggle довольно трудно использовать: отсутствие какой-либо документации. Можно просто щелкнуть мышкой и увидеть, что произошло, но небольшое руководство для пользователей было бы к месту. Кроме единственного способа выяснить, как работает пакет Giggle - "щелкнуть мышкой и увидеть", у него есть другой большой недостаток: производительность.

Производительность Giggle довольно слаба, особенно если учесть, что в инструменте, для которого предназначен этот пакет, определенное внимание уделяется скорости работы. На запуск Giggle для репозитария ядра Linux прежде, чем появится интерфейс, которым можно будет пользоваться, тратится 15-20 секунд при 99% загрузки процессора. Это можно было бы как-то объяснить при использовании огромного репозитария с большим количеством файлов и версий, таким как ядро Linux, но ситуация точно такая же и в случае с репозитарием гораздо меньшего размера.

Дело не только в том, что запуск пакета медленный. Переход из режима просмотра в режим истории может иногда занять до 10 секунд. При прокрутке истории пакет Giggle может на некоторое время перейти в паузу из-за недостатка ресурсов процессора. В целом, от практического использования пакета сложилось достаточно тягостное впечатление, особенно в сравнении с gitk. который работает достаточно быстро. В течение часа использования Giggle, пакет несколько раз прекращал правильно работать и зависал.

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

С момента создания проекта в январе 2007 года в него постоянно добавляются новые функции. В последнее время релизы выпускаются довольно часто, а с января этого года — более или менее ежемесячно, но перед этим в течение почти года проект находился в состоянии стагнации. Пока неясно, каковы планы для релиза 0.6 и далее, хотя в списке открытых вопросов (list of open issues ), указаны некоторые идеи, касающиеся ошибок и возможностей, которые, вероятно, будут реализовываться.

Есть и другие довольно активно разрабатываемые пакеты графического интерфейса для Git, в том числе пакет git-cola. разрабатываемый на основе Python/Qt4, и пакет gitg. в котором также используется GTK+. В последнем пакете внимание также уделяется клиентам Git для Windows и MacOS, тем самым делается попытка реализовать согласованный интерфейс к Git для всех трех платформ. В частности, особое внимание уделяется интерфейсу GitX для MacOS X.

Помимо чисто визуальной привлекательности (а графический интерфейс Tk, безусловно, имеет довольно неуклюжий вид), создается впечатление, что в действительности Giggle и другие графические интерфейсы для Git не дают ничего существенно большего, чем делают пакеты gitk и git-gui. Это можно объяснить довольно медленными темпами развития этих инструментов, поскольку каждому, кому действительно нужен графический пользовательский интерфейс для Git, уже что-то имеет под рукой. Также вероятно, что автономный графический интерфейс менее интересен для тех, кто привык к интегрированным средствам разработки (IDE), таким как Eclipse.

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

Эта статья еще не оценивалась

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

Git меняет правила игры в распределенной Web-разработке

Системы управления версиями (version control systems, VCS) предоставляют механизм внесения изменений в файлы проекта и управления ими и широко используются в командной разработке ПО, документации и других онлайновых проектах. Системы VCS важны для проектов разработки не меньше, чем системы резервного копирования, так как они позволяют множеству пользователей фиксировать изменения в одних и тех же файлах проекта, не рискуя при этом случайно перезаписать изменения своих коллег.

• CSS: каскадные таблицы стилей (Cascading Style Sheet)
• GUI: графический интерфейс пользователя (Graphical user interface)
• HTML: язык разметки гипертекста (Hypertext Markup Language)
• HTTP: протокол передачи гипертекста (Hypertext Transfer Protocol)

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

В Linux и UNIX® применяется чрезвычайно много систем VCS, начиная от таких динозавров, как RCS и CVS и заканчивая современными системами, такими как Subversion, Mercurial, Bazaar, Arch и Darcs. По иронии судьбы (особенно по отношению к Linux), Git была разработана для замены коммерческой VCS BitKeeper, которая обладала впечатляющими уникальными возможностями и имела бесплатную версию. BitKeeper все так же является впечатляющей системой, но изменения в схеме ее лицензирования, в конце концов, вынудили Торвальдса искать альтернативу, и, в лучших традициях свободного ПО, он решил написать свою собственную VCS. Как и ядро Linux, Git теперь является продуктом расширений, исправлений и иного участия в нем несчетного числа разработчиков ПО с открытым кодом.

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

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

• Использование центрального репозитория с одновременным предоставлением каждому разработчику полной копии исходного кода проекта. Это гарантирует, что все разработчики могут выполнить свою работу независимо от текущего состояния своего соединения.
• Обеспечение быстрой и надежной поддержки создания внутри проекта отдельных рабочих пространств, называемых ветвями. и слияний. т.е. распространения изменений из одной ветви проекта в другие. Ветви облегчают поддержку различных версий пакета, независимо от того, являются ли эти версии постоянными или же они созданы для экспериментов. Слияния являются ключевым аспектом всех систем управления версиями, а особое распространение они имеют в VCS, ориентированных на ветви.
• Реалзация легкого обмена изменениями в ветвях и коде между группами разработчиков без необходимости занесения этих изменений в центральный репозиторий.

Эти архитектурные решения и их реализация являются ключевыми аспектами успеха Git и удобства его использования. Конечно же, Git также удовлетворяет стандартным требованиям к VCS по неизменяемости и подотчетности. Неизменяемость означает, что изменения, будучи добавлены в репозиторий, становятся неотъемлемой частью истории проекта. Хотя изменения впоследствии могут быть удалены (так называемый reverting – отмена изменений), тем не менее, и изменения, и удаление этих изменений являются неотъемлемой частью истории проекта. Подотчетность означает, что можно легко отследить, кто и когда внес определенные изменения. Для чего было сделано изменение, может оставаться загадкой (хотя при внесении изменений необходимо заполнять комментарий), но, по крайней мере, всегда можно узнать, кого об этом следует спросить.

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

Пакеты Git доступы в репозиториях большинства дистрибутивов Linux. В Ubuntu, Debian и других системах, использующих формат пакетов .deb, нужно установить пакет git-core В системах, работающих с RPM-пакетами, таких как Fedora, Red Hat, Centos, SUSE и Mandriva, основной пакет Git называется просто git. Базовый пакет Git также требует, чтобы в системе были установлены Perl, библиотеки Perl для шифрования и обработки исключений, а также утилита patch.

При желании получить самую последнюю версию Git для Linux, можно заглянуть на Web-сайт Git, на котором доступны пакеты .deb и RPM, а также последний исходный код Git (если вы хотите собрать свою собственную версию). На сайте Git также доступны скомпилированные версии Git для Mac® OS X, Windows®, Cygwin под Windows и Solaris® от Sun/Oracle. В настоящее время администраторам операционных систем IBM® AIX® и Hewlett-Packard® HP-UX приходится самостоятельно собирать Git для своей платформы из исходного кода. За информацией о получении и сборке Git обращайтесь к разделу Ресурсы.

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

• git-cola. Графический интерфейс (GUI) для работы с файлами и директориями в репозитории Git.
• git-doc. Устанавливает локальную копию справочника пользователя, руководства и документации.
• git-gui. Графический интерфейс для работы с репозиториями Git и навигации по ним; использует пакет gitk.
• git-web. Основанный на Web графический интерфейс работы с репозиториями Git.
• gitk. Простой графический интерфейс для работы с репозиториями Git и навигации по ним.
• qgit. Основанное на Qt графическое приложение для просмотра и исследования репозиториев Git.

Пакеты git-gui, git-web, gitk и qgit предоставляют схожую функциональность, хотя git-web основан на Web, в то время как остальные запускаются локально. Любой из этих пакетов может быть полезен при начале работы с Git, хотя возможно пакет git-web является наилучшим выбором в распределенной среде разработки.

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

• git-cvs. Этот пакет обеспечивает взаимодействие репозиториев Git и CVS, позволяя импортировать CVS-репозитории и историю изменений в Git, вести работу в Git, вносить изменения обратно в CVS-репозиторий, а также импортировать обновления из CVS-репозитория.
• git-svn. Этот пакет обеспечивает взаимодействие репозиториев Git и Subversion, позволяя импортировать Subversion-репозитории и историю изменений в Git, вести работу в Git, вносить изменения обратно в Subversion-репозиторий, а также импортировать обновления из Subversion-репозитория.

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

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

Посмотреть список основных команд Git можно выполнив команду git без аргументов. Вот часть команд, которые будут показаны в этом списке:

• add . Добавляет к индексу Git новый файл. Для фактического добавления этого файла в репозиторий Git в дальнейшем нужно выполнить его фиксацию (commit).
• branch . Позволяет вывести список ветвей, копии которых у вас есть, определить, в какой ветви вы сейчас работаете, создать новые ветви или удалить локальную копию ветвей, которые вы создали или извлекли из репозитория. Эта команда не может переключить вас в другую ветвь. Для переключения надо использовать команду checkout.
• checkout . Эту команду можно выполнить для ветви или файла/директории. Если ее выполнить для какой-либо ветви, эта ветвь становится вашей рабочей ветвью. Если ее выполнить для какого-либо файла или директории, то этот файл или директория будут обновлены до текущей версии, находящейся в репозитории в вашей рабочей ветви. Также с помощью этой команды можно создать новую ветвь, которая будет основана на указанной существующей ветви, и, возможно, будет отслеживать изменения относительно нее.
• commit . Записывает (фиксирует) изменения файлов и директорий в индекс Git. Можно указать файлы и директории, изменения в которых мы хотим зафиксировать, с помощью параметра -a добавить все имеющиеся изменения в файлы, отслеживаемые Git, или с помощью параметра --interactive выбрать изменения в файлах и директориях, которые мы хотим зафиксировать за один раз. (Последний вариант может быть особенно полезен, если вы работаете над несколькими задачами, включающими большое количество файлов, но хотите зафиксировать некоторые изменения совместно. Фиксации производятся в локальный репозиторий, если же вы используете удаленный центральный репозиторий, то для того, чтобы опубликовать на нем свои локальные изменения, нужно использовать команду push .)
• diff . Отображает различия между локальным файлом и его версией, зафиксированной в репозитории или между двумя различными версиями файла, зафиксированными в репозитории. Эта команда чаще всего используется просто с указанием имени файла, чтобы отобразить различия между указанным файлом и его версией, находящейся в репозитории в текущей ветви.
• fetch . Извлекает обновления индекса из другого репозитория, после чего идентифицирует вновь созданные метки и оповещает о том, какие изменения в файлах и директориях, имеющиеся в репозитории, отсутствуют в локальной копии. Далее можно просмотреть доступные изменения с помощью команды git log. Для фактического извлечения файлов из репозитория следует использовать команду git pull или git rebase.
• grep . Ищет в файлах текущей ветви соответствия указанному шаблону и отображает их. Эта команда поддерживает большинство параметров обычной команды grep от GNU.
• log . Показывает журнал фиксаций для текущей ветви или для определенных файлов текущей ветви.
• merge . Выполняет перенос (слияние) изменений, сделанных в одной ветви, в другую ветвь. Эта команда предоставляет параметр, позволяющий либо автоматически занести изменения, либо перед принятием изменений просмотреть, как будет выглядеть обновленная версия.
• mv . Переименовывает файл, директорию или символическую ссылку, отслеживаемую Git.
• pull . Извлекает обновления индекса из другого репозитория и вносит соответствующие изменения в файлы и директории текущей ветви.
• push . Обновляет индекс удаленного репозитория в соответствии с локальным индексом и информацией об изменении объектов.
• rebase . Обновляет рабочую ветвь в соответствии с удаленной ветвью и изменяет все не опубликованные в удаленной ветви локальные фиксации таким образом, чтобы они могли быть применены к текущему состоянию удаленной ветви. Это мощная, но потенциально опасная команда, потому что она при необходимости буквально перезаписывает фиксации, так чтобы можно было выполнить слияние. В зависимости от частоты и размера изменений, производимых на удаленном репозитории, зачастую использование обычной команды git pull является предпочтительным.
• rm . Удаляет файл, директорию или символическую ссылку, отслеживаемую Git.
• stash . Временно переносит все текущие изменения в стек и возвращает текущую рабочую ветвь в изначальное состояние. Команда git stash save сохраняет текущие изменения в локальный стек, а git stash apply извлекает их и повторно выполняет. Это может быть полезным, когда вы хотите извлечь изменения из удаленного хранилища или выполнить rebase, не фиксируя при этом находящиеся в работе изменения.
• status . Показывает статус текущей ветви, идентифицируя не занесенные в репозиторий изменения, не отслеживаемые файлы и т.д.

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

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

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

1. Перейдите в директорию, содержащую исходный код проекта: