Opencart CE (Community Edition)

- Posted in Uncategorized by

Давно я ожидал появления альтернативной версии репозитория Опенкарт с более адекватным ведением дел. Вообще-то думал, что он чуть раньше появится. Но чтобы его объявили прям в "новостях и анонсах" на форуме -- не ожидал. Смело :) Я думал, будет как-то менее заметно и в одном из репо десятка-другого активных разработчиков и комиттеров, разочаровавшихся в политике DK. Респект rph :)

Вообще-то в какой-то момент, когда Qphoria начал бранчи в гитхабе изучать, я поверил, что не всё потеряно. Но потом опять началось, ДК ничуть не изменился. Workflow в гитхабе также остался прежним.

В общем, на днях (21 июня) пара квалифицированных разработчиков (rph /opencarthelp/ и AddCreative как минимум) объявили о рождении "community edition" форка (ответвления от основного репозитория Opencart). Судя по списку планируемых вопросов -- с этими людьми "кашу сварить" можно. И скорее даже нужно. Очень надеюсь, что там дело пойдёт намного лучше по части совместной разработки.

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

Чтобы было чуть более понятно, надо пояснить, как сейчас ведутся дела.

Дальше я буду оперировать понятиями, привычными для Git.

  • По-хорошему, обычно принято, чтобы в главной ветке (`master` или `trunk`) находилась стабильная версия проекта. Которую любой разработчик или пользователь может взять и смело выгрузить на production server и быть уверенным, что работает со стабильной и проверенной версией продукта.
  • В девелоперской ветке ведётся основная работа: там расположена текущая, самая свежая, но необязательно стабильная, версия. Там могут быть ошибки и вообще содом и гоморра. Это не для конечных пользователей. Когда там всё устаканивается и протестировано, изменения из `dev` ветки вливаются в `master` и выпускается новый релиз.
  • Если версии рассматриваются просто как вехи в истории, которые в будущем не исправляются, а предполагается работа с последней, наиболее свежей версией -- достаточно просто помечать их тегами. Тег в гите - это просто закладка с именем.
  • Если надо версии сопровождать какое-то время -- они должны выделяться в отдельные ветки. Тогда при обнаружении и исправлении каких-то ошибок надо внести исправления во все поддерживаемые ветки (версии), где эта ошибка присутствует.

Вот вкратце и всё. Можно ещё упомянуть, что гораздо разумнее работу в `dev`-ветке также вести в отдельных ветках (небольших, временных, с префиксами `feat-` и `fix-`). Во-первых, это способно избавить ветку от мусора и мешанины при активной работе (особенно командной, но и при работе в одиночку это справедливо) и сделать историю гораздо более понятной. Во-вторых, фикс, находящийся в отдельной ветке, можно легко и просто применить к множеству ветвей с версиями. Без выколупывания diff-ов, patch-ей и ручной работы.

В Опенкарт (главном репозитории):

  • вся разработка ведётся в единственной ветке. То есть по факту это девелоперская, "грязная" ветка;
  • релизы никак не помечаются тегами, что очень сильно затрудняет обнаружение конкретной версии в истории. По сути, обнаружить место релиза нереально, если только не успел сам отметить в своем репозитории момент выпуска новой версии. Или по каким-то косвенным признакам и комментариям, может по дате;
  • не устанавливаются никакие связи с багтрекером (вернее, issue tracker-ом), про "smart commit messages" DK тоже не в курсе и продолжает постить в историю сплошной поток изменений. Понять, где именно был пофиксен какой-то баг?... А вот фигвам. Поди найди через полгода или даже через неделю, что было сделано для исправления ошибки, отчет о которой читаешь.

В новом репо (Opencart CE) версии будут выделяться в самостоятельные ветки и сопровождаться в будущем силами сообщества. То есть теперь гораздо больше шансов, что версия 1531 (например) получит все возможные исправления и не надо будет обновляться до 1551 (которая со своими новыми фичами никак вас не волнует, поскольку ничего нужного вам там не появилось).

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

Будем следить за развитием событий!

Links

Немцы выложили законы на гитхаб для мержей и пулл-реквестов

- Posted in Uncategorized by

@vessi at Juick:

*Германия *вин *git немцы выложили законы на гитхаб. Можно делать пулл-реквесты, после одобрения бундестагом они будут смержены.

https://github.com/bundestag/gesetze

German Federal Laws and Regulations This Git repository contains all German federal laws and regulations in Markdown format. The source is the XML version of the laws from www.gesetze-im-internet.de.

git-flow: A collection of Git extensions to provide high-level repository operations for Vincent Driessen's branching model

- Posted in Uncategorized by

git-flow

A collection of Git extensions to provide high-level repository operations for Vincent Driessen's branching model.

https://github.com/nvie/gitflow#readme

http://nvie.com/git-model

Как облегчить процесс публикации изменений на сервер

- Posted in Uncategorized by

[Git, FTP] Для FTP и shared hosting (без SSH доступа и полноценной консоли)

Рекомендую готовый скрипт git-extract:

По команде, в которой указывается диапазон коммитов, создаёт папку .deployment с готовым деревом и изменившимися файлами. И список удаленных файлов, которые придётся удалить вручную (если пользуетесь FTP клиентом) или через SSH на сервере (если есть такая возможность).

У скрипта есть маленькая особенность: запускать его надо в корне репозитория (там, где расположена скрытая папка `.git`). Не в подпапках из любого места репо: там он просто отработает вхолостую.

[Git, SSH] При полноценном хостинге (с SSH доступом)

Судя по всему, у меня сделано один в один как в http://habrahabr.ru/blogs/Git/127213/, поэтому не вижу смысла описывать то же самое. У меня немного отличается структура папок проектов, но это несущественно. Суть проста - на сервере лежит как Git-репозиторий, так и обычная рабочая копия (на которую смотрит веб-сервер). Точнее, на одну из папок репозитория - public_html. Потому что в репозитории хранится ещё документация, служебные скрипты, тестовые и чистые SQL дампы.

И при новых коммитах от разработчиков (git push) репозиторий по хуку делает автоматически две операции - обновление локальной серверной копии (git pull origin dev) и копирование набора файлов из config_sets (здесь у меня хранятся файлы, специфические для разных конфигураций: для одного разработчика, для другого, для dev2-windows, dev2-linux, для production1, production-dev и так далее, если надо ещё больше). Понятна идея? Требуемый набор конфигов просто перезаписывается поверх того, что есть в репозитории (а туда могут попасть и локальные конфиги девелоперов, если они не исключены через .gitignore), и получается чистая и настроенная конфигурация. Быстро, без чек-листов, ручных проверок-исправлений и условий-ветвлений с множеством девелоперских конфигов (зачем они на сервере?).

Естественно, на сервере настроено использование SSH-ключей, чтобы избавиться от необходимоси ввода пароля после git pull.

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

См. также

[PHP, FTP] Web based FTP Sync Tool written in PHP. Есть возможность запрещать синхронизацию для отдельных файлов/папок.

[Windows, GUI] Сделать архив, содержащий только измененные файлы (сохранив при этом всю структуру папок) может также WinMerge: http://opencartforum.ru/topic/28606-решено-winmerge-как-сделать-изменения-в-движке-и-сохра/#entry223289

Что такое diff

- Posted in Uncategorized by

При публикации изменений используется формат DIFF. С его помощью можно перенести небольшие изменения к себе вручную (см. ниже). Или автоматически: командами git apply rb-patch.diff или patch -p2 < rb-patch.diff (находясь в корневой папке магазина - там, где расположены каталоги admin и catalog).

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

Перенос изменений вручную

См. http://rb.labtodo.com/page/opencart-admin-attributes-usability-improvement#comment-138

Это список изменений. В начале строк - индикаторы: что убрать (минусы, красный цвет) в старом файле и что добавить (плюсики, зелёный цвет).

В каких именно файлах - указано утроенным значком (---, +++)

@@ -106,10 +106,12 @@ -- строки, т.е. примерно на 106 строке вы должны найти похожий кусок кода, перед и после блока изменений обычно выводится пара строк текста. "Примерно 106" - потому что я множество правок вношу в свой магазин и содержимое файлов может не совпадать с оригинальным OpenCart 1.5.1.1 или с тем правками, которые внесены у вас до меня.

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

В данном случае надо закомментировать небольшую часть в файле admin/controller/catalog/attribute.php и модифицировать одну строку в admin/model/catalog/attribute.php (заменить её на несколько новых, которые можно скопировать и убрать плюсики в начале строк).

См. также

  • Улучшение сортировки на витрине Опенкарт - ещё одна статья с примером описания "обычным языком" и diff-файлом. До сих пор считаете длинное описание более понятным, чем diff? Не перестаю удивляться таким заявлениям.

Git User&apos;s Survey 2011

- Posted in Uncategorized by

UPD: This survey is currently closed. More information can be found on http://git.wiki.kernel.org/index.php/GitSurvey2011


Все на выборы!

В смысле заполните анкетку: https://www.survs.com/survey/VCAGZA8CT5

Результаты наверное будут многим пользователям Git интересны.

Я по ходу дела узнал много новых букв названий интересного Git-софта.

Вывод Git branch в подсказку командной строки

- Posted in Uncategorized by

При активном использовании Git-а и переключений между разными ветками часто хочется видеть, в какой ветке находишься. Удобно добавить вывод названия branch-а в подсказку командной строки bash:

rb@rb-msi:~/projects/opencart-a4u (master)$ 

Для этого в ~/.bashrc находим строку, похожую на PS1='${debian_chroot:+($debian_chroot)}\u@\h:\w\$ ':

if [ "$color_prompt" = yes ]; then
    PS1='${debian_chroot:+($debian_chroot)}\[\033[01;32m\]\u@\h\[\033[00m\]:\[\033[01;34m\]\w\[\033[00m\]\$ '
else
    PS1='${debian_chroot:+($debian_chroot)}\u@\h:\w\$ '
fi

и изменяем (я закомментировал старую строку и добавил новую):

if [ "$color_prompt" = yes ]; then
    PS1='${debian_chroot:+($debian_chroot)}\[\033[01;32m\]\u@\h\[\033[00m\]:\[\033[01;34m\]\w\[\033[00m\]\$ '
else
    # PS1='${debian_chroot:+($debian_chroot)}\u@\h:\w\$ '
    PS1='${debian_chroot:+($debian_chroot)}\u@\h:\w$(git branch &>/dev/null; if [ $? -eq 0 ]; then echo " ($(git branch | grep '^*' |sed s/\*\ //))"; fi)\$ '
fi

Теперь при попадании в каталог внутри Git репозитория bash prompt будет показывать в скобках имя текущего branch-а, что выглядит примерно так:

rb@rb-msi:~/projects/opencart-a4u (master)$ 

UPD 2012-02-07: See also http://en.newinstance.it/2010/05/23/git-autocompletion-and-enhanced-bash-prompt/

Первичные настройки Git

- Posted in Uncategorized by

Представляемся надолго, чтобы коммиты не были ничейными:

git config --global user.name "Your Name Comes Here"
git config --global user.email you@yourdomain.example.com

Облегчаем визуальное восприятие изменений:

git config --global color.diff auto
git config --global color.status auto
git config --global color.branch auto
git config --global color.ui auto

Не забываем про заплетающиеся пальцы (вы способны быстро набрать "status" без опечаток?! Раз 50 в день?!?! Ого!):

git config --global alias.st status
git config --global alias.ci commit
git config --global alias.co checkout
git config --global alias.logd 'log --oneline --graph --decorate'
git config --global alias.logdm 'log --oneline --graph --decorate --no-merges'
git config --global alias.logn 'log --pretty=format:"%cd %C(auto)%h (%an) %s%+b%d" --date=short'
git config --global alias.logst 'log --stat=140,100'
git config --global alias.logf 'log --stat=140,100'
git config --global alias.bav 'branch -av'
git config --global alias.rv 'remote -v'
git config --global alias.diffw 'diff --word-diff'

Проделав это один раз, можно добавить в свой бекап файл ~/.gitconfig, в котором настройки и хранятся. Или скопируйте его в Дропбокс, а в домашнем каталоге оставьте симлинк на этот файл.

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

Если нужен gitk, то перед вторым запуском (первый под Линуксом нужен, чтобы слегка удивиться, проморгаться и взбодриться) исправьте в ~/.gitk интерфейсные шрифты:

set mainfont {{andale mono} 9}
set textfont {{andale mono} 9}
set uifont {clean 10 bold}
set tabstop 4

Хотя это в принципе и через GUI сделать можно.

Бекап, контроль изменений и откат на стабильные конфигурации &quot;/etc&quot; в Linux&apos;е с помощью Git

- Posted in Uncategorized by

Как говорят, если вас посетила гениальная мысль -- в линукс-сообществе это уже давно реализовано или создаётся.

Решил добавить /etc в Git-репозиторий, чтобы получить все плюшки контроля версий. И, разумеется, оказалось, что я не слишком оригинален :)

Более подробно для интересующихся и сомневающихся это уже подробно описано ранее Антоном Чернышовым в статье Управление каталогом /etc с использованием tar и git.

<

p>См. также:

Распробовал Git

- Posted in Uncategorized by

Распробовал Git: он действительно оказался во многом гораздо удобнее, чем SVN. В первый день мне не очень понравилась большая, чем в Subversion, атомарность действий и необходимость каждый раз добавлять изменённые файлы в коммит. Я понимал, что это сулит и чем может быть полезно, но сперва показалось неудобным: ты машина — ты и следи/добавляй, раз всё известно, зачем мне лишняя рутина? Позже у коммита обнаружился ключ -a вдобавок к "git add .", так что по этому поводу ворчать стало некуда. Ну а потом всё-таки понравился этот мелочный контроль (можно некоторые файлы держать у себя изменёнными для экспериментов и не пускать их в репозиторий).

Что нравится и заметно в первую очередь в Git после SVN, так это:

  1. деление на оффлайн и онлайн работу: здесь можно комфортно коммитить сколько угодно локально, затем слить всё пачкой из дома или из офиса. Мне как любителю работать с ноутбуком и нелюбителю зря переплачивать за мобильный трафик это очень удобно (хотя основная причина скорее быстрая разрядка батарей телефона при постоянном или частом использовании GPRS/EDGE/3G). См. также пункт 5 этого списка;
  2. служебных папок нет по всему дереву каталогов (как в SVN), есть только одна в корне проекта (репозитория). При работе с SVN приходилось перед массовой заливкой на сервер не забывать очищать дерево каталогов от этих .svn -- и места занимают прилично, да и не дело их на сервере держать. А если и держать, то надо не забывать блокировать через .htaccess. См. также пункт 5;
    • в SVN локальная рабочая копия очень жёстко привязана к абсолютному пути на диске, поэтому любая попытка скопировать или перенести папки внутри копии обычными средствами, а не командами SVN, гарантируют массу приключений и неприятных открытий;
  3. branch и merge устроены гораздо проще и логичней -- пользоваться ими хочется сразу же. В SVN они вроде бы тоже есть, но столько лишнего надо в голове держать, что писать километровые пути просто сил никаких нет. В итоге при работе в командах до десятка человек мы работали только с транком и пользовались буквально 3 командами: checkout первый раз и update/commit в процессе. Хватало. Но git branch -- это очень даже. Концепция и сценарии работы очень понравились, они гораздо удобней и при самостоятельной работе, и для 2 человек. Не говоря уже про более обширные команды;
  4. простота и удобство создания репозиториев: буквально зашёл в папку с проектом, git init && git add . && git commit -m 'initial commit' -- и вот у нас уже новый репозиторий. Не связанный пока никак с онлайн, но зато уже сразу можно работать с кодом, удобно следить за изменениями и пользоваться ветками. Процесс заведения репозиториев в SVN у меня был гораздо дольше, ну и онлайн в случае SVN обязателен, что для меня далеко не всегда плюс: иногда это здорово мешает. Так что я очень доволен этой разницей.
  5. служебные файлы SVN занимают столько же места, сколько и отслеживаемые, удваивая таким образом объём папки проекта (было 100 мегабайт - стало 200). Что с ветками - не знаю, не пользовался ими под SVN. Репозиторий Git'а раза в 2 с хвостиком МЕНЬШЕ отслеживаемого проекта. Из очень приятного: этот репозиторий (папку .git в корне проекта) очень легко сбекапить или перенести на другой компьютер, где его можно восстановить даже в глухой деревне без онлайна (git checkout master -- и из пустоты рядом с .git мгновенно возникает весь проект). См. также пункты 1 и 2.

Есть и существенный недостаток. При использовании Git каждый человек держит у себя всю копию репозитория. У нас при работе в Proxistep была актуальна проблема больших графических файлов. С ними в команде работал обычно один, от силы два человека: художник-дизайнер и верстальщик. И верстальщику в итоге нужна, условно говоря, всего одна картинка после всех согласований с клиентом. А дизайнеру совершенно не нужен код. А остальным разработчикам (3-4 человека) -- дизайн. Наблюдать и выкачивать все эти изменения и версии дизайна было неудобно и тяжело. Это тормозило и было большинству команды совершенно неинтересно, отнимало время, а в некоторых проектах - весьма заметное место на диске. К тому же обычным состоянием разработчика являлось участие в нескольких текущих проектах и часть недавних проектов тоже лежала в состоянии быстрой готовности.

Сейчас, конечно, полегче - скорости доступа к интернет заметно выросли и объёмы HDD растут год от года. Но иногда это может стать проблемой.

SVN в принципе способен частично решить эту проблему: в нём, в отличие от Git, можно делать checkout-ы и commit-ы отдельных папок репозитория, поэтому на первый взгляд достаточно всего лишь разумно разделить по каталогам работу. Проблема лишь в том, что некоторым ролям нужны разные наборы каталогов, и если кто-то оказался "на стыке", сделать одним коммитом изменения в 2 разных каталогах уже не получится: придётся видеть в общем репозитории 2 коммита вместо одного. Проблема на самом деле мелкая и скорее эстетическая, но на всякий случай стоит иметь в виду.

Для повседневной работы мне хватает с головой командной строки git'а и Meld для сравнения, но на всякий случай скажу про знакомые мне GUI инструменты для работы с Git:

  • RabbitVCS поддерживает и SVN, и Git;
  • Giggle гораздо приятнее глазу, чем gitk.

Полезные материалы для начинающих знакомство с Git:

  • Git - SVN Crash Course — для тех, кто мигрирует с SVN на Git; таблицы соответствия для быстрого старта и укладывания в голове аналогий
  • http://progit.org/book/ru/ — хороший перевод об устройстве и логике работы Git; кратко, последовательно и понятно, без "воды" и лирических отступлений
  • http://habrahabr.ru/blogs/development/68341/ — одна из самых понятных и кратких статей о правильной организации коллективной работы над проектами с использованием Git
  • http://help.github.com/git-cheat-sheets/
  • Git-SVN Comparison

И не забудьте про git-svn! Этот пакет даёт нам в распоряжение такую замечательную команду, как git svn clone <SVN_repo_URL> /path/to/git/repo, которая позволит создать Git-репозиторий из SVN-репо, сохранив всю историю коммитов. Безусловно полезная при миграции вещь.

Page 1 of 2