Git *

Дарова, хабр! (ничего оригинальнее не придумал)

Сомневаюсь что эта заметка тянет на полноценный пост, но я все же оставлю ее здесь. О чем же пойдет речь?

Все мы слышали о Git. Все мы знаем что он — хорош. Но лишь немногие пытаются что-то с ним делать, как-то его протвикерить. Сразу говорю, тут не будет ничего паранормального, только немного работы с файлом .gitconfig. Да-да, именно с тем файлом, который так трепетно пылится у вас в домашней директории.

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

Доброго времени суток!

Вряд ли сейчас можно найти IT-ишника, который не слышал о системе управления версиями Git и популярном хостинге GitHub. Многие активно её используют как в продакшене, так и для хранения личных наработок и велосипедов. Совсем недавно в их блоге была опубликована статистика за 2012 год.

В процессе перехода с SVN на Git мы столкнулись с необходимостью переписывания наших внутренних инструментов, связанных с развёртыванием кода, которые ориентировались на существование линейной истории правок (и разработку в trunk). На Хабре уже публиковались возможные решения этой проблемы через Git-SVN, но мы пошли другим путём. Нам нужна поддержка таких возможностей Git, как branching и merge, поэтому мы решили разобраться в основах, как же работает 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.

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