Вот захотелось написать о ZSH и “Oh My ZSH” - в частности.
Что такое ZSH? Это командная оболочка для Unix-подобных систем, к которым относятся как Linux, так и Mac OS X. Стандартной командной оболочкой в Linux и Mac OS X является BASH, которая полностью удовлетворяет все потребности пользователя.
Но если хочется нечто особенное, не такое как у всех и BASH приелась, то можно попробовать ZSH. Эта оболочка может полностью заменить собой BASH и привнести с собой еще пару-тройку дополнительных возможностей. К слову сказать, под Linux имеются гораздо больше командных оболочек, нежели две BASH и ZSH. Но две последние самые популярные и используемые.
К оболочке ZSH имеется дополнительная надстройка Oh My ZSH, которая делает ее еще более красивой и функциональной. Каждый опытный пользователь Linux находит в ZSH что-то свое. Я нашел в ZSH (“Oh My ZSH”) красоту оформления с помощью большого выбора тем “Oh My ZSH Themes” и плагины “Oh My ZSH Plugins”, которые делают работу в командной строке еще более удобной.
Установка ZSH
Установка ZSH проста и не должна вызвать какие-либо затруднения. Практически все сводится к одной команде и зависит от консольного менеджера закачек, уже имеющегося в системе.
Первый случай подойдет для системы Mac OS X (в ней
1
curl
встроен по умолчанию):
$ curl -L https://raw.github.com/robbyrussell/oh-my-zsh/master/tools/install.sh | sh
Второй случай подойдет для системы Linux (в ней
1
wget
встроен по умолчанию):
$ sudo wget https://raw.github.com/robbyrussell/oh-my-zsh/master/tools/install.sh -O - | sh
После выполнения команды в системе Mac OS X достаточно закрыть и снова открыть терминал (рекомендуется к использованию “iTerm2”), чтобы ZSH вступил в действие и заменил собой BASH в качестве командной оболочки по умолчанию.
В системе Linux придется выполнить пару дополнительных действий. Первым шагом проверяем, что ZSH установилась нормально и работоспособная. Для этого запускаем ZSH вместо BASH:
$ zsh
Приглашение командной строки изменится со стандартного BASH на более причудливое и красивое приглашение ZSH. Отлично - все работает.
Производим смену командной оболочки по умолчанию с BASH на ZSH:
$ sudo chsh -s /bin/zsh
После следующей перезагрузки системы изменения автоматически вступят в силу. А пока они временные, но ничто не мешает ими пользоваться уже сейчас.
Настройка ZSH
Настройка ZSH сводится к редактированию файла
1
~/.zshrc
, в котором размещены все настройки этой оболочки. Строчек там достаточно много, но две самые интересные и важные из них опишу ниже.
Строка
1
ZSH_THEME="robbyrussell"
отвечает за тему оформления оболочки ZSH. По умолчанию используется тема под названием
1
robbyrussell
. Но ее можно заменить на любую другую из списка тем “Oh My ZSH Themes”, в котором представлены скриншоты, по которым легко выбрать любую тему. Все темы автоматически уже установлены в системе, поэтому достаточно указать нужную по ее имени.
Например, мне понравилась тема
1
pygmalion
:
ZSH_THEME="pygmalion"
Вторая важная строка
1
plugins=
конфигурационного файла
1
~/.zshrc
отвечает за подключение плагинов. Строка первоначально имеет вид:
plugins=(git)
Это означает, что при запуске оболочки ZSH будет автоматически подгружен плагин
1
git
. Плагины, как и темы, автоматическм устанавливаются в систему, поэтому достаточно указать только имя нужного плагина.
Важное замечание - перед использованием каждого конкретного плагина необходимо прочитать его README, чтобы знать, как его использовать. К примеру, плагин
1
sublime
служит для создания и использования псевдонимов (alias) при запуске редактора Sublime Text из командной строки. Плагин
1
bundler
служит для создания и использования псевдонимов (alias) при запуске утилиты
1
bundle
.
Пример строки с плагинами может быть таким (в моем случае):
plugins=(git sublime bundler)
Именно так - разделителями служат символы пробела между именами плагинов.
Ниже представлены два видео об установке и настройке “Oh My Zsh” под операционной системой Mac OS X. Видео на английском языке, но все понятно и так. Видео не мое - автор его Scott Tolinski, ведущий моего любимого канала Level Up Tuts.
Установка “Oh My Zsh”:
Настройка “Oh My Zsh”:
Заключение
В принципе, рассказанного выше минимума уже достаточно для комфортной работы в ZSH. В заключение можно лишь привести снимок терминала, чтобы иметь представление о красоте ZSH (с прикрученным “Oh My Zsh”):
Весьма полезные две опции в системе Git - показать только те ветки, которые уже слиты с веткой
1
master
(к примеру); или же показать только те ветки, которые еще не были слиты с веткой
1
master
(к примеру).
Таким образом, можно быстро и четко определиться, какие ветки уже можно удалить, так как все наработки в них слиты в основную ветку и таким образом - сохранены.
А какие ветки удялять нельзя, так как наработки в них еще не слиты в основную ветку и еще не сохранены.
Система Git не допустит удаления таких веток при запуске команды:
$ git branch -d name_of_branch
Только использование специального флага
1
-D
разрешит удаление ветки, которая не слита с основной веткой:
$ git branch -D name_of_branch
Итак, ниже две команды - героя дня.
Опция –merged
$ git branch --merged
показать все ветки, слияние для которых было выполнено. Такие ветки можно смело удалять.
Опция –no-merged
$ git branch --no-merged
показать все ветки, слияние для которых еще не было выполнено.
Опция -v
Показать список всех доступных веток и при этом отобразить последний коммит для каждой из веток:
Не помню, писал уже про создание псевдонимов (alias) в Git, или нет. Но материальчик мне сильно понравился - делюсь с ним.
Итак, в чем суть вопроса? Суть проста - любой компьютерщик с опытом прекрасно знает и всегда старается применять на своей практике сочетания клавиш (так называемые hotkeys) для убыстрения, упрошения процесса своей работы.
Сначала использование hotkeys кажется причудой не менее причудливых компьютерных гиков - это они просто хотят показать, что они крутые пацаны и не такие, как все; затем, когда выучены и применяются на практике пара-тройка hotkeys - ты кажешься себе невероятно крутым компьютерным “перцем”; когда ты знаешь пару-тройку десятков hotkeys - это уже просто нужно для быстрой работы; и последняя (финальная стадия, которая лечению не поддается) - ты уже просто не можешь жить без hotkeys!
И так во всем - в любой программе, в любой утилите.
Не исключение и Git. Если в день хотя бы около десятка раз набивать
1
git status
,
1
git add
,
1
git commit
,
1
git checkout
,
1
git branch
и так далее (список можно еще продолжать и продолжать), то через пару-тройку деньков в голову как-то сама собой вкрадывается мысль - а как бы сделать так, чтобы не набивать пальцами тупо одно и тоже изо дня в день? Как бы сделать это все покороче?
Ситуация выглядела бы крайне нелепой и смешной, если бы создатель системы Git (одновременно - один из создателей Linux) не предусмотрел возможности использования hotkeys в этой системе.
И она есть! Но вопрос данной статейки заключает даже не в том сногшибательном факте, что Git поддерживает работу “горячих клавиш”.
Вопрос в том - как их создавать самому и каким образом это делать.
До недавнего времени я лично знал один такой способ - это редактирование конфигурационного файла Git на предмет создания в нем своего собственного списка alias’ов.
Вот только одна тонкость - вы, уважаемый читатель, помните, какой файл под системой Windows необходимо редактировать для этой цели? А под системой Linux? А под Mac OS X?
Что-то я сильно сомневаюсь, что у вас “от зубов” отскочит ответ применительно ко всем трем системам. Я лично могу прямо сейчас припомнить ответ применительно только в системе Linux. Заминочка, однако!
А ларчик открывался просто! В системе Git есть встроенная возможность создания псевдонимов (alias).
И выглядит такая команда до смешного простой - к примеру:
$ git config --global alias.st status
В результате достаточно ввести в окне терминала:
$ git st
… чтобы получить информацию о текущем состоянии репозитория. И при этом не нужно “ломать” голову в попытках вспомнить, в каком файле (и где он вообще находится) нужно вписывать желаемый hotkey. Система Git сама это сделает - нужно только указать, alias какого вида вы желаете.
Ниже привожу краткий список псевдонимов (alias) из книги “Pro Git” второго издания (впрочем, все описанное здесь почерпнуто оттуда - просто материальчик очень понравился):
Оно канешна, приведенный выше списочек не является истиной в последней инстанции - на что фантазии хватает, то и можно\нужно делать. Какой псевдоним кажется более удобным в работе (у кого руки какой кривизны) - тот и стряпать надо. И вопрос совсем не в том - какие псевдонимы должны быть.
Вопрос в том - что Git сам может создавать псевдонимы (alias).
Обзор плагинов и скриптов для работы в технике Pixel Perfect.
Для начала - что такое техника Pixel Perfect? Все просто и можно догадаться по названию - это техника верстки, при которой сверстанный HTML-шаблон в точности (пиксель-в-пиксель) совпадает с оригиналом, PSD-макетом.
Другими словами, если наложить “картинку” сверстанного HTML-шаблона на картинку оригинального PSD-макета, то обе картинки должны совпасть. Совместиться должны все элементы картинок - текст, изображения, графические элементы.
По современным требованиям к верстке Pixel Perfect уже чуть ли не стандарт де-факто. Так что изучить этот вопрос жизненно необходимо, если есть желание и стремление иметь много заказов и заказчиков.
На момент написания статьи реализация техники Pixel Perfect осуществляется при помощи соответствующих плагинов под браузеры или же с помощью специализированных скриптов. Ниже будут кратко рассмотрены два плагина и два скрипта, однако во всех случаях шаги для проверки Pixel Perfect одинаковы.
Первоначально в программе Photoshop оригинальный PSD-макет сохраняется как изображение в формате
1
.png
. Затем в браузере открывается сверстанный по этому макету HTML-шаблон. При помощи плагина PNG-копия макета накладывается на сверстанную страницу. И становится видна разница в расположении элементов на HTML-странице и на PNG-копии.
В этом и заключается вся несложная процедура Pixel Perfect проверки сверстанной страницы. Там, где на странице элементы не совпадают с оригиналом, производится коррекция значений в файлах стилей.
Pixel Perfect под Firefox
Для браузера Firefox имеется плагин Pixel Perfect для одноименной проверки сверстанной страницы.
После установки плагина Pixel Perfect его значок появиться в панели инструментов браузера Firefox. Стоит сказать, что плагин Pixel Perfect поддерживает только последние версии браузера Firefox (к примеру, в версии v.31 этот плагин не будет работать).
Теперь нужно открыть в Photoshop оригинальный PSD-макет и сохранить его целиком как изображение в формате
1
.png
через “Save for Web…”.
Важно! Перед экспортом в PNG-изображение PSD-макет необходимо привести к оригинальному размеру! Для этого в Photoshop зарезервирована комбинация hotkeys: Ctrl+1 - под Windows\Linux, Cmd+1 - под Mac OS X.
Как только PNG-копия PSD-макета подготовлена и сохранена, открываем в окне браузера Firefox сверстанную по этому макету HTML-страницу.
Запускаем плагин Pixel Perfect щелчком мыши по его иконке в панели инструментов браузера. Сразу же появится окно плагина, в котором он предложит нам выбрать заранее подготовленное PNG-изображение (копию PSD-макета):
Жмем на кнопку “Add Layer”, выбираем подготовленное PNG-изображение и получаем результат - наложение двух слоев (сверстанного и оригинального):
Видим, как не совпадают текст и кнопка HTML-страницы c PNG-оригиналом. Поэтому открываем в Firebug (этот плагин активируется автоматически при запуске плагина Pixel Perfect) вкладку со стилями и начинаем правку\подгонку:
Обратите внимание на режим “Invert” плагина Pixel Perfect - с помощью него можно очень точно корректировать элементы HTML-страницы.
В описанном выше процессе и заключается работа с плагином Pixel Perfect, а также Pixel Perfect верстка как таковая. Все предельно просто.
Ниже приведен видео-ролик, в котором показан процесс работы с плагином Pixel Perfect (видео не мое, поэтому за качество во всех смыслах ответственности не несу) - для наглядности работы пойдет:
Рассмотрение плагина Pixel Perfect под браузер Firefox закончено.
PerfectPixel под Google Chrome
Плагин PerfectPixel под браузер Chrome очень похож по назначению и функционалу (и названию!) на плагин Pixel Perfect под браузер Firefox.
После установки PerfectPixel необходимо зайти в настройки расширений браузера Chrome - chrome://extensions/ и активировать для плагина галочку “Allow access to file URLs”, тем самым разрешив плагину доступ к локальным HTML-страницам:
Важно! Перед экспортом в PNG-изображение PSD-макет необходимо привести к оригинальному размеру! Для этого в Photoshop зарезервирована комбинация hotkeys: Ctrl+1 - под Windows\Linux, Cmd+1 - под Mac OS X.
После этого запускаем плагин PerfectPixel, добавляем в нем новый слой (PNG-копию оригинала) и проверяем:
Функционал и работа плагина PerfectPixel ничем не отличается от функционала и работы плагина Pixel Perfect.
Ниже приведен видео-ролик с официальной страницы плагина PerfectPixel для демонстрации работы в нем:
Рассмотрение плагина PerfectPixel можно на этом закончить.
X-Precise
Если в двух предыдущих случаях были рассмотрены бесплатные плагины под два популярных браузера Firefox и Chrome, то в данном случае речь пойдет о платном ($5 на момент написания статьи) скрипте X-Precise, написанном на JavaScript и использующем библиотеку jQuery.
Подключение X-Precise
Для того, чтобы получить наложение картинки-оригинала на сверстанную страницу нужно подключить скрипт X-Precise к этой странице. Для этого необходимо скачать архив X-Precise.
Затем нужно распаковать папку
1
_xprecise
в корневую директорию проекта. И подключить скрипт
1
xprecise.min.js
к HTML-странице для запуска интерсейса скрипта X-Precise.
Обратите внимание, что скрипт для своей работы использует библиотеку jQuery (v1.3.2), поэтому подключение X-Precise должно выглядеть таким образом:
Затем нужно создать копии PSD-оригиналов в формате JPG и сохранить под тем же именем, что и файл оригинала в директории
1
/_xprecise/
скрипта X-Precise.
При сохранении в формате JPG рекомендуется выбирать режим оттенков серого, так как при таком варианте лучше видна разница между сверстанной копией и оригиналом (помните об опции “Invert” плагина Pixel Perfect?).
Скрипт X-Precise попытается автоматически загрузить JPG-изображение из директории
1
/_xprecise/
по имени файла этого изображения, считая, что имя файла иображения идентично имени файла открытой HTML-страницы (index.html -> index.jpg).
Но это не означает, что нельзя загрузить файл изображения с другим именем. Для этого достаточно задать другой путь к файлу в интерфейсе скрипта X-Precise.
Использование X-Precise
Основным достоинством скрипта X-Precise является его способность автоматически запоминать и хранить все настройки.
В целом, интерфейс скрипта X-Precise и его применение ничем не отличается от плагинов Pixel Perfect или PerfectPixel. Для желающих - можно ознакомиться со скриншотами по ссылке на главной странице проекта.
pixLayout
pixLayout - еще один плагин (наподобие X-Precise) под библиотеку jQuery, предназначенный для попиксельной верстки. Однако, в отличие от предыдущего скрипта, pixLayout бесплатный (интересная особенность - скрипт создан отечественным разработчиком).
Для своей работы скрипт pixLayout может использовать изображение в двух популярных форматах - JPG или PNG.
Домашняя страничка проекта расположена здесь - pixLayout. Скрипт прекрасно документирован как на родном (русском), так и на языке Уильяма Шекспира. Полюбоваться и поиграться можно на демо-страничке скрипта - pixLayout Test.
Для подключения к тестируемой странице необходимо прописать базовый набор строк:
Показать\убрать картинку - центральная кнопка панели навигации или Shift + E.
Ниже приведено официальное видео, демонстрирующее работу со скриптом pixLayout:
Заключение
В этом небольшом обзоре мы познакомились с четырьмя инструментами для попиксельной (pixel perfect) верстки. Два из них - это бесплатные плагины под браузеры. Другие два - скрипты на JavaScript для подключения к HTML-странице.
Что выбирать для своей работы - решать каждому.
В пользу плагинов под браузеры можно сказать, что они бесплатные, их легко установить и просто использовать.
В минус скрипту X-Precise можно сказать, что он платный ($5), требует подключения к проверяемой HTML-странице и зависит от библиотеки jQuery. В минус pixLayout также можно сказать, что для своей работы он требует дополнительной “возни” с подключением к HTML-странице.
Однако в плюс обоим скриптам можно привести тот неоспоримый факт, что это кроссбраузерное решение, абсолютно не зависящее от какого-либо браузера (Firefox, Chrome, Opera, Safari) или версии конкретного браузера. Скрипты будут работать одинаково во всех случаях.
Перевод статьи, посвященной вопросу - что такое fast-forward в системе Git
Оригинал данного вольного перевода размещен здесь - Fast-Forward Git Merge. Статья довольно свежая - от 20.09.2013. Почему перевод статьи? Потому что на русском ничего не нашел (окромя книги официальной).
Слияние (
1
merge
) ветвей является весьма распространенной и обыденной операцией, выполняемой в системе Git. Однако, в некоторых случаях Git выполняет слияние ветвей в режиме fast-forward. Но что такое режим fast-forward и чем он отличается от обычного режима слияния ветвей.
Давайте разберем этот вопрос на конкретном примере. Допустим, при работе в репозитории мною была создана ветка
1
speedup
из текущей ветки
1
master
:
$ git checkout -b speedup
Поработав некоторое время в этой ветке, я создал несколько
1
commit
‘ов (три коммита, три белых кружка на рисунке):
После этого я решил, что работа в ветке
1
speedup
мною выполнена и я сделал
1
push
этой ветки на свой удаленный репозиторий.
Между тем, обратите внимание на тот важный факт, что в ветке
1
master
не было внесено никаких изменений с того самого момента, когда я сделал ответвление от нее - ветку
1
speedup
.
Когда менеджер проекта уведомится о том факте, что разрабатываемая мною ветка готова для интеграции в проект, то им будет выполнены стандартные шаги по публикации моей работы - команды
1
git fetch
и
1
git merge
. Так как в ветке
1
master
не было внесено изменений с того момента (серый кружок), как была создана ветка
1
speedup
, то при слиянии система Git применит метод fast-forward. В этом случае вся последовательность коммитов будет иметь линейный вид (левая часть рисунка):
Примечание переводчика: другими словами, Git просто произведет перемещение указателя HEAD с серого кружка (последний коммит ветки
1
master
) на последний белый кружок (последний коммит ветки
1
speedup
). И будет считать, что все это - ветка
1
master
. Получится своеобразный проброс указателя HEAD вдоль последовательной линии коммитов. Именно поэтому автор упоминает термин линейного вида.
Другим вариантом слияния веток в данном случае является использование флага
1
-no-ff
в команде
1
git merge
, что представляет из себя сокращение от - no fast-forward. В этом случае ситуация будет несколько иной - ее схематичное изображение на правой части рисунка вверху.
В этом случае при слиянии веток
1
master
и
1
speedup
системой Git создается коммит (кружок со штрихованной границей), задача которого - информировать о слиянии веток. Другими словами - цель и задача этого коммита только в информировании о слиянии веток
1
master
и
1
speedup
.
В ситуациях подобного рода система Git всегда старается применить режим fast-forward, если это возможно. Однако, такое поведение Git можно легко изменить на режим no fast-forward и сделать его поведением системы по умолчанию.
Пожалуй, самой главной неприятной неожиданностью при использовании
1
merge
в режиме no fast-forward - это когда вы нажимаете ту самую зеленую кнопку “Merge” в web-интерфейсе сервиса GitHub при выполнении pull request:
К сожалению, на сегодняшний день web-интерфейс GitHub выполняет операцию слияния (
1
merge
) так, как если бы для этой команды был установлен флаг
1
-no-ff
. Другими словами, даже если при слиянии веток ситуация позволяет использовать режим fast-forward, GitHub не будет его использовать.
Одним из разумных объяснений такого поведения GitHub является тот факт, что каждая операция
1
pull request
должна быть однозначно идентифицирована. К примеру, несколько последних коммитов проекта (в качестве примера мною был взят проект ESLint - ничего личного) могут выглядеть таким образом:
Внимательно посмотрите на приведенный выше рисунок. На нем хорошо видно, что некоторые слияния (
1
merge
) веток могут быть выполнены в режиме fast-forward. Но своеобразный подход GitHub к слиянию веток привел к тому, что линейная история коммитов была превращена в нечто похожее на рисунок железнодорожного пути.
Если в нескольких словвах подвести общий итог вышесказанного, то он окажется следующим.
Режим no fast-forward хранит всю информацию о слияниях веток. Такой подход может оказаться запутанным и сложным, если необходимо прочитать историю коммитов.
С другой стороны, режим fast-forward хранит не всю информацию о слияниях веток. Такой подход более простой для чтения, но в этом случае становится неочевидным история веток проекта.