Архив за месяц: Май 2013

DevConf 2013

До конференции осталось всего ничего, 14 и 15 июня в Москве в конгресс-центре гостиницы Измайлово Альфа. Конференция будет проходить в первый день, на второй же, как обычно, запланированы мастер-классы.

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

Обновление PHP в Mac OS X

Сегодня мне рассказали про очень простой способ обновить PHP на локальной Mac OS X.

Шаг 1. Сначала необходимо установить Xcode, если вы этого до сих пор не сделали. Запускаем его, идем в меню XcodePreferences… и выбираем тут закладку Downloads. Жмем «Install» напротив Command Line Tools. Шаг 1 завершен, в дальнейшем при очередном обновлении этого делать уже не потребуется.

Шаг 2. Снова, если не было это сделано ранее, устанавливаем Homebrew. Для этого достаточно выполнить команду:
ruby -e "$(curl -fsSL https://raw.github.com/mxcl/homebrew/go)"

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

Шаг 3. Переходим непосредственно к установке новой версии PHP. По адресу http://php-osx.liip.ch есть небольшой сайтик посвященный утилите для установки PHP. Смотрим раздел «One Line Installation» и копируем оттуда команду, соответствующую желаемой версии интерпретатора. Например, для PHP 5.4 это будет:
curl -s http://php-osx.liip.ch/install.sh | bash -s 5.4

Сегодня он установил мне PHP 5.4.15, который является самой последней версией в данной ветке.

Тут необходимо заметить, что эта утилитка не заменяет установленный в системе PHP, поэтому по умолчанию будет работать старая версия. Чтобы это исправить нужно отредактировать (или создать) файл .profile, который находится в вашей домашней директории (то есть ~/.profile). В этот файл нужно добавить строчку, которая изменит путь поиска бинариков:
export PATH=/usr/local/php5/bin:$PATH

После этого нужно перезапустить терминал (или перелогиниться в нем), чтобы изменения вступили в силу.

Меняем историю

На работе мы имеем дело c git и github. Чтобы не захламлять историю нашего основного репозитория на гитхабе, мы решили соединять коммиты перед пулл-реквестом.

То есть вместо истории:
9fc47c08e9d70cdd33768eff1dd0c4ea95c95a7f Создал класс для фичи
69e87e4eee9bc656184a8e32c619625db0b2f51f Написал класс этой фичи
4644b4d8111fd6a9fb38087bfa9f869215ff842e Правлю баг…
4881c35c6d58e0453e737a06ae19d264acddf423 Правлю другой баг…
86861e363530a4924217e4a497a74b168beb157d Форматирование!
9680a87d2a86bb205615afeb6a9780fc7a914ef5 Все, теперь можно!

Мы получаем нечто вроде:
38b34074eb416155167b10c6914c95ee4c26d2e6 Фича такая-то. Описание особенностей.

Понятно, что так история выглядит намного приличнее и понятнее. Собственно, добиться этого просто. Разумеется, работа ведется в отдельной ветке (а то и форке). Изменения вносятся, коммитятся и, наконец, пушатся. А в какой-то момент задача полностью готова и хочется склеить коммиты.

Сначала мы сбрасываем текущее состояние до последнего общего с мастером коммита:
git reset --soft 3a1829e5f8d49cdc404df070133e5a64ccacdac2

Мы делали «мягкий» сброс, поэтому все наши изменения остались в коде, теперь мы должны из закоммитить:
git commit -a -m 'Message'

И, наконец, запушить новый коммит. Если не сделать —force, то это закончится неудачей.
git push --forсe

У способа есть минус — на деле эти ревизии сохраняются и их можно увидеть, посмотрев лог с указанием комиитов:
git log ff122876f2f5ad46b4c930a5889571e8b6db6913…c66b0cf61e269809e2d655f10fa0a6f2294da405