Git *

Git — штука не то чтобы особо сложная, но гибкая. Иногда эта гибкость приводит к забавным последствиям. К примеру, посмотрите на этот коммит на GitHub. Он выглядит как нормальный коммит, но если вы клонируете себе данный репозиторий, то такого коммита в нем не найдете. Потому что это потерянный коммит, более известный как git loose object или же orphaned commit. Под катом — немного про внутренности Git, откуда такое берется и что делать, если оно вам встретилось.

В нашем блоге мы уже рассказывали о принципах организации репозитория большого проекта как совокупности независимых модулей, что позволяет организовать извлечение исходных кодов в произвольную файловую структуру рабочей копии. Разумеется, такой подход не мог не отразиться на системе сборки проекта, поскольку потребовал создание механизма отслеживания зависимостей между модулями с учетом их фактического размещения. Эта статья посвящена тому, как можно использовать возможности git-а для решения не только этой задачи, но и для извлечения фрагмента проекта с автоматическим учетом внутренних межмодульных зависимостей.

И снова здравствуй, Хабр!

Неделю назад мы выпустили новую версию Upsource — инструмента для code review и навигации по репозиториям.

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

Без малого два года назад мы начали использовать в разработке нашего флагманского проекта СУБД ЛИНТЕР новую модель ветвления и управления подмодулями git-а. Десятки тысяч коммитов, сделанные за это время группой разработчиков, позволяют с определенной долей уверенности считать нововведения успешными. Эта статья — краткий обзор принципов организации хранилища исходных кодов в большом проекте на базе альтернативной реализации модулей git, сложившейся стратегии ветвления и инструментария linflow.

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

Мы решили, что подобные случаи достойны серии небольших статей под общим названием «Работа с сообщениями об ошибках».

И сегодня у нас подарок от всеми любимой программы git.
В очередной раз, сделав git pull на тестовый сервер, клиент увидел вот такое сообщение:

fatal: write failure on 'stdout': No space left on device

И обратился к нам с просьбой разобраться, почему это он не может на stdout писать

На данный момент (начало апреля 2015) «официальная» версия Git для Windows — 1.9.5, в то время как для всех остальных платформ уже доступна версия 2.3.5. Отсюда и естественный интерес к обновлению Git for Windows до актуальной версии или замене его на альтернативный дистрибутив.

После небольшого исследования были обнаружены следующие способы (дистрибутивы) использования Git на платформе Windows.

Убил пару дней на установку Gitolite. Вроде куча инструкций в интернете, и процесс-то глобально не сложный. Но ни в одной статье нет полного порядка команд, которые надо проделать, чтобы все это дело заработало без проблем.

Подразумевается, что читатель понимает, что такое git и gitolite и умеет с ними работать, рассматривается только вопрос установки.

Предлагаю вашему вниманию перевод небольшой статьи из блога Armin Ronacher — автора Flask, Jinja2 и много чего еще. На этот раз он поделится своими мыслями о Git — распределенной системе управления версиями файлов.

Git для меня интересная тема. Впервые я попробовал использовать Git, когда там не было вообще никакой системы команд, а Cogito считался многообещающим проектом. Не могу сказать, что мне это понравилось, в то время я в основном пользовался SVN, и он полностью решал все мои задачи. Вскоре я познакомился с Mercurial, и это была любовь с первого взгляда, положившая начало долгому и позитивному опыту использования этой VCS (version control system), которая получила в моем лице преданного сторонника. Только в 2008 году я перешел на Git, и мне потребовалось несколько попыток, прежде чем я понял, что пора переносить на него мои репозитории.

Пятница тринадцатое отличный день для очередного holywar обсуждения «как я готовлю Git, и почему я готовлю его неправильно».
Итак,

По следам моей первой публикации хочу сделать небольшую заметку об изменении файлов i386_defconfig или x86_64_defconfig, входящих в поставку исходников ядра Linux.

Здравствуйте!

Издательство «Питер» рассматривает возможность выпустить книгу по системе управления версиями Git.

Хотим посоветоваться с будущими читателями: какое издание вам будет наиболее интересно в русском переводе?
Мы сразу исключили книги ознакомительного уровня и выбрали три кандидатуры:

1. Новое издание (декабря 2014) книги Скотта Шакона



(Хотим сразу предупредить, что данная книга получится самой дорогой — розничная цена может достигать 1500 руб. Необходимо учесть это при принятии решения).

2. Классику от O'Reilly



3. Более краткое, но не сильно уступающее в информативности издание от Manning



Просьба голосовать:

Наткнулся сегодня на этот замечательный проект. Из файла README.md репозитория проекта:

Это игра для терминала, цель которой проверить ваш уровень знаний Git. Каждый уровень в игре — задание, которое необходимо выполнить в репозитории. После выполнения текущего задания вы получите следующее задание. Всего есть 10 уровней, которые возрастают по сложности!

Поехали!

Склонируйте репозиторий с помощью команды:

$ git clone https://github.com/hgarc014/git-game.git

Всем привет! Вот и наша компания решила завести блог на Хабре (в конце концов, не вечно же читать чужие статьи). В профиле компании вы можете посмотреть, чем мы занимаемся. В ближайшее время мы предложим вашему вниманию цикл статей по широкому спектру тем: от сервисов дистрибуции и поддержки тестовых сборок iOS приложений до программного управления IIS. А первая наша публикация посвящена Atlassian Stash.

На текущий день на хабре практически отсутствует какая бы то ни было информация об Atlassian Stash (всего один анонс и одна статья на тему установки). Хотя инструмент, на самом деле, прекрасный, и определенно стоящий рассмотрения в случае использования всего стэка Atlassian. Я хочу рассказать что это такое и как эту штуку можно добавить в процесс разработки.

Введение

При развертывании проектов основанных на модульных приложениях (например, Magento) сталкиваешься с тем, что в проекте сосуществует код, находящийся в различных репозиториях. PhpStorm вполне хорошо справляется с подобной ситуацией. Допустим, у нас есть основной проект, расположенный на Github'е, в котором используются один новый модуль, расположенный там же, и один legacy-модуль, расположенный в SVN-репозитории:

• основной проект: https://github.com/praxigento/z_git_submodules_main.git (Git)
• новый модуль: https://github.com/praxigento/z_mage_composer_mod_01.git (Git)
• legacy-модуль: https://github.com/praxigento/z_mage_composer_mod_02/trunk (Git as SVN)

Работать одновременно с несколькими git-репозиториями позволяет механизм git submodules, а PhpStorm также позволяет к этому добавить и SVN-репозиторий.

Обнаружена новая критическая уязвимость CVE-2014-9390 в Git, позволяющая выполнить произвольные команды на клиенте.

Суть уязвимости заключается в возможности совершить коммит в .Git/config, что равносильно служебному пути .git/config на регистронезависимых файловых системах. Это дает возможность инициировать запуск произвольных команд на клиенте. В общем случае уязвимости подвержены рабочие станции на Windows и Mac OS X, Linux-системы будут подвержены в случае использования регистронезависимых файловых систем.

Возможно, вы уже наслышаны, а если нет, то самое время узнать, что на днях мы выпустили первый официальный релиз Upsource.

Что такое Upsource?

Upsource — это инструмент для просмотра VCS-репозиториев, навигации по ним, а также для обсуждения и рецензирования кода (code review). Upsource предназначен для установки на собственном сервере компании и умеет работать с репозиториями Git, Mercurial, Subversion и Perforce.

В Java-проектах Upsource дополнительно осуществляет анализ кода аналогично тому, как это делает IntelliJ IDEA, а также предлагает знакомые по IDE функции Find Usages, Go to Declaration и Type Hierarchy.

Если помните, в августе мы анонсировали программу раннего доступа к Upsource, ну а сейчас дожили до релиза. Особо стоит отметить, что перед релизом мы обстоятельно подумали о лицензировании и ценах, и в итоге пришли к тому, что лицензия для небольших команд — до 10 пользователей (8 обычных пользователей, 1 гость и 1 администратор) — будет совершенно бесплатна. Для более крупных команд предлагается ряд коммерческих лицензий от 25 пользователей.

В декабре Perl празднует свой 27-й день рождения. А мы традиционно проводим приуроченный к этой славной дате очередной, шестой уже по счёту, Saint Perl. В этом году он состоится 20-21 декабря.

Доброго времени суток. Решил поделиться опытом в организации рабочего процесса разработки веб-проектов и не только веб. Расскажу свое видение максимально удобного использования связки типа: bugtraker + git + ci + deploy.



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

Предлагаю использовать Tor для доступа к сайтам, к которым отсутствует прямой доступ.

Навеяно публикацией «Github опять заблокирован».

Новость о блокировке гитхаба заставила задуматься об изготовлении костылей.

Почему-то сразу пришла в голову мысль об I2P.

И это действительно оказалось несложно.