Git *

Команда Github продолжает радовать своими обновлениями, и на этот раз они приглашают нас попробовать полностью обновленный github:gist.

Для тех, кто не был знаком с этим сервисом ранее — Gist предназначен для обмена кусочками кода (и не только кода) между людьми. В основе Gist лежит система контроля версий git, что делает возможным коллективную работу над материалом, поддержку форков и версионности.

Gist успел стать незаменимым инструментом в арсенале Open Source сообщества. Например, таким простым образом распространяется перформанс-патч для руби, упомянутый недавно на хабре.

Проблема

Жена очень тщательно относится к выбору одежды. Цвет нарядов должен сочетаться с цветотипом внешности, чтобы подчеркнуть природные достоинства и скрыть недостатки. Правильно подобранный цвет освежает лицо, делает его ярким и выразительным. Поэтому пришла идея сделать сайт, на котором можно без особых усилий определить — какой цвет тебе «к лицу».

pickyourcolor.github.com

Rebase — один из двух способов объединить изменения, сделанные в одной ветке, с другой веткой. Начинающие и даже опытные пользователи git иногда испытывают нежелание пользоваться ей, так как не видят смысла осваивать еще один способ объединять изменения, когда уже и так прекрасно владеют операцией merge. В этой статье я бы хотел подробно разобрать теорию и практику использования rebase.

Теория

Итак, освежим теоретические знания о том, что же такое rebase. Для начала вкратце — у вас есть две ветки — master и feature, обе локальные, feature была создана от master в состоянии A и содержит в себе коммиты C, D и E. В ветку master после отделения от нее ветки feature был сделан 1 коммит B.

С сегодняшнего дня на Github появилась возможность создавать файлы прямо в репозитории, не уходя с сайта, и редактировать их содержимое.

Добрый день!

В статье я расскажу, как мы работаем с svn через git и почему не выбрали чистый git.

SVN

Subversion — это централизованная система контроля версий. Это главный ее минус и главный ее плюс :)

Плюс в том, что централизация дает возможность, например, нумеровать коммиты, т.к. их порядок известен.
Так же она минимизирует конфликты (хотя об этом можно и поспорить), т.к. текущее состояние репозитория одно и оно всем известно.
В svn можно хранить несколько проектов в одном репозитории. Вообще интефрейс репозитория в svn очень похож на файловую систему, что обеспечивает минимальный порог вхождения для тех, кто никогда не работал с системами контроля версий.

Главный минус — это merge… Те, кто часто делает мерж средствами svn, понимает о чем я.
Это медленно (даже меееееееедлееенно), требует постоянного соединения с репозиторием, а еще эти svn-properties, которые мешают читать diff.

Слово «Git» среди разработчиков, как правило, вызывает две диаметрально противоположные реакции. Один при его звуке начинает возбужденно делиться историями и опытом. Другой – говорит, что Git – это весьма опасный и сложный в изучении инструмент, вокруг которого в последнее время поднялась незаслуженная шумиха. Так кто же прав? Анализу этого вопроса и была посвящена встреча Git & Github в Киевском офисе EPAM Systems.

Git – это не только удобная распределенная VCS, но и инструмент подготовки релизов.
В статье будет рассмотрен flow на примере Java-проектов на Maven. Статья может быть полезна для разработчиков малых и средних команд, подразумеваются базовые знания git. Материал частично перекликается с git-flow, но здесь описан более простой вариант.
В классическом случае в репозитории существует одна ветка master, из нее же делаются сборки. Если проект собирается при этом на build-сервере, это может привести к беспорядку – несколько разных билдов под одной версией, не ясен набор коммитов, которые попадают в релиз (например, если сборка делается автоматически по триггеру на VCS).

В этой статье я расскажу, как создать групповую среду разработки сайтов через git с помощью git-хуков. Статья рассчитана на опытных системных администраторов, я лишь опишу алгоритм.
Многое на эту тему уже обсуждалось, а я добавлю, как автоматически создавать или удалять сайты при создании/удалении бранчей в git-репозитории. Такая возможность может пригодиться, к примеру, если над разными частями сайта работают разные программисты и нужны разные площадки (бранчи). После основной разработки и тестирования выполняется merge в основную ветку, а бранчи и тестовые сайты удаляются или архивируются.

Предисловие

Добрый день.

Вот уж, около полгода, наша компания перешла с системы контроля версий SVN на Git. О преимуществах или недостатках я писать не буду, их обсудили не раз. Ребята, которые этим занимались в нашей команде, написали несколько внутренних статей с основными сценариями: создание бранчей, мерджи и т.п.
Но жизнь преподносит свои сюрпризы и выход за основные сценарии всегда обозначался фразой WTF или говоря по русски «я думал Git сделает так, почему он сделал по другому?»

И всё сводилось к тому, что нужно читать документацию по Гиту. (А на чтение документации, всегда нет времени.)
По этому поводу была статья Завершён перевод книги «Pro Git» на хабре.
Но как оказалось, в документацию ещё вносятся изменения. Не часто, но всё же, тут хорошо видно, когда вносились последние.

И возникла идея слепить последний вариант доки…

В последнее время мои коллеги начинают знакомство с git'ом. И один из интересующих их вопросов — как откатиться до определённой ревизии. В интернете можно найти набор команд, но хочется, чтобы было понимание каждой из них. Баловство с комадами git'а без понимания может привести к потере истории разработки.

В этой статье я хочу рассказать о командах git checkout и git reset с ключами --soft и --hard.

Комманда git up (аналог svn up) добавляется так:

git config --global alias.up '!(git add . && git stash && git pull --rebase >&2) | grep -v "No local changes to save" && git stash pop'

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

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

Gitorious – open source альтернатива GitHUB, написан на RoR, использует ActiveMQ (в данном случае Stomp)
Установка производилась на свежеустановленный дистрибутив CentOS-6.2-x86_64-minimal. Все команды выполняются от root, там где нужен другой пользователь будет соответствующее указание.

Время на установку ~3 часа

Gitosis уже не поддерживается, и не за горами стабильный релиз Debian Wheezy, на котором его уже не будет. Поэтому было принято решение о миграции на gitolite. Не смотря на то, что есть соответствующий мануал, он не даёт ответа на вопрос — «Как это сделать и ничего не сломать?». Об этом сейчас и пойдёт речь.

Контекст

Предположим мы поддерживаем небольшой web-проект. У нас есть песочница для разработки с git'ом, отладчиками и прочими полезными вещами. Сайт уже запущен, и код скопирован из песочницы на удаленный сервер. Код приходится иногда (а возможно и частенько) обновлять и дорабатывать. Любые изменения естественно обкатать в песочнице. И тут возникает вопрос: как максимально просто и удобно обновить код на сервере?

Первым же решением, пришедшим в голову, оказывается простая команда git push: мы пушаем в удаленный репозиторий и получаем обновленную версию кода на сервере. Но не все так просто.

Точнее, на rackspace за то, что хостят гитхаб.

pdf'ка с заявлением в суд.

Среди истцов не только патентный тролль (некая Personalweb Technologies LLC), но ещё каким-то образом L3 communication (крупный ISP).

Цитата:

Rackspace has infringed and continues to infringe the ’791 patent by its manufacture, use, sale, importation, and/or offer for sale of the following products and services within the PersonalWeb Patent Field: Rackspace Cloud Servers and GitHub Code Hosting Service. Rackspace further contributes to and induces others to manufacture, use, sell, import, and/or offer for sale these infringing products and services. Rackspace is liable for its infringement of the ’791 patent pursuant to 35 U.S.C. § 271.

Список патентов:

Привет, Хабр!
Все программисты делятся на тех, кто использует систему контроля версий, и тех кто ещё ёё не использует. Одной из самых популярных на сегодняшний день, является git. И хотя его структура направлена на децентрализованное хранение данных, все мы пользуемся github, assembla, bitbucket или githost. Главный недостаток этих хостингов, в том, что это чужие проекты, которые в любой момент могут прикрыть ваш аккаунт или слить данные налево. И тут на сцене появляется GitBlit! Git сервер на Java, полностью контролируемый вами, с множеством плюшек и веб-интерфейсом. Сегодня будем запускать его на бесплатном хостинге от Redhat.

Что может быть лучшим подарком на день знаний для программиста? Конечно, полезная книга ;) Поэтому команда переводчиков «Pro Git» поднапряглась и доделала перевод книги на русский язык.

«Pro Git» — это довольно обширная обучающая книга о Git от Скотта Шакона — активного участника разработки проектов Git и GitHub. Автор рассматривает в тексте всевозможные аспекты работы с Git'ом, начиная с установки программы и базовых принципов работы децентрализованных систем контроля версий, и заканчивая рассмотрением внутреннего устройства Git'а и созданием валидных объектов в базе Git'а собственными руками. Несмотря на довольно обширный материал и затрагивание довольно специфических тем, книга написана довольно простым языком, содержит массу примеров и иллюстраций, и поэтому должна быть понятна и новичкам, только начинающим знакомиться с системами контроля версий.

Последняя версия перевода книги доступна в форматах pdf, epub, mobi.
Также доступна онлайн-версия перевода, но она, к сожалению, не обновлялась с мая.

Здравствуй, мой любознательный %username%!

Несколько месяцев назад я случайно наткнулся на еще одну перспективную систему управления версий — Veracity, о которой и хотел бы сегодня рассказать, чтобы тебе было что поковырять на выходных. Несмотря на то, что разработка Veracity идет уже больше года, на Хабре ее имя было лишь пару раз вскользь упомянуто в комментариях. Под катом тебя ждет краткое описание Veracity и ссылки, где можно получить более подробную информацию о ней.

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

Примечание. Многие описанные в этой статье команды Git выполняются автоматически при создании веб-сайта с помощью инструментов командной строки Windows Azure для Mac и Linux.

Выполните следующие действия:

• Установка системы Git
• Создание локального репозитория
• Добавление веб-страницы
• Включение репозитория веб-сайта
• Добавление веб-сайта в качестве удаленного репозитория
• Публикация и повторная публикация веб-сайта
• Устранение проблем

Установка Git

Действия по установке Git зависят от операционной системы. Сведения о конкретных дистрибутивах операционных систем и руководство по установке приведены в разделе «Установка системы Git».