August 31, 2014gearmobile Reading time ~1 minute

Как удалить репозиторий на GitHub

Как новичок в работе с системой GitHub, столкнулся с вопросом - как удалить созданный на GitHub репозиторий?

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

Итак, у меня есть учетная запись на GitHub, под которой создана пара репозиториев. Один из этих репозиториев был создан в учебных целях, поэтому для моей дальнейшей работы он мне не пригодиться и его можно удалить.

Список репозиториев на GitHub

Для начала открою свою страничку на GitHub и посмотрю, какие репозитории у меня уже есть:

Список репозиториев на GitHub

Один из репозиторев -

arbeit

- можно удалить.

Для этой цели нужно просто зайти в него по ссылке:

Репозиторий arbeit на GitHub

В правом нижнем углу окна браузера, в списке, имеется строка

Settings

. Открываем ее, сразу же копируем имя репозитория в поле

1
Repository name

(оно нам понадобиться еще здесь) и прокручиваем страницу вниз, пока не находим раздел с устрашающим названием

1
Danger Zone

. В этой опасной зоне находим подраздел

1
Delete this repository

с одноименной кнопкой

1
Delete this repository

Жмем на эту кнопку и получаем в результате окно с предупреждением об удаленни репозитория. В окне запроса имени удаляемого репозитория вводим (или вставляем из буфера обмена) -

arbeit

Запрос имени удаляемого репозитория

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

arbeit

удален:

Удаленный репозиторий на GitHub

Ничего сложного, но так сразу и не догадаешься, что нужно делать. Разработчики GitHub постарались и обезопасили пользователей от случайного удаления репозиториев с данными.

August 30, 2014gearmobile Reading time ~10 minutes

GitHub и Git - создание и работа с репозиторием

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

Вот такие получаются шаги, которые нужно осветить. Profit у всех этих сложностей, описанных мною выше, один - но большой! Заключается он в том, что проект, над которым вы работаете (даже в гордом одиночестве) находится на удаленном сервере, к которому можно подключиться из любого места и с любой машины. Так как он находиться на remote server, то с ним ничего не случиться, даже если ваша машина упадет\утонет\разобьется.

В статье большая часть времени будет посвящена автоматизации процесса авторизации на сервисе GitHub с помощью такой вещи, как ssh-ключи. Такие ключи предназначены как раз для возможности авторизации пользователя на каком-либо сервисе, без необходимости каждый раз вводить логин\пароль. Естественно, на стороне сервиса должна быть настроена такая возможность - на GitHub она настроена и даже является почти обязательным условием настройки аккаунта.

Все действия, описанные в этой статье, будут производиться под операционной системой Linux Mint 17 Cinnamon, в консоли. Поэтому пользователи Mac OS X найдут для себя почти все идентичным. Система Windows остается в стороне.

Создание SSH-ключей под Linux

Первоначально необходимо создать (если их еще нет) ssh-ключи, которые будем использоваться для авторизации на GitHub. В системе Linux такие ключи расположены в домашней директории пользователя и выглядят примерно так:

$ ls ~/.ssh
  id_rsa id_rsa.pub known_hosts

Один из этих ключей

id_rsa

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

1
id_rsa.pub

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

Если показанная выше команда “скажет” вам, что директории

.ssh

не существует, то это означает, что у вас с системе установлен пакет SSH, отвечающий за создание и обработку ssh-ключей.

Установка пакета SSH

Под Linux Mint его нужно установить командой:

$ sudo apt-get install ssh

Создание пары ssh-ключей

Теперь можно приступать к созданию пары ssh-ключей. Выполняется это командой:

$ ssh-keygen -t rsa -C "g***e@gmail.com"

Чтобы было немного понятно, что это я сделал в данной команде, немного расшифрую ее. Утилита

1	ssh-keygen

входит в комплект пакета

1
ssh

и предназначена для одной цели - создания ssh-ключей. Часть команды -

1
-t rsa

- указывает, что необходимо создать ssh-ключи типа

1
rsa

Обязательный параметр

1	"g***e@gmail.com"

- электронный адрес, к которому “привязывается” создаваемый ssh-ключ; данный email будет также использоваться мною для регистрации на GitHub.

Как только будет введена представленная выше команда, утилита

1	ssh-keygen

запросит имя файла и местоположение для создаваемых ssh-ключей. Можно ничего не вводить, а просто нажать Enter. В этом случае программулька создаст и положит их по пути по умолчанию (который показан ею в скобочках):

$ ssh-keygen -t rsa -C "g***e@gmail.com"
  Generating public/private rsa key pair.
  Enter file in which to save the key (/home/aaron/.ssh/id_rsa):

Утилита задаст еще один вопрос, который крайне не рекомендуется игнорировать:

$ ssh-keygen -t rsa -C "g***e@gmail.com"
  Generating public/private rsa key pair.
  Enter file in which to save the key (/home/aaron/.ssh/id_rsa):
  Enter passphrase (empty for no passphrase):

Здесь

1	passphrase

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

После успешного ввода

1	passphrase

ssh-ключи будут созданы:

$ ssh-keygen -t rsa -C "g***e@gmail.com"
  Generating public/private rsa key pair.
  Enter file in which to save the key (/home/aaron/.ssh/id_rsa):
  Enter passphrase (empty for no passphrase):
  Enter same passphrase again:
  Your identification has been saved in /home/aaron/.ssh/id_rsa.
  Your public key has been saved in /home/aaron/.ssh/id_rsa.pub.

В состав пакета

ssh

входит утилита

1
ssh-agent

, задача которой в управлении созданными ssh-ключами. Передадим ей в пользование только созданные мною ssh-ключи:

$ eval "$(ssh-agent -s)"
  Agent pid 17461
  $ ssh-add ~/.ssh/id_rsa
  Enter passphrase for /home/aaron/.ssh/id_rsa:
  Identity added: /home/aaron/.ssh/id_rsa (/home/aaron/.ssh/id_rsa)

Можно посмотреть, что утилита

shh-add

“подхватила” и распознала предоставленные ею ssh-ключи:

$ ssh-add -l
  2048 e4:4d:fe:73:cb:b9:bb:ee:26:32:6b:f5:f1:6a:db:38 /home/aaron/.ssh/id_rsa (RSA)

Под операционную систему Linux имеется консольная утилита

xclip

, которая умеет получать содержимое любого файла и отправлять это содержимое в буфер обмена, и все это в консоли. По умолчанию такой утилиты нет в системе (в том числе и у меня), поэтому первоначально установлю ее:

$ sudo apt-get install xclip

… а затем передам ей на вход содержимое публичного ключа

1	id_rsa.pub

, который буду применять на сервисе GitHub:

$ xclip -sel clip < ~/.ssh/id_rsa.pub

Если вам, уважаемый читатель, такой путь покажется слишком сложным, то можно открыть файл

1	id_rsa.pub

в любом редакторе кода и скопировать его содержимое в буфер обмена.

Добавление ssh-ключа на GitHub

Переходим на сервис GitHub и создаем на нем новую учетную запись. Описывать процесс создания такой записи на GitHub не буду, так как там все просто. Более интересный момент - это добавление ssh-ключа в профиль пользователя GitHub.

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

SSH key

и нажимаем ее:

SSH ключи на GitHub

Откроется окно для добавления новых ssh-ключей в учетную запись пользователя на GitHub. Здесь все элементарно просто - нажимаем кнопку

1	Add SSH key

. В поле

1
Title

вводим название (произвольное) для импортируемого ssh-ключа.

В поле

Key

просто нажимаем Ctrl+V - содержимое буфера обмена (которое я получил ранее с помощью утилиты

1
xclip

) вставиться в это поле:

Добавление ssh-ключа на GitHub

Жму на зеленую кнопку

Add key

внизу окна. Ключ добавлен на GitHub и появиться в списке SSH-ключей:

Добавленный на GitHub ssh-ключ

Проверка SSH-соединения с GitHub

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

Для этой цели ввожу команду:

$ ssh -T git@github.com
  The authenticity of host 'github.com (192.30.252.131)' can't be established.
  RSA key fingerprint is 16:27:ac:a5:76:28:2d:36:63:1b:56:4d:eb:df:a6:48.
  Are you sure you want to continue connecting (yes/no)? yes

На ошибку в строке

1	The authenticity of host 'github.com (192.30.252.131)' can't be established.

не стоит обращать внимание. В запросе командной строки печатаем

1
yes

и получаем:

Warning: Permanently added 'github.com,192.30.252.131' (RSA) to the list of known hosts.
Hi gearmobile! You've successfully authenticated, but GitHub does not provide shell access.

Отлично! GitHub “узнал” меня и поприветствовал в строке

1	Hi gearmobile! You've successfully authenticated, but GitHub does not provide shell access.

. Это говорит о том, что ssh-соединение моей машины с GitHub установлено успешно и GitHub авторизует меня.

Однако, при настройке ssh-соединения возможны и ошибки. В этом случае может помочь статья - Error: Permission denied (publickey).

Создание нового репозитория на GitHub

Создаем новый репозиторий на GitHub. Ввожу новое уникальное имя для репозитория, краткое его описание и включаю галочку “Initialize this repository with a README”:

Создание нового репозитория на GitHub

Отлично! На GitHub я только что создал новый репозиторий

arbeit

. Теперь можно скопировать (склонировать) его на свою локальную машину командами:

$ mkdir arbeit
$ git clone git@github.com:gearmobile/arbeit.git
  Cloning into 'arbeit'...
  Warning: Permanently added the RSA host key for IP address '192.30.252.130' to the list of known hosts.
  remote: Counting objects: 3, done.
  remote: Compressing objects: 100% (2/2), done.
  remote: Total 3 (delta 0), reused 0 (delta 0)
  Receiving objects: 100% (3/3), done.
  Checking connectivity... done

Переходим в локальную копию репозитория

arbeit

. Вношу изменения, а затем последовательно:

$ git add .
$ git commit -m 'Added changes'
$ git push

Команда

1	git commit -m 'Added changes'

фиксирует изменения в локальном репозитории. Команда

1
git push

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

Вот, таким образом я наладил Git-работу своей машины с GitHub.

August 28, 2014gearmobile Reading time ~4 minutes

gitignore - игнорирование файлов в Git

В системе Git можно настроить возможность автоматического игнорирования файлов.

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

1	.gitignore

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

К примеру, если развертывать в проекте Compass, то будет создан каталог

.sass

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

Давайте на практике разберемся, каким образом можно настроить игнорирование файлов в Git с помощью

1	.gitignore

Создание нового проекта

Создаю новый проект с именем

1	git_ignore

, в котором помещаю несколько файлов разного типа:

$ mkdir git_ignore
$ cd git_ignore/
$ touch index.html style.css

Инициализирую репозиторий Git в директории

1	.git_ignore

, индексирую созданные файлы и фиксирую их:

$ git init
Initialized empty Git repository in /home/aaron/Projects/git_ignore/.git/
$ git add .
$ git commit -m 'First Commit'

Вывод команды

1	git status

показывает, что все чисто:

$ git status
On branch master
nothing to commit, working directory clean

Настройка игнорирования в .gitignore

Для настройки игнорирования определенных типов файлов в системе Git необходимо первоначально создать файл

1	.gitignore

$ touch .gitignore

Откроем созданный файл

1	.gitignore

в любом редакторе:

$ nano -w .gitignore

… и пропишем в нем следующие строки:

*.txt
*.md

Тем самым мы говорим Git, что нужно игнорировать все файлы с расширением

.txt

1
.md

внутри директории

1
git_ignore

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

Проиндексируем и зафиксируем изменения (создание файла настроек

1	.gitignore

), а затем проверим данный факт. Для этого в рабочей директории

1
git_ignore

создаю еще несколько типов файлов:

$ touch main.css readme.txt humans.md

Затем выполняю индексацию всех файлов, которые были добавлены или изменены в рабочем каталоге:

$ git add .

И смотрю, что мне показывает команда

1	git status

$ git status
  On branch master
  Changes to be committed:
    (use "git reset HEAD <file>..." to unstage)

    new file:   main.css

Система Git увидела только новый файл

main.css

. Два других файла -

1
readme.txt

1
humans.md

- проигнорированы системой. Отлично! Зафиксирую изменения.

Можно создать еще пару файлов в разных директориях и посмотреть на вывод команды

1	git status

в консоли:

Результат настройки файла .gitignore

Усложнить задачу игнорирования в .gitignore

Можно усложнить задачу игнорирования в Git, добавив в файл

1	.gitignore

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

1
ignore

и скрытая директория

1
.ignore

(с точкой перед именем):

Добавлю в файл

1	.gitignore

пару строк таким образом:

$ cat .gitignore
*.txt
*.md
ignore/
.ignore/

Проиндексирую изменения, а затем выполню операции по созданию директорий и файлов внутри них:

$ mkdir ignore
$ mkdir .ignore
$ touch ignore/reset.css
$ touch .ignore/normilize.css

Вновь ввожу команду просмотра состояния репозитория Git:

$ git status
  On branch master
  nothing to commit, working directory clean

Все сработало - Git не захотел видеть директории

ignore

1
.ignore

, а также их содержимое. Отлично!

Шаблоны в файле .gitignore

Для файла

1	.gitignore

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

August 27, 2014gearmobile Reading time ~8 minutes

Gulp - плагин gulp-livereload

Сегодня рассмотрим еще один очень нужный и полезный плагин для web-разработчика. Это плагин
1
gulp-livereload
под Gulp, который должен иметь каждый веб-разработчик в своей копилке.

Суть плагина

1	gulp-livereload

в автоматизации обновления страниц в окне браузера. Это тоже самое, что и связка - плагин LiveReload под Sublime Text + плагин LiveReload под браузер. Но в данном случае получается связка - плагин

1
gulp-livereload

+ плагин LiveReload под браузер.

Сказать честно, предыдущий опыт настройки LiveReload, описанный в этой статье - “Установка LiveReload в Sublime Text 2” меня полностью не удовлетворял и я им не пользовался. Причина заключалась в том, что иногда эта связка работала, а иногда - почему-то нет. Нестальность работы плагина под Sublime Text (у меня) отбивала всякое желание иметь с ним дело.

А вот связка плагин

1	gulp-livereload

+ плагин LiveReload под браузер работает стабильно. Кроме того, если Node.js + Gulp уже настроен для текущего проекта, то не возникает никакой проблемы в установке дополнительного плагина

1
gulp-livereload

Установка плагина gulp-livereload

Плагин

1	gulp-livereload

проживает по указанному адресу - gulp-livereload. Установка в проект производиться командой:

$ npm install --save-dev gulp-livereload

В виде зависимостей проекта запись в файле

1	package.json

должна выглядеть (как минимум) так:

{
 "name": "test",
 "version": "0.0.1",
 "devDependencies": {
  "gulp": "~3.8.7",
  "gulp-livereload": "~2.1.1"
 }
}

Добавляем переменную

1	livereload

в файл

1
gulpfile.js

для инициализации плагина

1
gulp-livereload

и дальнейшей работы с ним:

var gulp = require('gulp'),
    livereload = require('gulp-livereload');

Установка плагина LiveReload под браузер

Следующим шагом будет установка расширения LiveReload под браузер. В моем случае это будет Mozilla Firefox, однако расширение LiveReload существует и под два других популярных браузера - Google Chrome и Safari.

Для установки расширения под Firefox не стоит искать его на странице расширений Mozilla - LiveReload 0.6.4. Там находится устаревшая версия плагина, которая наверняка не подойдет для вашего браузера.

Лучше посетим домашнюю страницу проекта LiveReload с описанием установки расширений под каждый из браузеров - How do I install and use the browser extensions. Скачиваем по указанной на странице ссылке расширение под нужный браузер (Firefox) и автоматически устанавливаем его.

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

Создание задачи под gulp-livereload

В принципе, плагин

1	gulp-livereload

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

1
gulp-livereload

подразумевает автоматическую установку сервера LiveReload.

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

Ошибка запуска сервера LiveReload

… то это говорит всего лишь о том, что перед этим не был запушен в консоли сам сервер LiveReload. Для этого я создам задачу

watch

, внутрь которой помещу вызов функции

1
livereload()

// Watch Task
 gulp.task('watch', function(){
  livereload.listen();
  gulp.watch('sass/*.scss', ['sass']).on('change', livereload.changed);
});

Все - мне больше ничего не нужно дописывать для задачи компилирования из Sass в CSS (эта задача приведена здесь в качестве примера использования плагина

1	gulp-livereload

// Sass Complie Task
 gulp.task('sass', function(){
 gulp.src('sass/*.scss')
  .pipe(sassSCSS())
  .pipe(gulp.dest('build/css'));
});

Полностью листинг файла

1	gulpfile.js

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

var gulp = require('gulp'),
    sassSCSS = require('gulp-sass'),
    minifyHTML = require('gulp-minify-html'),
    rename = require('gulp-rename'),
    livereload = require('gulp-livereload');

// Default Task
gulp.task('default', ['sass', 'watch']);

// Watch Task
 gulp.task('watch', function(){
  livereload.listen();
  gulp.watch('sass/*.scss', ['sass']).on('change', livereload.changed);
});

// Sass Complie Task
gulp.task('sass', function(){
 gulp.src('sass/*.scss')
  .pipe(sassSCSS())
  .pipe(gulp.dest('build/css'));
});

Все готово для тестирования работы плагина

1	gulp-livereload

Тестирование плагина gulp-livereload

Осталось выполнить две маленькие вещи. Первая - включаю плагин LiveReload в браузере. Вторая - запускаю Gulp для мониторинга изменений и работы плагина

1	gulp-livereload

$ gulp
Using gulpfile ~/Projects/gulp_test/gulpfile.js
Starting 'sass'...
Finished 'sass' after 11 ms
Starting 'watch'...
Finished 'watch' after 17 ms
Starting 'default'...
Finished 'default' after 19 μs
Live reload server listening on: 35729

Видим, как последняя строка в консоли говорит нам, что сервер LiveReload запустился и прослушивает порт по умолчанию - 35729. Вношу изменения в файл стилей

1	style.scss

figure{
  border: 1px solid #000;
  padding: 5px;
 }

… и смотрю на вывод в консоли:

$ gulp
Using gulpfile ~/Projects/gulp_test/gulpfile.js
Starting 'sass'...
Finished 'sass' after 10 ms
Starting 'watch'...
Finished 'watch' after 15 ms
Starting 'default'...
Finished 'default' after 11 μs
Live reload server listening on: 35729
style.scss was reloaded.
Starting 'sass'...
Finished 'sass' after 3.58 ms

Изменение было отслежено, файл перекомпилирован задачей

sass

. А что же плагин

1
gulp-livereload

- он тоже подхватил изменения?

Смотрим:

Изменения в gulp-livereload

О, да! Изменение было подхвачено плагином

1	gulp-livereload

- “картинка” в окне браузера изменилась без перезагрузки последнего.

Еще раз проверим и внесем какое-нибудь изменение в файле стилей:

$ gulp
Using gulpfile ~/Projects/gulp_test/gulpfile.js
Starting 'sass'...
Finished 'sass' after 10 ms
Starting 'watch'...
Finished 'watch' after 15 ms
Starting 'default'...
Finished 'default' after 11 μs
Live reload server listening on: 35729
style.scss was reloaded.
Starting 'sass'...
Finished 'sass' after 3.58 ms
style.scss was reloaded.
Starting 'sass'...
Finished 'sass' after 1.97 ms

Изменения в gulp-livereload

Отлично! Вот мы и изучили еще одну полезную сторону работы с Gulp - использование плагина

1	gulp-livereload

August 26, 2014gearmobile Reading time ~7 minutes

Gulp-imagemin - оптимизация изображений в Gulp

Крайне необходимая задача, возникающая в работе каждого верстальщика - это оптимизация графики, нарезанной из psd-макета или используемой в HTML-шаблоне.

Для этой цели существует много разных инструментов, начиная с RIOT и заканчивая утилитами Linux. Но гораздо более удобной возможностью является автоматизация процесса сжатия картинок с помощью плагина под Gulp.

Таким плагином является gulp-imagemin. Он умеет сжимать картинки форматов PNG, JPEG, GIF и SVG. Все остальные (не поддерживаемые) форматы графических файлов просто игнорируются плагином

1	gulp-imagemin

Установка gulp-imagemin

Установка плагина

1	gulp-imagemin

стандартная и производиться командой

1
npm install

с ключом

1
--save-dev

для внесения пакета в список зависимостей проекта:

$ sudo npm install --save-dev gulp-imagemin

Создание задачи под gulp-imagemin

После установки плагина

1	gulp-imagemin

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

1
imagemin

, в которую помещаем сам плагин

1
gulp-imagemin

var imagemin = require('gulp-imagemin');

А затем создаем задачу с произвольным именем

compress

// Compress Task

gulp.task('compress', function() {
  gulp.src('images/*')
  .pipe(imagemin())
  .pipe(gulp.dest('build/images'))
});

Задачу

compress

можно запускать однократно вручную или автоматически, доверив это дело Gulp и поместив ее внутрь встроенной функции

1
gulp.watch

Создаю в проекте

gulp_test

директорию

1
images

и размещаю в ней несколько изображений формата

1
.jpg

, но достаточно большого размера:

$ ls images/
black (22).jpg  black (23).jpg  black (28).jpg  black (31).jpg  black (36).jpg  black (41).jpg

Цель - проверить, действительно ли происходит сжатие графических файлов. Давайте опробуем работу плагина

1	gulp-imagemin

однократно, запустив в консоли команду

1
gulp compress

$ gulp compress
Using gulpfile ~/Projects/gulp_test/gulpfile.js
Starting 'compress'...
Finished 'compress' after 8.56 ms
gulp-imagemin: Minified 6 images (saved 83.02 kB - 7.2%)

Отлично! Задача

compress

запустилась и выполнилась за 8.56 миллисекунд. При этом было обработано 6 изображений, над которыми была произведена операция сжатия. Экономия размера в результате компресии составила

1
7.2%

Давайте посмотрим на изображения в оригинале, расположенные в директории

images

Оригинальные изображения в проекте

… запомним примерные размеры каждого из файлов. А затем взглянем на содержимое директории

1	build/images/

, в которой располагаются сжатые плагином

1
gulp-imagemin

изображения:

Обработанные плагином gulp-imagemin изображения

Видно при сравнении, что размер графических файлов, пускай и ненамного, но уменьшился.

Gulp-imagemin - автоматический мониторинг

Давайте доведем нашу задачу до логического завершения и настроим Gulp таким образом, чтобы он автоматически отслеживал добавление в директории

images

новых изображений.

И как только они появляются там, то немедлено производил бы их сжатие при помощи плагина

1	gulp-imagemin

Для этого создам задачу мониторинга

watch

// Watch Task

gulp.task('watch', function() {
  gulp.watch('images/*', ['compress']);
});

… которую добавлю в очередь на выполнение для дефолтной задачи

default

// Default Task

gulp.task('default', ['watch']);

Полностью листниг файла

1	gulpfile.js

для данного случая выглядит следующим образом:

var gulp = require('gulp'),
    imagemin = require('gulp-imagemin');

// Default Task
gulp.task('default', ['watch']);

// Watch Task
gulp.task('watch', function() {
  gulp.watch('images/*', ['compress']);
});

// Compress Task
gulp.task('compress', function() {
  gulp.src('images/*')
  .pipe(imagemin())
  .pipe(gulp.dest('build/images'));
});

Запускаю в консоли команду

gulp

, а затем по одному добавлю в директорию

1
images

два файла-скриншота, созданных мною для этой статьи.

Видим, что каждый раз, как в директорию

images

был добавлен файл, Gulp запускал задачу

1
compress

на выполнение:

$ gulp
  Using gulpfile ~/Projects/gulp_test/gulpfile.js
  Starting 'watch'...
  Finished 'watch' after 8.42 ms
  Starting 'default'...
  Finished 'default' after 12 μs
  Starting 'compress'...
  Finished 'compress' after 13 ms
  gulp-imagemin: Minified 7 images (saved 93.43 kB - 7.7%)
  Starting 'compress'...
  Finished 'compress' after 2.13 ms
  gulp-imagemin: Minified 8 images (saved 103.77 kB - 8%)

На выполнение первой задачи ушло 7 миллисекунд:

gulp-imagemin: Minified 7 images (saved 93.43 kB - 7.7%)

… на вторую задачу - 2.13 миллисекунд:

gulp-imagemin: Minified 8 images (saved 103.77 kB - 8%)

При этом я “выиграл”

7.7%

1
8%

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

Усложним задачу для gulp-imagemin

Можно немного усложнить и усовершенствовать процесс оптимизации изображений. Для этого немного перепишу задачу

compress

таким образом:

// Compress Task
  gulp.task('compress', function() {
    gulp.src('images/*')
    .pipe(imagemin({
      progressive: true
    }))
    .pipe(gulp.dest('images/'));
  });

Первое изменение - это добавлена опция

1	progressive: true

к плагину

1
gulp-imagemin

. Эта опция управляет методом сжатия графических файлов и приведена мною для наглядности примера.

Второе изменение - изменена директория назначения. Теперь директория-источник изображений

1	gulp.src('images/*')

и директория-“выхлоп”

1
gulp.dest('images/')

, куда помещаются обработанные изображения - одна и та же.

Таким образом, достаточно положить в директорию

images

какое-либо изображение и оно тут же преобразуется в точно такое же изображение, но меньшего размера! Удобно, не правда ли?

На этом все.

Zencoder

Frontend Developer Notebook

Как удалить репозиторий на GitHub

Список репозиториев на GitHub

GitHub и Git - создание и работа с репозиторием

Создание SSH-ключей под Linux

Установка пакета SSH

Создание пары ssh-ключей

Добавление ssh-ключа на GitHub

Проверка SSH-соединения с GitHub

Создание нового репозитория на GitHub

gitignore - игнорирование файлов в Git

Создание нового проекта

Настройка игнорирования в .gitignore

Усложнить задачу игнорирования в .gitignore

Шаблоны в файле .gitignore

Gulp - плагин gulp-livereload

Установка плагина gulp-livereload

Установка плагина LiveReload под браузер

Создание задачи под gulp-livereload

Тестирование плагина gulp-livereload

Gulp-imagemin - оптимизация изображений в Gulp

Установка gulp-imagemin

Создание задачи под gulp-imagemin

Gulp-imagemin - автоматический мониторинг

Усложним задачу для gulp-imagemin