В составе Midnight Commander, помимо всем известного редактора mcedit, есть не менее замечательная утилита для сравнения файлов «бок о бок» (side-by-side) — mcdiff. В ней можно сравнивать и при необходимости производить полное или частичное слияние в обе стороны.
Историю появления утилиты mcdif когда-то уже рассказывал тут но ближе к делу…
Установка указанного продукта достаточно проста. Но я всё таки нашёл для себя грабли.
Отчасти это было связано с тем, что ставил я на CentOS. С этим дистрибутивом я до недавнего времени опыта почти не имел.
Фактически данная статья это вольный перевод Getting Started руководства с сайта Atlassian в разделе установки в Linux.
Возможно кому то пригодится.
Читать полностью »
Выходные окончились, и к нам возвращается прежний настрой на внедрение новых функций Гитхаба. Исходя из желания зрелищно начать 2014 год, сегодня мы с удовольствием запускаем аналитику посещаемости!
Теперь вы сможете видеть подробные проанализированные сведения о посещениях тех репозиториев, которыми владеете или в которых можете напрямую помещать код (push). Просто зайдите на страницу графиков конкретного репозитория — и увидите новую ссылку, ведущую на страницу «Traffic».
![[Traffic]](https://www.pvsm.ru/images/predstavlyaem-analitiku-poseshaemosti-githaba.png "Представляем аналитику посещаемости Гитхаба")
Прежде, чем начать свой рассказ, задам один маленький вопрос: Как вы разворачиваете свои проекты сервере?
Если вами управляется один маленький сайтик на бесплатном виртуальном хостинге, то проблемы синхронизации у вас не возникают — подключился по ftp, скопировал файлы и все. А если нужно контролировать развертывание нескольких сотен проектов (от маленьких сайтов визиток до нагруженных приложений), над которыми трудится не один десяток людей? Если позволяет квалификация, то можно использовать rsync, unison и др. Особо отчаянные могут просто обновлять рабочую копию проекта (svn, git и тд.) из репозитория. А что будут делать десятки художников, которым срочно нужно поправить вот ту маленькую картинку? Ведь для многих из них консоль — волшебный темный дремучий лес.
Под катом описание одного решения, позволяющего сильно упростить процесс развертывания приложений.
Читать полностью »
За несколько дней до наступления 2014 года Гитхаб успел перешагнуть отметку в 10 миллионов репозиториев. Причём больше половины из них — 5,5 миллиона — было создано в этом году. Гитхаб, несмотря на уже огромные размеры, продолжает расти экспоненциально. Если на создание первого миллиона репозиториев ушло три года и восемь с половиной месяцев, то последний миллион нарегистрировали за сорок восемь дней.
Читать полностью »
Никогда не был фанатом gitk и пользовался им редко, предпочитая консоль и настроенные алиасы. Благодаря читательу grossws, я открыл для себя tig. Это то, чего мне не хватало. После месяца использования его в работе хочу поделиться находкой с вами.
Tig это консольный GUI(TUI) для Git, основанный на Ncurses.
Основные преимущества:
Cкриншоты основных режимов и сравнение с gitk.
Читать полностью »
Здравствуй Хабр!
Совсем недавно в нашей компании проходил очередной Хакатон. И в его рамках мне захотелось убить время поинтересней сделать полезную вещь, как для себя так и для других разработчиков. Выбор пал на этакий валидатор sql кода, который бы проверял его на разные правила что не под силу компилятору и те что могут пропустить ребята которые делают Code Review. Таких правил можно придумать массу, начиная от простого “Добавлять GO в конце запроса” и заканчивая более сложными “Использовать View вместо Table”. И самое главное, этот валидатор никоим образом не должен добавлять время разработчику на его использование, т.е. попросту говоря, он должен валидировать себе где-то автоматически, вне зависимости от действий разработчика.
Так уж исторически сложилось, что весь sql-код перед тем как выйти в продакшн (т.е. исполнится на основной БД) сохраняется у нас в GIT репозитории, куда попадает напрямую от разработчиков (естественно после Code Review). Так вот, возникла идея добавить git-hook в этом репозитории который бы валидировал sql-код и если он не валидный то коммит бы возвращался разработчику на доработку. Немного тяжело представить, легче нарисовать:
Эта статья в первую очередь пригодится тем, кто использует тот же стек технологий, что и наша команда, а именно: ASP.NET, C#, NUnit, Selenium 2, git, MSBuild. Будут рассмотрены такие задачи, как интеграция с git, сборка C#-проектов, NUnit-тесты (как модульные, так и тесты UI), а также деплой на сервер. Впрочем, наверняка найдётся интересное и для других пользователей, кроме разве что съевших на этом вопросе собаку. Но они опять же смогут обратить внимание на ошибки в статье или что-то посоветовать: например, как оптимизировать фазу деплоя.
Читать полностью »
Некоторое время назад, сервис GitHub ананонсировал возможность использовать эмоциональные иконки Emoji во всей своей GFM-разметке.
Мало кто знает, что эмоциональные иконки можно использовать не только в комментариях к pull requests и issues, но и в commit messages!
Читать полностью »
К моему удивлению на целом хабрахабре нет ни одного поста где бы было понятно написано про 3 вида git reset. Например, во второй по релевантности статье по запросу «git reset» автор пишет что «данное действие может быть двух видов: мягкого(soft reset) и жесткого(hard reset)». Режим --mixed, используемый по умолчанию, почему-то не удостоился упоминания.
Ничего удивительного, что часто видишь непонимание работы этой команды. Под катом коротко и ясно расскажу о всех трёх режимах git reset, после прочтения топика неясностей остаться не должно.
Читать полностью »
