Часто ли вы задумывались над тем, какие ветки будут отправлены в удалённый репозиторий при выполнении команды push?

А поможет ли вам задуматься над этим такая картина?

Наверное, поможет, особенно если увидеть это в ночь перед релизом. А началось-то все с того, что хотели фичу красиво слить через rebase.

Так давайте разберёмся, что пошло не так.

В компании, в которой я работаю в настоящее время, мы используем при разработке довольно распространённую модель ветвления, а в качестве инструмента для стандартизации работы по этой схеме git-flow. Так же мы дополнили эту схему ещё одной веткой — staging. Это временная ветка, в которую сливаются feature branches, и на основе неё делаются промежуточные релизы на тестовый сервер. Естественно, всё, что происходит в этой ветке, нужно для предварительного просмотра и тестирования выполненных задач и никак не должно попадать ни в основную ветку разработки, ни в master, то есть в итоговый релиз. В принципе, схема работы достаточно удачная. Она упрощает взаимодействие и работу большой команды с разным навыком работы с git, и нештатные ситуации случаются достаточно редко, но зато, если случаются, то это запоминается надолго.

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

Всё что мне нужно для презентации это — каскад слайдов и иметь возможность переходить по ним в разных направлениях, чтобы текст с них хорошо читался и выглядело красиво. Я ленив. Я хочу просто набрать текст, нажать кнопочку и чтобы БАХ, и мой текст превратися в презентацию размещённую в интернете и готовую к показу.

Мечта? Нет. Реальность.

Сейчас стало модным делать стартапы. У каждого второго разработчика есть свой. А в Rails сообществе ­— у каждого первого, наверное. И чтобы оставаться в тренде я тоже решил принять участие в разработке одного интересного сервиса.

Небольшая история о том, как я докатился до такой жизни.

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

Я написал плагин для этого. https://github.com/Andrew8xx8/jekyll-link

Однозначного и общеизвестного ответа на вопрос “Что положить в либ?” нет, обычно туда валится всё, что нельзя положить в другие места. Вопрос что с этим делать дальше.

Я устал от того, что начав работу с проектом и открыв терминал, я вынужден каждый раз открывать вкладки и запускать в них однотипные команды. Отсутствие же адекватных названий вкладок, в случае, если открыто более одного проекта, превращает навигацию по открытым терминалам в ад. Terminal, Terminale, Termina and so on…

В связи с этим я решил привнести немного автоматизации в этот процесс.

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

Начиная с версии CS-Cart 3.0 используется новая философия блоков и блок менеджера в частности.

Ключевым моментом здесь является использование CSS фреймворка 960gs (сайт проекта http://960.gs).