Как часто вы задумываетесь над инструментами, с которыми работаете? Как часто думаете, что вам чего-то не хватает, или вас что-то не устраивает? Если не часто - то вы вероятно очень счастливый человек, так как я нахожусь в постоянном поиске идеалов для решения своих задач, которыми я мог бы пользоваться ежедневно, получать удовольствие и не задумываться над тем, что я работаю с ПО, а не выполняю свою работу.
Иногда случается, что для тех или иных задач я нахожу все таки идеал. И хотелось бы рассказать об очень любопытном проекте под названием Pry, который я ежедневно использую. Это интерактивная консоль для Ruby-разработчиков с огромными возможностями. С тех пор как меня с ним познакомили (спасибо за это Алексею Магусеву) я до сих пор нахожусь в вау-эффекте, причем в очень положительном. Ниже я проведу краткий экскурс по этому замечательному инструменту, и очень надеюсь, что вы разделите мое мнение относительно него.
Сейчас я сижу и думаю, как бы правильно охарактеризовать pry, потому что этот инструмент настолько многограннен, что я затрудняюсь это сделать.
Сами разработчики pry позиционируют свое детище, как альтернативную интерактивную консоль для разработчиков на Ruby, которая призвана заменить IRB. Поставленную цель они выполнили более чем на отлично. Но мое затруднение вызвано тем, что в pry настолько огромное количество самых разных возможностей, что я не могу относится к нему просто как к интерактивной консоли. Пройдем по порядку, что умеет pry из коробки, помимо того, чтобы быть просто консолью:
pry-doc
);Pry создавался под влиянием таких инструментов как IPython, Smalltalk, SLIME и в сравнении с IRB выглядит как zsh в сравнении с sh. Разница огромна, а возможности поражают. Честно признаюсь, я хоть и активно пользуюсь pry, но до сих пор не постиг и половины его возможностей, ибо их очень много.
Но тем не менее, хотелось бы не просто пиарить проект копируя примеры из официальной документации, но и рассказать о том, как я ими пользуюсь, так как красивая документация - это ничто по сравнению с опытом использования. Однако, я разделю свое повествования на структуру близкую к официальной документации, чтобы можно было сразу перейти к проекту и посмотреть более расширено то, что там действительно есть.
У вас часто были ситуации, когда вам приходилось писать какие-то функции или большие одноразовые куски кода? К примеру добавить запись в базу данных с большим количеством полей или что-то подобное? В код не вынести, но нужно что-то в консоли проверить.
Иногда у меня встречаются такие ситуации, и… Бывают моменты, когда очень легко опечататься. Это очень неприятно, так как приходится набирать тот же самый код с нуля, что тратит драгоценное время и тратит еще более драгоценные нервы, так как я не люблю много раз писать одно и тоже.
Видимо мои взгляды такие же, как у разработчиков pry, потому что они очень хорошо позаботились о том, чтобы максимально удобно и просто решить данную проблему. В pry очень удобные инструменты для управления пользовательским вводом.
К примеру набирая код, вдруг думаешь, что нет. Он не нужен. И просто вводом !
можно этот ввод очистить. Для наглядности, я все же возьму пример из официальной документации, так как особо вспоминать пример для этого у меня нет желания. Слишком я леним.
1 2 3 4 5 |
|
На этом месте, конечно многие скажут, что отменить ввод можно и в IRB, однако смысл этой команды более глубок, если более детально ознакомиться с функционалом pry, и тогда все встанет на свои места. Я имею ввиду работу с историей и проигрыванием кода.
Все что вы вводите в консоль pry записывается в историю, и это можно воспроизвести. Причем, когда я говорю воспроизвести, я не имею ввиду стандартную навигацию по истории подобно IRB, а именно полноценно воспроизвести определенные куски кода, которые вводились за время сессии. Например:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
|
На самом деле управление историей в pry гораздо более обширно по функционалу и выше я показал лишь очень маленький пример. Для более детального ознакомления прошу сюда.
Иногда удобно отключить вывод результата выполнения строки кода. Например, мы получили из базы двадцать записей, и итератором each проделали что-то. В общем, отключить вывод можно добавив в конце ;
:
1 2 |
|
Как я уже говорил, иногда бывают ситуации, когда мы опечатываемся в наборе кода, и его приходится набирать полностью с нуля (например код какого-то временно используемого метода). Но этого можно избежать, к примеру используя команду amend-line
.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
|
Эта команда позволяет заменить не одну строку, но даже их последовательность или вовсе удалить их, если передать !
вместо исправленной строки.
Если набрать кода нужно очень много, то безусловно лучше воспользоваться услугами редактора кода, нежели встроенные(пусть и чертовски продвинутые) средства pry для редактирования кода. И это черт побери возможно!
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
|
Возможности редактирования на самом деле еще больше, например можно открыть на редактирование файл с исходным кодом для редактирования к примеру конкретного метода. В общем, читаем здесь.
Ненадолго хочется вернуться к “проигрыванию” кода. Я выше показывал, как можно проигрывать код из истории пользовательского ввода. Но pry позволяет “проигрывать” отдельные файлы и методы, и даже отдельные строки методов прямо в поток ввода pry, будто этот код был введен вами. Эдакое подобие макроса получается.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 |
|
Это такой краткий экскурс по быстрой работе с кодом прямо в консоли pry.
Программа на Ruby, похожа на операционную систему. Она состоит их отдельных модулей, которые взаимодействуют между собой, имеют свое внутреннее окружение. Представьте теперь, что эта программа еще и выглядит как файловая система, где каждый объект одновременно выступает в роли и директории, которая содержит другие файлы, и в качестве каталога, и внутри каждого каталога есть свой контекст исполнения, свое окружение. И теперь представьте, что вы можете перемещаться по работающему приложению куда вам вздумается и делать там что угодно, оперировать и изучать живой(!) код прямо в runtime(!).
Наверное программисты на компилируемых языках просто обзавидуются, да и многие другие программисты тоже. Но нам повезло. У нас есть pry, и он делает нашу фантазию реальностью. Такие возможности интересны не только в контексте изучения работы программ изнутри, но и очень помогают при отладке кода, когда в живом работаюшем коде можно посмотреть чтоже происходит, и при каких условиях возникает ошибка и откуда у нее растут ноги.
Ну да бог с ним. Перейдем от кода, ой от слов, к делу и посмотрим как это выглядит.
Предположим, мы создали Rails приложение, запустили консоль c pry. Давайте попробуем исследовать наше приложение изнутри так сказать и посмотреть, что там есть.
Исполняемое приложение, тем более такое сложное как Rails, да еще на динамическом языке типа Ruby - подобно огромной сети пещер, где темно, страшно и ничего не видно. Ну прям как в ж*пе у афроамериканца. А нас посадили где то в центре этой пещеры, и мы как то должны научиться ориентироваться в ней.
Для начала, нам бы понадобился фонарик. Нам нужно оглядеться вокруг, и посмотреть что вокруг собственно есть. Для этого у нас есть команда ls
. Не удивляйтесь, так как я не спроста привел в начале этой части аналогию с файловой системой. Эта команда действительно позволяет практически тоже, что и ее аналог из Unix, за оговорками того, с чем мы работаем.
Эта команда позволит нам легко оглядеться, и увидеть что находится в непосредственной близости от нас, или до чего мы сможем дотянутся нашими загребущими рученками.
1 2 3 4 |
|
1 2 3 4 5 6 7 |
|
Как вы заметили, я использовал другое приспособление под названием cd
. Это такое чудо техники, под названием телепорт, которое помогает мне перемещаться по темному и мрачному лабиринту работающего кода.
Он позволяет перейти в контекст всего, куда можно дотянуться. Например, любая переменная доступная из текущей области видимости.
1 2 3 4 5 6 7 |
|
Путешествуя по дебрям приложения, мы оставляем за собой путеводную нить Ариадны, и следим за вложенностью контекстов, в которых работаем. А также, наш телепорт умеет перемещать нас используя эту самую нить, и мы можем прыгать через контексты.
1 2 3 4 5 6 7 8 9 10 11 12 |
|
И прошу не путать вложенные контексты, с областью видимости или наследованием. Это контекст в терминах pry, считайте, что-то вроде сессии. Я не вдавался глубоко в подробности, так что если найдется человек знающий, прошу просвятить меня в комментариях к статье.
Иногда встречаются ситуации, когда нам нужно переключиться между контекстами. К примеру, что-то быстро посмотреть, и вернуться обратно. Это тоже возможно. Здесь я не буду выдумывать свой пример, и возьму пример из официальной документации.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
|
Как видно из примера, switch-to
очень похожа на jump-to
. Однако есть два больших различия. Каждый из вас работал с командной строкой. Когда мы выполняем команду cd
в pry - мы создаем новый контекст (представьте будто это сессия bash, или рабочий стол). Переходя все глубже и глубже вы создаете контексты. Возвращаясь наверх, нижележащие контексты закрываются.
В случае с использованием switch-to
, все происходит немного не так. Когда вы вызываете эту команду, то это было бы равносильно тому, что вы работая в терминале, открыли еще один терминал, и полностью передали управление нужным контекстом этому терминалу. Так происходит и в pry. Он не закрывает нижележащий контекст, а создает новый объект Pry
, и отдает под его управление нужный контекст.
Помимо навигации, нам порой нужна и поисковая система. К примеру, мы хотим найти метод с названием serialized_attributes
.
1 2 3 4 5 6 7 8 9 10 |
|
В случае Rails приложения - эта операция будет дорогой, так как она будет шерстить все, что есть в приложении. А это очень много кода. Зачастую же, мы уже примерно знаем, где нужно найти нужный метод.
1 2 3 4 5 6 7 8 9 |
|
Можно также задать вопрос “Где используется искомый нами метод?”.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
|
Когда нам надоест лазать по нашей пещеры, мы можем уйти отсюда, или уйти прихватив с собой сувенир.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 |
|
Поздравляю, юный падаван. Вы прошли краткий курс выживания в условиях runtime-исполнения приложения написанного на языке программирования Ruby.
Приложение в runtime никогда не живет само по себе. А в процессе разработки, очень часто требуется иметь доступ к исходному коду, и даже выполнять какие-то команды. В таких случаях, приходится отрываться от текущей сессии, и к примеру открывать отдельный терминал, в котором производить нужные действия.
Но слава богам, разработчики pry умеют заимствовать чужие достижения и перенимать успешные и красивые решения. Не знаю, многие ли из тех, кто читает эти строки, поели в свое время из миски под названием Python, но у меня было счастливое время, когда я писал на этом замечательном языке (причем, все это говорю без сарказма, как многие могут подумать).
Не только Ruby плодотворен на разного рода креативные решения. Среди разработчиков Python есть тоже весьма одаренные люди. И одни из них написали в свое время прекрасную замену системному shell’у. В отличии от Ruby, Python есть в 99% дистрибутивов из коробки, если не во всех 100%. Это позволяет писать на нем софт, совершенно не беспокоясь, что пользователю Linux системы придется беспокоиться насчет установки интерпретатора языка. В общем, некоторые одаренные личности, скрестили стандартный Python REPL с командной строкой и назвали свое творение IPython. Между прочим, творение прижилось и ничем не уступает даже тому zsh, так как за плечами стоит мощный язык программирования и хороший синтаксис, чего не скажешь ни о каком скриптовом языке для shell.
Так вот, разработчики pry позаимствовали идеи IPython, и внедрили в свой продукт аналогию сего чуда. И получилось весьма и весьма недурственно на мой вкус.
Итак, посмотрим, что мы можем делать? Мы можем работать с pry, будто находимся в shell.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 |
|
Заманчиво, неправда ли. Насколько можно заметить, можно использовать интерполяцию Ruby строк прямо в вызовах команд. Неплохая замена shell’у получается, надо сказать. У pry есть также shell-mode
. По сути, в shell-mode
меняется строка приглашения.
Небольшим недостатком является то, что в pry не работает автодополнение к примеру для перехода по каталогам.
Еще у pry имеются две интересные команды cat
и cd-gem
.
Команда cat
умеет выводить различные данные, как и ее родственница из Unix, но ориентированна на работу с кодом и pry. К примеру, она поддерживает подстветку синтаксиса. Но если вам нужна именно настоящая cat
, то из pry ее можно вызвать как .cat
.
Вторая команда умеет вас быстро перебрасывать в каталог выбранного гема.
Это в принципе база, которой должно с головой хватить для работы с shell из pry, если пригляделся такой вариант.
Pry в первую очередь интерактивная консоль для разработчиков. Важным моментом здесь является быстрый доступ к исходному коду и документации, и желательно это делать не отрываясь от работы с консолью, без переключения контекста нашего внимания к примеру в браузер, или не дай бог в другой терминал с запущенной ri.
Я это понимаю, вы это понимаете, и главное это понимают разработчики pry.
Для просмотра исходного кода есть специальная команда show-source
, которая позволяет просмотреть исходный код метода, или класса. Она также поддерживает синтаксис ri. Также следует заметить, что если у вас уставовлен и загружен плагин ‘pry-doc’, то становится возможным также и просмотр исходного кода на C в случае, если у вас MRI.
Если вы разрабатываете расширения для pry, или вас интересует код команды, то можно воспользоваться командой show-command
.
Касательно документации, то есть команда show-doc
. Имеется доступ к ri
одноименной командой. А также можно посмотреть краткую статистику объекта с помощью stat
.
Pry можно использовать в качестве отладчика. Причем очень отменного и удобного. В любом месте вашего кода вы можете поставить брекпоинт в виде binding.pry
, и при выполнении этого кода, выполнение остановится и откроется сессия Pry с runtime-окружением в момент останова. При выходе из сессии, исполнение кода продолжится дальше с учетом внесенных изменений, если таковые были.
Также не стоит забывать про bundle open <gem-name>
. Это позволяет делать более глубокую отладку кода, позволяя делать точки останова и изучать состояние приложения внутри сторонних гемов, а не только внутри нашего приложения.
Это основные и главные для меня фичи, которые я использую регулярно. Если у меня падает код в приложении, и мне надо найти причину падения, если она не видна и не лежит на поверхности, то первым делом я делаю binging.pry
и воспроизвожу действие, которое приводит к падению, и изучаю то, что может вызвать ошибку. А учитывая, что я получаю не просто отладчик, а runtime окружение и мощнейшую консоль разработчика с возможность работы с кодом, документацией и многими другими плюшками - то мне не нужны другие инструменты отладки приложения, кроме логов, которые по большей части используются не для попытки узнать что происходит путем топорного puts
, а для анализа работы приложения и сохранения данных о работе приложения в production. То есть, логи у меня выполняют ровно ту роль, которую должны выполнять, не более и не менее. Для всего остального есть pry.
Среди всего прочего, многим может прийтись по душе набор доступных расширений, комбинации которых предоставляют и полноценную альтернативу настоящему отладчику, и возможности асинхронной среды (EventMachine), и возможность подсветки синтаксиса вводимого кода, и даже возможности удаленного подключения к отлаживаемому приложению, в том числе и по SSH.
Статья получилась громоздкой, и я не смог нормально избавиться от дублирования документации по Pry, но постарался сделать так, чтобы хотя бы заинтересовать в том, чтобы пользоваться этим инструментом.
Всю остальную информацию в достатке можно найти по ссылкам ниже:
]]>В частности, у меня возникла проблема развертывания Git-хостинга и Redmine-приложения, которые должны работать на одном сервере, и запускаться от разных пользователей для разграничения привилегий.
Описывать то, как поставить Redmine или Gitolite я не собираюсь. Эти задачи во многом более чем тривиальны, и могут быть проделаны даже при небольшом опыте.
Но как всегда не обошлось без подводных камней, об одном из которых хочу предупредить тех, кто еще не сталкивался с таким, но вполне есть вероятность столкнуться.
Имеется сервер с двумя пользователями:
git
- пользователь, от которого работает gitolite;rails-runner
- пользователь, от которого работают Rails-приложения, и в частности нужный нам Redmine.Мы настроили сервер, gitolite отлично работает, Redmine тоже отлично бегает, радует глаз своими возможностями, и все хорошо. Создали проект, добавили хранилище и добавили прямой путь к репозиторию в gitolite для проекта. И думаем, вот сейчас все будет круто.
Но не тут то было. Redmine упорно не находит репозиторий. Вот не видит и все.
Проблема: rails-runner
не имеет доступа к файлам bare-репозитория.
Ложное решение: добавить пользователя rails-runner
в группу git
, и выставить права на все файлы в
репозитории с правами на чтение и выполнение для группы git.
На самом деле, Redmine увидит репозиторий. И тут кроется подводный камень, на который практически сразу натыкаешься после первого же push’а новых коммитов в gitolite-репозиторий.
Redmine снова перестанет видеть репозиторий, так как Git для некоторых каталогов и файлов, которые будут созданы в репозитории не выставит абсолютно никаких прав для всех, кроме владельца. И как раз из-за невозможности прочесть часть файлов, Redmine падает на просмотре репозитория.
В голову приходили самые разные решения данной проблемы. Можно было написать hook, можно было сделать mirror и push’ить еще в него к примеру, и еще десяток костылей, которым позавидует даже кобыла, несущая всякую ахинею в Новогоднюю ночь.
А все потому что, в Git уже давно есть очень мощная система конфигурации и в ней есть решение нашей проблемы.
Решение нашей проблемы называется core.sharedRepository
. Эта конфигурация говорит Git’у, какие
права выставлять на вновь создаваемые файлы, и имеет несколько вариантов настройки:
false
- права на доступ к файлам устанавливаются только владельцу;group
, true
- права на доступ к файлам устанавливаются для владельца и группы;all
, world
, everybody
- полные права для любого пользователя;umask
- заданная вручную umask
, которая нужна пользователю.Меняем настройки:
git config --global core.sharedRepository group
и наслаждаемся беспроблемной интеграцией Redmine и gitolite. Redmine не меняет файлы репозитория, так что по сути опасаться нечего, но особые параноики могут выставить свой umask.
После этого выставляем нужные права на уже существующие файлы, чтобы исправить ошибки - и забываем о проблеме, но мотаем на ус, что очень очень и еще раз чертовски очень полезно читать мануалы по настройке ПО, чтобы осознавать его возможности, и не изобретать костыли для решения тривиальных проблем.
Конечно, если у вас Gitolite и Redmine хостятся на разных серверах - то может и понадобится какой-нить плагин к Redmine, или более радикальное решение. Но когда надо расшарить репозиторий в пределах одной машины для нужных пользователей - можно и нужно использовать Git-only возможности в первую очередь.
За сим откланиваюсь.
]]>В данной статье я хочу рассмотреть реализацию данного API в браузерах на основе Chromium (Chromium, Google Chrome и вероятно другие его клоны).
На данный момент спецификация находится в разработке.
Notification API позволяет выводить уведомления пользователю на основе каких-то событий, либо пассивно (например, уведомления о новых сообщениях электронной почты, событиях в календаре или новых твитах).
Чтобы использовать эти возможности, нужно всего четыре простых шага.
Чтобы проверить поддержку NotificationAPI в браузере, нужно проверить
существование объекта webkitNotification
. Данное имя выбрано на время
разработки стандарта, и в окончательной спецификации будет заменено на
notifications()
функцию.
1 2 3 4 5 6 7 8 |
|
Существует два типа уведомлений, в зависимости от их контента: простой текст и HTML. Если ваше приложение использует оба типа уведомлений, вы можете создать функцию, которая будет создавать одно из них на основе передаваемых параметров.
1 2 3 4 5 6 7 8 |
|
Любой конструктор, который был продемонстрирован ранее, вызовет ошибку, если пользователь вручную не предоставил разрешение на показ уведомлений для сайта.
Можно использовать try-catch
конструкцию, для отлова исключения и его обработки, но более правильным путем будет использовать метод checkPermission
.
1 2 3 4 5 6 7 8 |
|
Если веб-приложение не имеет разрешение на показ уведомлений, то можно использовать метод requestPermission
, который покажет следующий infobar:
Важно помнить, что метод requestPermission
работает только в обработчиках событий, вызванных действиями пользователей, такие как события мыши или клавиатуры. Это сделано, чтобы избежать нежелательных показов infobar’а. В данном примере, пользовательское действие - это клик по кнопке с id “show_button”.
Фрагмент приведенный выше никогда не будет работать, если пользователь явно не нажал кнопку или ссылку, которая вызывает requestPermission
в каком-то месте кода.
1 2 3 4 5 6 7 8 9 10 11 |
|
Все эти события можно инкапсулировать в свой собственный класс, и сделать код чище, но это уже выходит за рамки статьи.
Здесь можете посмотреть дополнительные ссылки по теме:
В оригинале статьи можно также посмотреть примеры реализации в конце статьи.
Немного ссылок по реализации уведомлений в Gecko 2.0:
Префикс webkit
намекает на то, что вполне возможно, что уведомления уже доступны в других webkit-based браузерах, например Safari. Возможности протестировать это у меня пока нет.
Что касается других браузеров, то информации по реализации я пока не нашел, кроме как Mozilla Firefox. В будущем рассчитываю изучить этот момент, и найти информацию касательно планов разработки данной функциональности.
И в качестве вывода, хочется сказать пару слов удивления, почему до сих пор, я не видел иcпользования уведомлений ни в одном крупном веб-приложении, кроме продуктов Google (такие как GMail например), либо в расширениях Google Chrome.
]]>Было это классно. На деле, я ждал этой конференции наверное недели две с нетерпением, чтобы наконец там побывать.
С самого утра, все собирались у метро Приморская, где участников конференции встречала event-команда. Все было организованно, и красиво. Людей собирали, и на автобусах отвозили в гостиницу Park Inn Прибалтийская, где собственно и проходила конференция.
Всех участников на входе организованно провожали на регистрацию, выдавали надлежащий стафф в виде рекламных буклетов от MS, и стандартного блокнота и ручки, и анкеты участника для оценки конференции.
Пока все собирались, участникам был устроен кофебрейк с печеньками, интерактивными залами, где например, можно было попробовать себя в дартс, а в качестве мишени висел значок Internet Explorer 6, и конечно же делали памятные фото.
Так как на конференции я был один, то наблюдал за народом со стороны, дожидаясь собственно начала конференции.
Конференция проходила в большом пленарном зале. Открывали конференцию Александр Ложечкин (директор Департамента стратегических технологий Microsoft в России), и Николай Прянишников (президент Microsoft в России).
Александр красиво и подробно изложил как цели конференции, так и в общих чертах складывающуюся ситуацию в сфере веб-разработки, и в частности, что она влечет за собой.
Краткое выступление же Николая Прянишникова не порадовало особо, так как было похоже на какую-то рекламную акцию, хотя надо отдать должное, так как Microsoft является организатором.
После часового открытия конференции, все дождались выступления специального гостя из далекого США Бенжамина Лившица (исследователь из Microsoft Research).
Доклад был весьма технический, но поднимаемый вопрос - не менее важный. Несмотря на то, что Бен отлично говорит по русски, доклад все же был на английском, очень содержательным и подробным.
Тема приватности и безопасности в интернете сейчас очень актуальна и важна, кроме того обсуждались возможности сбора информации о пользователях, и способы ее обработки. В общих чертах конечно.
Сказать более подробно что-то увы не смогу, так как меня просто вырубало в сон (да, мне стыдно, но видимо сказался недосып).
Далее, во время перерыва зал разделили на два конференц-зала, для продолжения конференции по интересам.
Я остался слушать доклад Гайдара Магданурова о Node.js на Windows. По поводу доклада. Доклад был предназначен скорее для тех, кто не знаком с Node.js, и честно сказать, тема Windows в докладе почти не присутствовала, так как сам доклад выглядел как демонстрация возможностей.
Что порадовало, так это то, что Node.js уже работает под Windows, хотя когда-то это было очень проблемно.
Как показал краткий опрос проведенный Гайдаром, среди участников, мало кто слышал о Node.js, и еще меньше использовали его в production, что честно говоря меня удивило. Я надеялся увидеть лес рук, но его не было.
Помимо всего, в докладе, Гайдар пожаловался на слабые стороны Node.js (действительно, отладка с дебаггером - это очень страшное занятие), ведь на Windows до сих пор не поддерживается Node Inspector.
Ну и также, посмеялись над фанатами Javascript. В зале оказался всего лишь один фанат.
Доклад был очень показательным, и полным для демонстрации, и очень хорошо приправленных харизматичностью Гайдара, который не давал слушателям скучать. Честно сказать, покидал я доклад с очень большой грустью, потому что хотелось еще. Не каждому дано интересно и красиво выступать с докладами, чтобы это было интересно.
Вместе со мной, зал покинуло большинство людей, несмотря на то, что следующим докладом в первом зале был доклад Бена Лившица, и снова о безопасности. Видимо таки, многие пришли посмотреть и послушать про новые возможности HTML5.
Следующим докладом был “От уголков до анимаций: погружение в новые возможности CSS3” от Константина Кичинского. Лично для меня доклад был не особо информативным, так как демонстрировались базовые возможности CSS3, которые я уже давно стараюсь использовать везде где только можно, отчасти потому что, это действительно удобно, отчасти потому, что я хреновый художник, и в глаза Photoshop в жизни видел наверное пару раз.
Сам доклад был хорошим, и судя по всему многим дал много новой полезной информации. Народу было не протолкнуться (интересно, а кто слушал доклад Бена в соседнем зале?).
В частности, этот доклад был для меня еще некоторой пищей для размышлений, после наблюдения за другими участниками конференции.
Не обошлось на докладе и шуток в сторону Microsoft. Так как все надо было демонстрировать, и Костя как и обычный человек порой опечатывался, то выходили и ошибки. На одну из таких ошибок, из зала вылетел довольно хороший укол в виде “используй Chrome”. Зал поржал, а Косте надо отдать должное - очень стойкий. Молодец.
После двух часов докладов, все отправились на обед. Я особо не буду задерживаться на этом моменте. Впереди меня ждало еще два часа докладов.
Первый из которых я посетил был второй доклад Гайдара Магданурова “Игры воображения с новыми API для Javascript”. В своем докладе, Гайдар продемонстрировал возможности нового стандарта JS 5, такие как FileAPI, AppCache, Web workers, HistoryAPI, и другие. Для демонстрации вновь использовался Node.js.
Кроме того, как бы невзначай, слушатели увидели воочию работу Windows 8. У Гайдара стояла на машине Windows 8, и он то и дело “невзначай” промахивался, открывая интерфейс Метро. В остальном, Windows 8 была не отличима от Windows 7. Кстати говоря, судя по тому, что на ней уже многое работает, она довольно таки production-ready.
Не обошлось без шуток и “рекламы”. Шутка “самый лучший браузер в мире” после третьего или четвертого повторения уже не имела никакого эффекта.
Доклад был очень информативен, несмотря на всего лишь базовый обзор возможностей. Было описано также много подводных камней. Еще раз спасибо Гайдару.
Слушать про достижения от компании 1С мне было совсем не интересно, как и многим другим, судя по моим наблюдениям. Я решил отправиться на доклад технического директора Keiss Media Павла Криворучко.
Павел поделился историей успеха его компании на рынке поставки HTML контента, поделился опытом, который они приобрели наступая на грабли во время разработки множества HTML-игр для мобильных платформ, а также дал много полезных советов, которые стоило намотать на ус.
Доклад очень ободрил, и дал надежду на будущее, дал не просто надежду, но и вселил очень большой оптимизм. Оптимизму Павла и его компании можно только позавидовать.
Самым же ценным советом от Павла мне кажется был его заключительный совет, заключающийся в призыве использовать HTML5 технологии уже сейчас, в призыве писать много новых интересных приложений, и если есть удачные веб-приложения в виде сайтов, то писать для них интересные мобильные клиенты.
Следующим докладом, на который я заранее планировал попасть был доклад разработчика интерфейса Я.Почта Алексея Андросова.
Алексей очень хорошо изложил как они используют новые возможности в сервисе Яндекс.Почты. Прошелся по новым возможностям HTML5, и о том, какие грабли они встретили на своем пути.
В частности, много было посвящено проблеме WebSocket’ов, Server-Sent Events, flash-websocket и long-polling. Тема очень горячая, и очень интересная, а опыт Яндекс в использовании этих технологий неоценим.
Алексей также рассказал про использование AppCache, о котором ранее в своем докладе рассказывал Гайдар, и пожаловался на топор в спину Яндекс со стороны Firefox (да, огненная лисичка подвела их).
По мере доклада, Алексей представил не мало полезных советов, за что ему огромное спасибо.
После перерыва, все снова собрались в пленарном зале, который уже объединили, для выступления Владимра Колесникова (еще одного представителя Microsoft). На этот раз тема была не столь волнующа для многих, но не менее интересна. Касалась она разработки мобильных приложений для Windows Phone 7.
В целом, обзор был интересный, хотя местами что-то не получалось. Помимо стандартного обзора возможностей написания HTML5 приложений для Windows Phone 7, была продемонстрирована возможность использования PhoneGap для написания кроссплатформенных приложений с его помощью, а также дан краткий обзор возможностей использования его вкупе с jQuery Mobile.
Владимир вовремя предостерег от граблей как в использовании PhoneGap, так и в использовании его вместе с jQuery (так как самые новые их версии, увы работать вместе не могут).
Также мне понравилась демонстрация возможностей интерфейса Metro, в частности тайлов.
Ну и в довершении всего Владимир очень хорошо подвел черту под тем, какой должен быть интерфейс мобильного приложения, чтобы быть удачным, и иметь успех у пользователя. Советы во многом очевидные, но как всегда и бывает, все что на поверхности - зачастую забывается и не используется.
В завершении доклада Владимира, его ждал большой “сюрприз”. Один из слушателей, дорвавшись таки до микрофона, задал вопрос, который не знал кому задать весь день: “Когда наконец-то Internet Explorer будет поддерживать стандарты?”.
Швал аплодисментов был просто бешеный. Владимир с Гайдаром действительно не нашлись что ответить, и по ним было видно, что они потеряны, а “перепалка” заняла минут пять.
Разрулил ситуацию Костя, очень адекватно и обстоятельно подойдя к вопросу, прислушавшись к автору вопроса, и попытавшись выйти из трудной ситуации. Это у него получилось, и это еще один раз, за что ему хочется отдать должное.
Честно говоря, я думаю каждый сидящий в то время в зале ожидал, когда же этот вопрос будет задан.
На этом доклады закончились. Онлайн трансляция была завершена, а участники остались для завершающей части с розыгрышем призов.
Константин Кичинский подготовил простенькую викторину, по которой разыграли пары памятных пивных кружек с эмблемой Internet Explorer.
Вопросы были в основном по второму докладу Гайдара, но не смотря на это, были случаи, когда на них не могли ответить. Ну а я замешивался поднять руку, и как грится проворонил свои памятные призы.
Особенно порадовал первый вопрос: “Что такое W3C?”. Ответ одного из участников был гениальным: “Такая организация, которая занимается стандартами”. Ответ прошел, но Костя на деле подготовил просто сногсшибательный правильный ответ: “Консорциум WWW, или ужас летящий на крыльях ночи”, чем сорвал куш.
Дополнительные призы в виде веб-камер и компьютерных мышей был разыгран по анкетам, которые выдавали при регистрации на конференции.
На этом конференция закончилась, все поблагодарили организаторов, и отправились на фуршет, или прямиком домой, как это сделал я. Конференция жутко понравилась, было действительно весело и интересно, особенно на докладах Гайдара, который даже не смотря на возникающие проблемы подбадривал аудиторию, и всячески старался не дать заскучать, за что ему отдельное спасибо.
Общие впечатления от прошедшей конференции у меня крайне положительные. Мое отношение к этой компании существенно изменилось. Не то, чтобы я стал лоялен к их продуктам, или проникся желанием стать Windows-разработчиком, но.
Там действительно работают веселые и позитивные люди, которые как и мы видят идеальный мир, идеальное ПО, и эти люди открыты и позитивны. Может быть взгляды и стратегии у нас с ними разные, может быть в обыденной жизни, мы конкуренты - но на конференции были не “злые дяди из Microsoft”, а очень позитивные и открытые люди, которые пригласили своих коллег не чтобы провести очередное впаривание своих продуктов, но и поделиться опытом с другими, и хорошо провести время.
И спасибо им, за этот теплый прием. Если у меня выдастся возможность попасть на HTML5 Camp в следующий раз - я обязательно сделаю все, чтобы туда попасть.
После конференции остались не только приятные впечатления от классных докладов, позитивных людей, хорошего настроения и теплого приема, но и осталось довольно много пищи для размышлений, и для подтверждения мыслей и ощущений связанных с наблюдением за веб-разработкой, как огромной индустриальной областью.
С одной стороны, на конференции присутствовало много людей, которые были либо вообще не веб-разработчиками, либо почти ничего не знали о HTML5.
Это и удивительно, и не очень. Я уже честно говоря привык к тому, что многие веб-разработчики - очень консервативные люди, которые зачастую просто боятся использовать новые возможности и технологии.
Да. Веб-разработка - это очень вязкая и неоднозначная сфера, в которой разработка не может вестись без десятка другого костылей, без решения множества проблем, которые не приносят никакого удовольствия.
И постоянная забота о развитии продуктов, о совместимости браузеров и многие другие вещи. Все это сделало многих разработчиков - консерваторами.
Это привело к очень сложной ситуации на рынке. Мало того, что найти веб-разработчика (я не имею ввиду PHP CMS’о настройщиков), я имею ввиду именно веб-разработчика (PHP, Python или Ruby, а может Java - не важно), так еще меньше из этих разработчиков не являются консерваторами.
Тем временем, существует большое количество прогрессивных разработчиков, которые двигают отрасль вперед, не боятся новых возможностей, и как можно больше придумывают нового. Но их все равно несоизмеримо меньше.
Это создает очень большой разлом, между используемыми технологиями и накопленным опытом, и между технологиями, которые появились недавно, требуют много внимания, активного внедрения и использования, “обкатки” если хотите.
Учитывая, что мы сейчас стоим действительно на пороге революции в вебе - я даже не боюсь сказать, что это будет не Web 2.0, и не Web 3.0, это будет что-то совершенно новое (эти мои мысли однозначно подтверждает и то, что гиганты индустрии кинулись в эту область разом), такой разброд, такая “разладка”, такой разлом не играет отрасли на руку.
Кто-то так и останется навсегда позади, кто-то уже впереди, а у кого-то еще есть возможность встать на гребень волны. И эту возможность нельзя упускать ни в коем случае.
Что еще хочется сказать от себя. HTML5 требует новых решений, нового опыта, и глобальные изменения претерпят не только инструменты разработки клиентской части приложения, но эти изменения во многом требуют кореных и очень сильных решений в разработке серверных решений, и таких решений пока очень мало, и они очень нужны. И опять таки, открывается очень большой простор.
Настает момент еще большей фрагментации и более узкой специализации веб-разработчиков. А сама веб-разработка, несмотря на мнение многих, становится не менее сложным занятием, чем разработка сложных технологий, например в области операционных систем, каких-то серверов, или математических вычислений. Сложность веб-разработки растет с каждым днем, и очень радует, что веб-разработчики более ленивы, и стараются создать инструменты, которые максимально стараются облегчить жизнь, так как жизнь итак усложняется непомерным количеством костылей, и других проблем.
И да. Веб-разработка выходит на первое место. Нравится кому или нет, это сейчас наиболее приоритетная область, которая будет двигать очень большой пласт остальных отраслей IT.
Еще один момент, который совершенно не радует: вся эта суматоха, весь этот сумасшедший ритм приводит к тому, что новые возможности стараются внедрять многие, но многие это делают просто бездумно. Как уже сегодня эта тема обсуждалась мной в Juick, то я приведу очень яркий пример: Unity и Gnome 3. И если Unity еще очень отдаленный пример такого стремления и непонимания, и ее разработчики очень аккуратно проходят минное поле, то разработчики Gnome 3 собирают на минном поле все мины. Это яркий пример того, как люди начинают замечать новые тренды, новые возможности, но не знают как правильно их использовать. И это очень плачевно.
Фотографий с конференции не будет, так как ваш покорный слуга не фотографировал, а следовало бы.
Ну и простите за столь объемный пост, и столь сумбурные мысли. Я старался собрать в голове все впечатления как от конференции, так и свои ранние мысли в одно, и поделиться с вами. Не судите строго.
]]>Еще в начале 2010 года, Vincent Driessen написал статью, в которой описал опыт использования Git, и обобщил свой опыт в виде модели использования веток при организации хранения кода под управлением Git.
Свою статью он опубликовал по в своем блоге, и ее можно почитать в оригинале: A successful Git branching model.
В данном посте, я приведу свой немного вольный перевод этой статьи.
Предлагаемая модель управления исходным кодом, с использованием Git, успешно использовалась автором на всех его проектах (рабочих, и собственных). В статье не говорится о деталях проектов, а статья содержит лишь описание модели, которую автор с успехом применяет в повседневной разработке программного обеспечения.
Данная модель позволяет использовать Git именно как инструмент для контроля версий, в контексте разработки программного обеспечения.
Данная статья не о Git как таковом, не о его преимуществах и недостатках. Эта статья лишь описывает одну из моделей разработки проекта, с применением особенностей Git.
Модель предложенная автором статьи базируется на особенностях работы Git с ветками версий. Для сравнения, если рассматривать классические централизованные системы контроля версий, такие как CVS/SVN, то можно увидеть более консервативный и осторожный подход к использованию веток, а также их объединения. Данные операции являются тяжелыми и сложными, а в любой книге, посвященной данным системам, такие операции описываются в разделе предназначенном для опытных пользователей. Зачастую, операции создания и объединения веток в репозитории являются привилигированными операциями, и разработчики не имеют к ним доступа.
Распределенные системы контроля версий, такие как Git, напротив, базируются на идее активного использования веток, их создания и объединения. Это позволило создать еще одну эффективную модель разработки, которая отлично подходит как для разработчика-одиночки, так и для командной разработки.
Что касается самой модели, то это не панацей, не великое открытие. Это всего лишь набор процедур и подходов, придерживаясь которых можно сделать процесс разработки ПО управляемым. Конечно, чтобы данная модель принесла свои плоды, требуется четкое соблюдение процедуры не отдельными разработчиками, а каждым участником команды. Как показала практика, и опыт применения этой модели автором на реальных проектах, модель является весьма жизнеспособной и эффективной.
Несмотря на долгое существование Git на рынке, как и децентрализованных систем управления версиями, до cих пор имеет место путаница в связи с централизованностью.
При разработке с использованием Git, всегда создается единый центральный репозиторий. С технической точки зрения, этот репозиторий не является центральным, так как такого понятия в Git просто не существует. Разделение на центральный, и остальные репозитории является чисто логическим, и завязано на соглашениях в конкретном проекте и команде. Центральный репозиторий, с которым работает команда, обычно называется origin
.
Каждый разработчик используя push
и pull
может в двустороннем порядке обмениваться изменениями между своим локальным репозиторием и origin
. Но, кроме двунаправленного обмена между указанными хранилищами, возможен также двусторонний обмен с хранилищами других разработчиков. Это может быть полезно, когда в проекте, над разработкой какого-либо функционала работают несколько разработчиков. Во время разработки, эти изменения не должны попадать в origin
, но в то же время, должен происходить обмен изменениями, произведенными каждым из разработчиков. В этом случае, разработчики обмениваются изменениями между своими локальными репозиториями, не затрагивая код в origin
.
На рисунке выше показан пример такой организации работы. В команде четыре разработчика. Каждый из них имеет доступ к origin
, но помимо этого можно выделить три группы разработчиков, которые обмениваются изменениями только между собой: Алиса и Боб, Алиса и Дэвид, Клер и Дэвид.
С технической стороны, это означает, что к примеру Алиса работает с двумя удаленными репозиториями: origin
и bob
(который принадлежит Бобу), и наоборот.
Представленная модель в значительной степени вдохновлена уже существующими моделями. Центральное хранилище предоставляет две ветки с бесконечным жизненным циклом:
master
develop
Ветка master
в хранилище origin
знакома каждому пользователю Git. Паралелльно с веткой master
, существует другая ветка, называемая develop
.
Ветка origin/master
мы рассматриваем как главную ветку, HEAD
в которой, всегда указывает на production ready состояние.
Ветка origin/develop
рассматривается как главная ветка, в которой HEAD
отражает состояние исходного кода, на момент последних изменений, подготовленных к следующему релизу. Некоторые называют эту ветку integration branch. Например, HEAD
этой ветки используется для ночных сборок.
Когда исходный код в ветке develop
достигает стабильности, и содержит уровень функциональности близкий к желаемому, все изменения из develop
должны быть внесены обратно в master
, и отмечены тегом соответствующего релиза.
Исходя из всего вышесказанного, можно заявить, что каждое внесение изменений в master
, является очередным релизом по определению. Если строго подходить к этим рекомендациям, то теоретически, можно использовать хук(hook) к скрипту Git, для автоматической сборки и развертывания ПО на production-серверах, после каждого коммита в master
.
В предлагаемой модели, помимо двух главных веток (master
и develop
), также используются вспомогательные ветки, которые позволяют облегчить ведение параллельной разработки членами команды, слежение за спектром разрабатываемого функционала проекта, подготовку к релизам, а также помогают в решении проблем, которые возникают в production коде. Но в отличии от главных веток, эти ветки имеют ограниченное время жизни, так как рано или поздно будут удалены.
В качестве основных вспомогательных типов веток могут быть выделены:
feature
release
hotfix
(Оригинальные названия типов веток сохранены намерено, во измежание путаницы в переводе. Прим. перев.)
Каждый из этих типов веток имеет конкретные цели и правила работы с ними. Для них строго определены те ветки, от которых можно произвести ветвление, и с какими ветками должны быть объединены. И опять же, во избежание введения в заблуждение, стоит оговориться, что эти ветки никак не являются “специальными” с технической точки зрения. Это обычные ветки Git. Их типизация зависит от правил, которые придерживаются при работе с ними.
feature
Правила ветвления, слияния и именования:
develop
;develop
;master
, develop
, release-*
, hotfix-*
.В ветках feature
ведется разработка функционала для будущих релизов проекта. На момент начала работы над новым функционалом, релиз в котором он появится может быть и неизвестен. Суть таких веток в том, что разработка новых функциональных возможностей может вестись параллельно разработке основной части проекта, а по завершении реализации нового функционала он может быть внедрен в одном из следующих версий, либо отклонен (в случае, если функционал не удовлетворяет целям проекта, либо по каким-либо другим причинам). Такие ветки должны создаваться в локальных репозиториях разработчиков, но ни в коем случае не в origin
.
feature
Для создания ветки feature
:
1 2 |
|
При создании ветки feature
ветвление осуществляется от develop
.
feature
Законченный функционал может быть объединен обратно с веткой develop
для добавления его в следующий релиз:
1 2 3 4 5 6 7 8 |
|
Использование флага --no-ff
создает новый коммит, который содержит все изменения сливаемой ветки. Это позволяет избежать потери информации о существовании ветки, в которой велась разработка добавленного функционала. Для сравнения, взгляните на изображение ниже. Слева слияние с использованием флага --no-ff
, справа без него:
Как видно, если не указать флаг –no-ff, изменения которые делались в ветке feature
, невозможно будет увидеть. Это чревато тем, что для того, чтобы увидеть все изменения сделанные в ветке feature
, придется перечитать все сообщения журнала, и выбирать именно те коммиты, которые касаются интересующих изменений. Отмена изменений ветки feature
также становится настоящей головной болью, тогда как --no-ff
упрощает эту задачу, ведь откатить придется всего лишь один коммит. Хотя именно такое поведение более предпочтительною
Для установки такого поведения слияния по умолчанию, можно заставить Git использовать --no-ff
по умолчанию, путем правки .gitconfig
, и добавления следующих строк:
1 2 |
|
release
Правила ветвления, слияния и именования:
develop
;develop
и в master
;release-*
.Ветки release
используются при подготовке к выпуску очередного релиза. Они позволяют в самую последнюю минуту расставить все точки над i. Кроме того, они позволяют вносить исправления мелких ошибок, и подготовить метаданные для релиза (номер версии, дата создания и т.д.). Делая все эти действия в ветках release
, ветка develop
останется чиста, и будет готова к добавлению нового кода, отвечающего непосредственно за расширение функционала разрабатываемого продукта.
Создание ветки release
производится в тот момент, когда состояние кода в develop
отражает желаемое состояние нового релиза. По крайней мере, весь запланированный функционал ожидаемый в релизе, уже должен быть в develop
ветке. Весь оставшийся код, отвечающий за расширение функционала, и отложенный на будущие релизы, должен ожидать, пока не будет выпущен релиз.
Именно при создании release
ветки, релиз получает номер версии, а не раньше. До этого момента, в ветке develop
отражены изменения запланированные для выпуска в следующем релизе, но станет ли следующий релиз 0.3
или 0.1
неизвестно до создания ветки release
. Присвоение релизу номера версии происходит в момент создания release
. Присвоение релизу номера версии происходит в момент создания release
ветки, и следует правилам нумерации, которые предложены в проекте.
release
Ветки release
создаются ветвлением от develop
. Создание такой ветки покажем на примере. Пускай версия 1.1.5
- это текущий production релиз, и мы приближаемся к следующему большому релизу. Состояние ветки develop
говорит о готовности к следующему релизу, и мы решили, что это будет 1.2
, а не 1.1.6
или 2.0
. Теперь, мы создаем ветку, и даем ей имя отображающее номер релиза:
1 2 3 4 5 6 7 |
|
После создания новой ветки, и переключения на нее, мы изменяем везде номер версии на новый. К примеру это могут быть номера версии в исходных файлах проекта, в параметрах сборки executable файла, или еще что-то. В примере выше, это автоматизировано, и для этой цели используется вымышленный скрипт bump-version.sh, который производит нужные изменения в файлах рабочей директории, для отображения состояния новой версии. Это конечно может быть произведено и в ручную. В нашем примере, мы используем некий абстрактный проект. После этого заносим изменения в RB.
После создания новой ветки, и переключения на нее, мы изменяем везде номер версии на новый. К примеру, это могут быть номера версии в исходных файлах проекта, в параметрах сборки выполняемого файла, или еще что-то. В примере выше, это автоматизировано, и для этой цели используется вымышленный скрипт bump-version.sh
, который производит нудные изменения в файлах рабочей директории, для отображения состояния новой версии. Это конечно может быть произведено и в ручную. В нашем примере, мы используем некий абстрактный проект. После этого заносим изменения в ветку release
.
Этот процесс очень похож на выпуск так называемой бета-версии, когда производится только тестирование продукта, поиск и исправление ошибок, но уже никакой новый функционал не добавляется.
release
и выпуск релизаКогда состояние кода в ветке release
готово к выпуску релиза, необходимо провести некоторые действия. Во-первых, нужно влить ветку release
обратно в master
(напомним еще раз, что каждый коммит в master
- это новый релиз по определению). Далее, сделанный коммит следует отметить тегом, отображающим номер версии, что поможет в будущем легче ориентироваться в релизах. И наконец, изменения сделанные в ветке release
должны быть слиты обратно в develop
, так чтобы будущее релизы содержали все исправления, сделанные в процессе подготовки релиза.
Первые два шага в Git:
1 2 3 4 5 6 |
|
Релиз выпущен, и помечен для будущего использования.
Для того, чтобы сохранить изменения сделаные в ветке release
, нужно слить их обратно в develop
:
1 2 3 4 5 |
|
Этот шаг может привести к конфликтам во время слияния. Если такое произойдет, то следует исправить конфликты, и зафиксировать изменения.
Теперь релиз полностью выпущен, и release
ветка может быть удалена, так как она нам больше не нужна:
1 2 |
|
hotfix
Правила ветвления, слияния и именования:
master
;develop
и master
;hotfix-*
.Ветки hotfix
очень похожи на ветки release
в том, что они также предназначены для подготовки к новым релизам, хотя и не запланированным. Они возникают, из-за необходимости действовать сразу же после обнаружения серьезной ошибки в production коде. Когда критическая ошибка в production версии должна быть разрешена немедленно, hotfix
может быть создана ветвлением от коммита в ветке master
с меткой текущей production версии.
Использование такого перехода заключается в том, что члены команды смогут дальше продолжать решение поставленных задач (в ветке develop
), в то время как ответственный разработчик будет готовить исправление ошибки в production версии.
hotfix
Ветка hotfix
создается ветвлением от ветки master
. Рассмотрим небольшой пример. Допустим, версия 1.2
является текущей production версией, которая сейчас используется и вызывает проблемы из-за нескольких досадных и неприятных ошибок в коде. Изменения в ветке develop
пока нестабильные, чтобы делать новый релиз. В таком случае, мы ветвлением от master
создает ветку hotfix
и начинаем исправлять ошибку в рамках этой ветки:
1 2 3 4 5 6 7 |
|
Не забывайте применить изменения версии после ответвления!
После, исправляем ошибку и фиксируем исправление одним или несколькими коммитами.
1 2 3 |
|
hotfix
и выпуск внеочередного релизаПосле исправления ошибки, нужно слить ветку hotfix
обратно в ветку master
, но также требуется объединить эту ветку обратно с develop
, с тем, чтобы гарантировать, что исправления будут доступны и в последующих релизах. Эти действия аналогичны закрытию ветки release
.
Обновим ветку master
и тег релиза.
1 2 3 4 5 6 |
|
Затем, занесем исправление в ветку develop
:
1 2 3 4 5 |
|
Из правила работы с ветками hotfix
есть одно исключение: если ветка release
уже существует, изменения ветки hotfix
должны быть слиты обратно в ветку release
, исключая при этом ветку develop
. Слияние с веткой release
приведет к тому, что после выпуска релиза, исправление будет также доступно и в ветке develop
. (Если работа в develop
требует немедленного исправления, и не может ждать пока будет выпущен релиз, можно безопасно занести исправление и в develop
).
В конце, удаляем ветку hotfix
:
1 2 |
|
Предложенная модель в чем-то может показаться знакомой, и может сложиться ощущение, что автор изобрел велосипед. На самом деле, автор объединил существующие подходы, очевидные вещи в единую логичную системы и подвел черту. Данная модель не является серебрянной пулей, но она проста, наглядна и легка в применении. Модель отлично подходит для тех проектов, где используется Git. Также, данная модель помогает развить понимание ветвления и процесса выпуска релизов.
]]>