Не помню, писал уже про создание псевдонимов (alias) в Git, или нет. Но материальчик мне сильно понравился - делюсь с ним.

Итак, в чем суть вопроса? Суть проста - любой компьютерщик с опытом прекрасно знает и всегда старается применять на своей практике сочетания клавиш (так называемые hotkeys) для убыстрения, упрошения процесса своей работы.

Сначала использование hotkeys кажется причудой не менее причудливых компьютерных гиков - это они просто хотят показать, что они крутые пацаны и не такие, как все; затем, когда выучены и применяются на практике пара-тройка hotkeys - ты кажешься себе невероятно крутым компьютерным “перцем”; когда ты знаешь пару-тройку десятков hotkeys - это уже просто нужно для быстрой работы; и последняя (финальная стадия, которая лечению не поддается) - ты уже просто не можешь жить без hotkeys!

И так во всем - в любой программе, в любой утилите.

Не исключение и Git. Если в день хотя бы около десятка раз набивать git status, git add, git commit, git checkout, 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 config --global alias.st status
$ git config --global alias.ci commit
$ git config --global alias.co checkout
$ git config --global alias.br branch
$ git config --global alias.unstage reset HEAD --
$ git config --global alias.last log -1 HEAD

Оно канешна, приведенный выше списочек не является истиной в последней инстанции - на что фантазии хватает, то и можно\нужно делать. Какой псевдоним кажется более удобным в работе (у кого руки какой кривизны) - тот и стряпать надо. И вопрос совсем не в том - какие псевдонимы должны быть.

Вопрос в том - что Git сам может создавать псевдонимы (alias).

На этом все.


Обзор плагинов и скриптов для работы в технике Pixel Perfect.

Для начала - что такое техника Pixel Perfect? Все просто и можно догадаться по названию - это техника верстки, при которой сверстанный HTML-шаблон в точности (пиксель-в-пиксель) совпадает с оригиналом, PSD-макетом.

Другими словами, если наложить “картинку” сверстанного HTML-шаблона на картинку оригинального PSD-макета, то обе картинки должны совпасть. Совместиться должны все элементы картинок - текст, изображения, графические элементы.

По современным требованиям к верстке Pixel Perfect уже чуть ли не стандарт де-факто. Так что изучить этот вопрос жизненно необходимо, если есть желание и стремление иметь много заказов и заказчиков.

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

Первоначально в программе Photoshop оригинальный PSD-макет сохраняется как изображение в формате .png. Затем в браузере открывается сверстанный по этому макету HTML-шаблон. При помощи плагина PNG-копия макета накладывается на сверстанную страницу. И становится видна разница в расположении элементов на HTML-странице и на PNG-копии.

В этом и заключается вся несложная процедура Pixel Perfect проверки сверстанной страницы. Там, где на странице элементы не совпадают с оригиналом, производится коррекция значений в файлах стилей.

Pixel Perfect под Firefox

Для браузера Firefox имеется плагин Pixel Perfect для одноименной проверки сверстанной страницы.

После установки плагина Pixel Perfect его значок появиться в панели инструментов браузера Firefox. Стоит сказать, что плагин Pixel Perfect поддерживает только последние версии браузера Firefox (к примеру, в версии v.31 этот плагин не будет работать).

Теперь нужно открыть в Photoshop оригинальный PSD-макет и сохранить его целиком как изображение в формате .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-макета):

Pixel Perfect Add Layer

Жмем на кнопку “Add Layer”, выбираем подготовленное PNG-изображение и получаем результат - наложение двух слоев (сверстанного и оригинального):

Pixel Perfect Compare Layers

Видим, как не совпадают текст и кнопка HTML-страницы c PNG-оригиналом. Поэтому открываем в Firebug (этот плагин активируется автоматически при запуске плагина Pixel Perfect) вкладку со стилями и начинаем правку\подгонку:

Pixel Perfect Correct CSS Styles

Обратите внимание на режим “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-страницам:

PerfectPixel Activate

Важно! Перед экспортом в PNG-изображение PSD-макет необходимо привести к оригинальному размеру! Для этого в Photoshop зарезервирована комбинация hotkeys: Ctrl+1 - под Windows\Linux, Cmd+1 - под Mac OS X.

После этого запускаем плагин PerfectPixel, добавляем в нем новый слой (PNG-копию оригинала) и проверяем:

PerfectPixel Work

Функционал и работа плагина PerfectPixel ничем не отличается от функционала и работы плагина Pixel Perfect.

Ниже приведен видео-ролик с официальной страницы плагина PerfectPixel для демонстрации работы в нем:

Рассмотрение плагина PerfectPixel можно на этом закончить.

X-Precise

Если в двух предыдущих случаях были рассмотрены бесплатные плагины под два популярных браузера Firefox и Chrome, то в данном случае речь пойдет о платном ($5 на момент написания статьи) скрипте X-Precise, написанном на JavaScript и использующем библиотеку jQuery.

Подключение X-Precise

Для того, чтобы получить наложение картинки-оригинала на сверстанную страницу нужно подключить скрипт X-Precise к этой странице. Для этого необходимо скачать архив X-Precise.

Затем нужно распаковать папку _xpreciseв корневую директорию проекта. И подключить скрипт xprecise.min.js к HTML-странице для запуска интерфейса скрипта X-Precise.

Обратите внимание, что скрипт для своей работы использует библиотеку jQuery (v1.3.2), поэтому подключение X-Precise должно выглядеть таким образом:

<script src="http://ajax.googleapis.com/ajax/libs/jquery/1.3.2/jquery.min.js" type="text/javascript"></script>
<script src="_xprecise/xprecise.min.js" type="text/javascript"></script>

Затем нужно создать копии PSD-оригиналов в формате JPG и сохранить под тем же именем, что и файл оригинала в директории /_xprecise/ скрипта X-Precise.

При сохранении в формате JPG рекомендуется выбирать режим оттенков серого, так как при таком варианте лучше видна разница между сверстанной копией и оригиналом (помните об опции “Invert” плагина Pixel Perfect?).

Скрипт X-Precise попытается автоматически загрузить JPG-изображение из директории /_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.

Для подключения к тестируемой странице необходимо прописать базовый набор строк:

<script type="text/javascript" src="jquery.js"></script>
<script type="text/javascript" src="jquery.pixlayout.js"></script>
<script type="text/javascript">
  $(function(){
    $.pixlayout("/path_to_picture/picture.ext");
  });
</script>

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

$(function(){
  $.pixlayout({
    src: "/img/layout.jpg",
    opacity: 0.8,
    top: 50,
    center: true,
    clip: true,
    show: true
  }, ".wrapper");
});

Краткая справка по использованию скрипта pixLayout

Краткая справка по использованию скрипта pixLayout приведена в двух абзацах ниже (также взята с официального сайта):

Перемещение

  • кнопки: ‘влево’, ‘вправо’, ‘вверх’, ‘вниз’
  • кнопки: W, A, S, D, когда картинка видима
  • кнопки панели навигации

Операции

  • Уничтожить (удалить весь html и css код pixLayout со страницы) - крестик в правом верхнем углу панели;
  • Закрепить панель - иконка в правом верхнем углу панели;
  • Краткая справка - знак вопроса в правом верхнем углу панели;
  • Свернуть параметры - стрелка “вверх”” внизу панели;
  • Показать\убрать картинку - центральная кнопка панели навигации или 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. Почему перевод статьи? Потому что на русском ничего не нашел (окромя книги официальной).

Слияние (merge) ветвей является весьма распространенной и обыденной операцией, выполняемой в системе Git. Однако, в некоторых случаях Git выполняет слияние ветвей в режиме fast-forward. Но что такое режим fast-forward и чем он отличается от обычного режима слияния ветвей.

Давайте разберем этот вопрос на конкретном примере. Допустим, при работе в репозитории мною была создана ветка speedup из текущей ветки master:

$ git checkout -b speedup

Поработав некоторое время в этой ветке, я создал несколько commit‘ов (три коммита, три белых кружка на рисунке):

Ветка speedup

После этого я решил, что работа в ветке speedup мною выполнена и я сделал push этой ветки на свой удаленный репозиторий.

Между тем, обратите внимание на тот важный факт, что в ветке master не было внесено никаких изменений с того самого момента, когда я сделал ответвление от нее - ветку speedup.

Когда менеджер проекта уведомится о том факте, что разрабатываемая мною ветка готова для интеграции в проект, то им будет выполнены стандартные шаги по публикации моей работы - команды git fetch и git merge. Так как в ветке master не было внесено изменений с того момента (серый кружок), как была создана ветка speedup, то при слиянии система Git применит метод fast-forward. В этом случае вся последовательность коммитов будет иметь линейный вид (левая часть рисунка):

Fast-Forward Git

Примечание переводчика: другими словами, Git просто произведет перемещение указателя HEAD с серого кружка (последний коммит ветки master) на последний белый кружок (последний коммит ветки speedup). И будет считать, что все это - ветка master. Получится своеобразный проброс указателя HEAD вдоль последовательной линии коммитов. Именно поэтому автор упоминает термин линейного вида.

Другим вариантом слияния веток в данном случае является использование флага -no-ff в команде git merge, что представляет из себя сокращение от - no fast-forward. В этом случае ситуация будет несколько иной - ее схематичное изображение на правой части рисунка вверху.

В этом случае при слиянии веток master и speedup системой Git создается коммит (кружок со штрихованной границей), задача которого - информировать о слиянии веток. Другими словами - цель и задача этого коммита только в информировании о слиянии веток master и speedup.

В ситуациях подобного рода система Git всегда старается применить режим fast-forward, если это возможно. Однако, такое поведение Git можно легко изменить на режим no fast-forward и сделать его поведением системы по умолчанию.

Пожалуй, самой главной неприятной неожиданностью при использовании merge в режиме no fast-forward - это когда вы нажимаете ту самую зеленую кнопку “Merge” в web-интерфейсе сервиса GitHub при выполнении pull request:

GitHub Pull Request

К сожалению, на сегодняшний день web-интерфейс GitHub выполняет операцию слияния (merge) так, как если бы для этой команды был установлен флаг -no-ff. Другими словами, даже если при слиянии веток ситуация позволяет использовать режим fast-forward, GitHub не будет его использовать.

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

ESLint

Внимательно посмотрите на приведенный выше рисунок. На нем хорошо видно, что некоторые слияния (merge) веток могут быть выполнены в режиме fast-forward. Но своеобразный подход GitHub к слиянию веток привел к тому, что линейная история коммитов была превращена в нечто похожее на рисунок железнодорожного пути.

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

Режим no fast-forward хранит всю информацию о слияниях веток. Такой подход может оказаться запутанным и сложным, если необходимо прочитать историю коммитов.

С другой стороны, режим fast-forward хранит не всю информацию о слияниях веток. Такой подход более простой для чтения, но в этом случае становится неочевидным история веток проекта.

На этом все.


Краткий обзор команды git diff

Итак, продолжаю знакомиться с системой Git и на этот раз вопрос будет касаться команды git diff. Это краткая заметка, которая ни в коей мере не претендует на полноценный обзор. Скорее всего - философское рассуждение на тему сравнения в Git.

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

Когда изменение обнаружено, тогда можно решать, что с ним делать - оставить, удалить или отредактировать.

Перед использованием команды diff стоит напомнить о трех состояниях системы Git: Working Area, Staging Area, Repository. Фактически, команда diff производит сравнение между разными состояниями одного файла.

Поэтому, когда запускается команда diff, следует принимать во внимание, что и с чем будет сравниваться.

Working Area

Рассмотрим первый случай, когда имеется отслеживаемый файл index.html, в который вносятся изменения.

Но изменения в этом файле не индексируются (git add) и не фиксируются (git commit).

В этом случае, чтобы увидеть изменения, нужно запустить команду:

$ git diff

В этом случае производится сравнение между фиксированной версией файла index.html (в области Repository) и его измененной версией (в области Working Area).

Вывод будет примерно таким:

$ git diff
diff --git a/index.html b/index.html
index 8fbea1c..fff54a9 100644
--- a/index.html
+++ b/index.html
@@ -5,6 +5,6 @@
   <title>Index</title>
 </head>
 <body>
-
+  <h1>Header 1</h1>
 </body>
 </html>

В этом примере все предельно ясно и понятно. Строка --- a/index.html - это фиксированная версия файла index.html. Строка +++ b/index.html - это измененная версия файла index.html.

Две строки:

-
+  <h1>Header 1</h1>

… отображают, сколько и каких строк удалено (знак минус); сколько и каких строк добавлено (знак плюс).

Итак, с первым вариантом разобрались. Комадна git diff выполняет сравнение версии файла из области Repository и этой же версии из области Working Area.

Staging Area

Второй вариант - файл index.html отслеживается, в него внесено изменение, которое проиндексировано (внесено в область Staging Area).

Команда git diff ничего не покажет, так как изменения в файле index.html были перенесены (git add) из области Working Area в область Staging Area. Другими словами, область Working Area чистая и в ней нет ничего, чтобы можно было сравнить с областью Repository.

В этом случае для команды git diff необходимо добавить ключ --staged. Тогда вывод будет примерно таким:

$ git diff --staged
diff --git a/index.html b/index.html
index 8fbea1c..fff54a9 100644
--- a/index.html
+++ b/index.html
@@ -5,6 +5,6 @@
   <title>Index</title>
 </head>
 <body>
-
+  <h1>Header 1</h1>
 </body>
 </html>

Ключ --staged указывает, что необходимо сравнивать область Repository с областью Staging Area.

Итак, разобрались со вторым случаем. Команда git diff --stagedпроизводит сравнение области Repository с областью Staging Area.

Repository

Третий вариант - файл index.html отслеживается, в него внесены изменения, которые проиндексированы (git add) и зафиксированы (git commit).

В этом случае область Working Area и Staging Area чистые от изменений, поэтому область Repository нельзя сравнивать с ними - там нет ничего для сравнения.

Поэтому команда git diff или git diff --staged ничего не покажет - сравнивать то не с чем!

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

В этом случае команда сравнения git diff будет выглядеть примерно таким образом:

$ git diff 0644c20  73a4c4c
diff --git a/index.html b/index.html
index fff54a9..8fbea1c 100644
--- a/index.html
+++ b/index.html
@@ -5,6 +5,6 @@
   <title>Index</title>
 </head>
 <body>
-  <h1>Header 1</h1>
+
 </body>
 </html>

Здесь 0644c20 - это первые семь символов hash-суммы последнего commit’а, 73a4c4c - первые семь символов hash-суммы предпоследнего commit’а.

Их можно получить командой:

$ git log --oneline

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

Итак, разобрались с третим вариантом - когда сравниваются командой git diff hash_sum_1 hash_sum_2 между собой различные коммиты, расположенные в области Repository.

На этом все.


Решил написать небольшой обзор по редактору Remarkable

Озадачился выбором markdown-редактора под Linux. После недолгих поисков с легким и приятным удивлением нашел две программы под эту операционную систему. Все течет, все меняется и вот теперь под Linux есть два достойных markdown-редактора.

Первый редактор - это Remarkable, второй редактор - это Haroopad. После недолгого сравнения обеих программ оставил в своей коллекции редактор Remarkable по нескольким причинам.

Обзор Remarkable

Чем мне понравился Remarkable? Это простая и интуитивно понятная программа, с таким же приятным и понятным интерфейсом. Что называется - установил и пользуйся.

Одна особенность этого редактора - на момент написания статьи существует только версия под Linux (преимущественно под Ubuntu).

После установки и запуска редактор будет иметь такой примерный вид:

Remarkable - markdown editor

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

Вставка, открытие и сохранение документа; иконки Undo и Redo; форматирование текста - Bold, Italic, Stroke; удобные кнопки для вставки на страницу изображения, ссылки или timestamp:

Remarkable - insert images and links

Окно редактора Remarkable разбито на две части - левая для редактирования, правая - для предпросмотра. Все как и должно быть в нормальном markdown-редакторе.

Предварительный просмотр можно отключить:

Remarkable - disable live preview

Есть также “ночной” режим работы:

Remarkable - night mode

Программа поддерживает синтаксис Github Flavoured Markdown:

Markdown Support

Markdown Support

На GitHub имеется подробный пример markdown-синтаксиса - Remarkable Demo, созданного в этом редакторе. Там есть что посмотреть и чему поучиться - своеобразная реклама редактора Remarkable.

Ниже приведен официальный демо-ролик, показывающий возможности редактора Remarkable:

Одна приятная и мощная особенность редактора - возможность экспортирования в HTML или PDF.

Remarkable автоматически подсчитывает число строк, слов и символов в тексте и отображает эту информацию в строке состояния.

Заключение

Мой субъективный вывод - программа Remarkable является отличным выбором markdown-редактора под Linux. Простая, удобная, интуитивно понятная.

В качестве редактора для ежедневной работы контент-менеджера - лучший выбор под операционной системой Linux. Все самое нужное - под рукой и ничего лишнего. Стоит ли упоминать, что данная статья написана в редакторе Remarkable.

На этом все.