Архив рубрики: git

Добавление существующего git-хранилища на GitHub

git

Иногда код, хранимый локально, дорастает до состояния, что его уже можно выложить на GitHub. Конечно же, с сохранением уже накопленной истории изменений. Если установлен gh — клиент для Гитхаба с интерфейсом командной строки, то решить такую задачу будет просто: достаточно зайти в каталог с существующим кодом, создать командой gh repo create новое GitHub-хранилище — оно автоматически будет указано в качестве удалённой ветки (remote branch) — после этого останется отправить всё наружу командой git push origin master (да, git всё-таки ещё главную ветвь называет мастером, а не main). То есть, достаточно всего двух команд.

path/to/code$ gh repo create slide-python --public -d 'Slides for Python classes'
? This will create 'slide-python' in your current directory. Continue? Yes
✓ Created repository shoorick/slide-python on GitHub
✓ Added remote git@github.com:shoorick/slide-python.git
path/to/code$ git remote -v
origin git@github.com:shoorick/slide-python.git (fetch)
origin git@github.com:shoorick/slide-python.git (push)
path/to/code$ git push origin master
Enumerating objects: 370, done.
Counting objects: 100% (370/370), done.
Delta compression using up to 4 threads
Compressing objects: 100% (368/368), done.
Writing objects: 100% (370/370), 832.24 KiB | 13.87 MiB/s, done.
Total 370 (delta 249), reused 0 (delta 0)
remote: Resolving deltas: 100% (249/249), done.
To github.com:shoorick/slide-python.git
[new branch] master -> master

Копирование с Gist на GitHub

git, screenshot, рабочее

Бывает, что мелкие фрагменты программного кода, заброшенные на Gist, со временем разрастаются до состояния, когда надо бы выделить им отдельное нормальное хранилище на Гитхабе — с багтрекером и остальными плюшками.

На https://gist.github.com/ishu3101/830b556b487de5d69690 нашёлся и был испытан на практике такой метод:

1. Создать новый репозиторий на Гитхабе.

2. Склонировать гист:

git clone git@gist.github.com:4b84d4a8d8404ede668225de68fb96ba.git

3. Переименовать получившийся каталог и зайти в него.

4. Добавить удалённый репозиторий (см. Pro Git 2.5 Git Basics — Working with Remotes, по-русски Основы Git — Работа с удалёнными репозиториями):

git remote add github https://github.com/username/repository-name

5. Отправить на Гитхаб:

git push github master

Но есть и более простой способ — импортировать через https://github.com/new/import

Импорт проекта на Гитхаб

Такой способ подходит, если надо всего лишь скопировать файл на Гитхаб и не заниматься дальнейшим его поддержанием в актуальном состоянии и на gist.github.com

Цветной Subversion

git, Perl, subversion

Git умеет «из коробки» раскрашивать то, что выводит в консоль, а Subversion — нет. Надоело руками каждый раз перенаправлять вывод svn diff в colordiff — написал простенькую раскрашивалку. Когда-то умела красить только вывод подкоманды status, теперь понимает blame (praise, annotate, ann), diff (di), help (?, h), status (stat, st) — и сами подкоманды, и их синонимы.

https://github.com/shoorick/svn-st-color

Инструменты разные — методы похожие

git, Perl, PHP, subversion, веб, тестирование

Попробовал решить одну из рабочих задач, применив нелюбимый язык PHP в комплекте с современными инструментами — получилось близко к тому, что делал сравнительно недавно на перле, с некоторыми отличиями:

  • Вместо  перла — PHP,
  • Модули тоже лежат рядом со своим кодом, но управляются не картоном, а через composer,
  • Композер и тесты может запустить (composer test), и отладочный сервер (composer start). Но можно для однообразия для обоих языков сделать Makefile и выполнять нужные действия командой make. Например, у меня запуск тестов — всегда make test, чтобы не путаться.
  • Вместо Mojolicious::Lite — микрофреймворк Slim. Для быстрого старта — Slim-Skeleton.
  • В шаблонах вместо Embedded Perl — Twig.
  • Если сайт работает через PHP-FPM, то нет нужды пинать демона каждый раз, как обновится код — он сам обрабатывает подобную ситуацию. Развёртывание свежей версии простого веб-приложения сводится к трём действиям: обновление рабочей копии (svn up либо git pull), разрешение зависимостей (composer install) и на всякий случай запуск тестов.

Слон и код

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

Собственные переводы интерфейса OJS

git, OJS, язык

Open Journal Systems — многоязычная система: многие её части могут быть переведены на разные языки. Не все, конечно: например, в материалах статей некоторые поля по странной прихоти разработчиков (или просто по невнимательности) остались одноязычными и добавить в них возможность правильно хранить данные на нескольких языках — не самая простая задача: я, например, так её и не завершил. В версиях 2.4.* нормальной многоязычности статей не будет — возможно, такое положение и объясняет тот факт, что в России OJS не особо популярна — она без применения напильника непригодна даже для тех журналов, где надо всего лишь продублировать имя русского автора статьи латинскими буквами.

С переводом интерфейса дела обстоят чуть получше: переведено может быть почти всё. Но и тут не всё гладко: вместо gettext применяется другой механизм локализации, где ключами служат не фразы на естественном языке (например, английском), а строки вида where.what.someItem. Переводы хранятся в XML-файлах, раскиданных по дереву каталогов. Впрочем, бо́льшая их часть сосредоточена в locale/ и lib/pkp/locale.

Есть два пути внедрения своих собственных переводов: первый, очевидный — отредактировать системные XML-файлы с переводами, плох тем, что при первом же обновлении OJS собственные переводы могут пропасть или вызвать конфликт слияния, если обновление проводится через git. Другой, более правильный — использовать плагин Custom Locale: он позволяет заменить системные переводы своими, не трогая системные файлы. Для того, чтоб заменить какой-либо фрагмент, надо знать ключ, а также файл, где перевод определён. Процесс замены переводов получается таким: сначала ищем, где и как определён нужный текст, затем идём на http://some-ojs-site/journal_name/manager/plugin/generic/customlocaleplugin/edit/ru_RU (если меняем русский текст), ищем в увиденном списке нужный файл, затем пытаемся найти в нём нужный ключ. Поиск там, вроде, есть, но, во-первых, ищет только в пределах текущего файла и умеет искать только точное соответствие с ключом — ничего более. Понятно, что такой интерфейс не нужен: лучше обходиться без него. Плагин хранит изменённые переводы в виде XML-файлов, которые складывает в public/journals/journal_id/customLocale/locale/path, где journal_id — номер журнала, locale — язык в виде язык_СТРАНА, например en_US — американский английский, а path — путь к заменяемым XML-файлам относительно каталога, где установлена OJS.

Пример: некий файл public/journals/1/customLocale/ru_RU/lib/pkp/locale/ru_RU/common.xml заменяет строки из файла lib/pkp/locale/ru_RU/common.xml:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE locale SYSTEM "../../../../../../../../../lib/pkp/dtd/locale.dtd">
<locale name="ru_RU">
	<message key="navigation.about">О журнале</message>
	<message key="navigation.setup">Настройка журнала</message>
	<message key="common.notApplicableShort"> </message>
</locale>

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