Привет, Хабр. Решил затронуть измученную во многих статьях тему, конкретнее – описать во многом нестандартное (я бы сказал, несорцовое) использование систем контроля версий (далее – СКВ). Товарищи программисты, давайте спрячем тухлые помидоры и пройдем мимо, ибо данная статья – не для вас. Да, все вы уже изучили все тонкости работы Git, SVN, CVS и знаете много других умных слов. Позвольте же и нам, простым смертным, ознакомиться со всеми преимуществами использования СКВ.
Приглашаю под кат всех желающих ознакомиться с СКВ, а также всех тех, кто, так или иначе, имеет дело с быстроменяющимися данными.

Много лет подряд в качестве системы контроля версий для большого количества проектов использовали только SVN. Но наступил момент, когда количество разработчиков на одном из проектов заметно увеличилось, проект уже запущен в работу, и нужно как активно разрабатывать параллельно несколько фич, так и фиксить уже имеющиеся баги в оперативном режиме. Единый trunk в SVN не позволяет этого делать, а организация бранчей в нем же превращает жизнь разработчиков в ад. Поэтому было принято решение о переезде этого проекта с SVN на Git.

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

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

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

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

Установка Git

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

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

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

По роду своей деятельности я нередко становлюсь свидетелем «священных войн» между коллегами-программистами на тему, какую же систему контроля версий выбрать для того или иного проекта. Роль системы контроля версий особо остро ощущается в случаях разработки и поддержки проектов с длинной историей. Вариантов инструментов много, но я хочу сконцентрироваться на двух, на мой взгляд, наиболее перспективных: Mercurial и Git. Далее попробуем рассмотреть возможности обеих систем с позиции их внутреннего устройства.

В этой статье я хотел бы поделиться своими впечатлениями от использования Atlassian Bamboo — системы непрерывной интеграции от компании Atlassian. В Java-проекте, над которым мы работаем, изначально в качестве системы управления использовалась JIRA On Demand, т.е. облачная версия JIRA, установленная на серверах компании Atlassian. В определенный момент появилась необходимость внедрения системы непрерывной интеграции. Важным требованием при выборе такой системы была поддержка из коробки системы автоматической сборки Gradle. Подобному требованию удовлетворяло лишь несколько систем непрерывной интеграции: всем известный Jenkins, Jetbrains TeamCity и Atlassian Bamboo. Под катом изложено как это работает и почему же мы выбрали Atlassian Bamboo. Осторожно — много картинок!

Доброго времени суток уважаемые хабражители. Буквально только что увидел потрясающий проект на GitHub от FredrikNoren.

Ungit:

• Чистый и интуитивно понятный интерфейс для Git (что есть невероятно круто для освоения Git)
• Работает на любой платформе с установленными Node.js и самим Git
• Веб-ориентированный. Возможность запускать его в облаке.
• GitHub

Необходим Node.js версии 0.10 или выше и npm версии 1.3.1 или выше

Установка

npm install -g ungit

Я думаю, что после просмотра видео, моего более тщательного описания не потребуется. Спасибо всем за внимание.

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

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

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

В этой серии статей мы рассмотрим процесс размещения инфраструктуры для разработки в облаке InfoboxCloud. Для удобного развертывания стека приложений будем использовать Docker.

В первой статье развернем Gitlab, включающий в себя:

• веб-интерфейс для системы управления исходными текстами git, максимально похожий на GitHub
• удобный просмотр активностей пользователей
• браузер файлов
• Wiki
• возможности проведения Code Review
• баг-трекер
• возможность создания сниппетов кода
• возможность вставки web hooks
• билд-сервер

и многое другое.



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

Имеем следующую ситуацию:

В проекте присутствует файл super.config. В нем содержатся много разных настроек проекта. Например, конфигурация взаимодействия со сторонним сервисом и уровень логирования. Система контроля версий — git.

В чем проблема:

1. Этот файл должен находиться под версионным контролем, так как в нем содержатся «общие» настройки. Ну и сама структура файла ценна.
2. Каждый разработчик меняет уровень логирования под свои нужды и не хочет, чтобы эти изменения попадали в коммиты, и тем более в интеграционный репозиторий.
3. В этом файле периодически меняются общие настройки, и разработчик хочет их получать (pull) и публиковать (commit)

Приветствую,

Поиск по архивам Хабра показал, что о Perforce Helix почти ничего не писали, а в рунете доступна только обзорная статья про расширение для VS и перевод англоязычной старенькой статьи Dear Perforce: fcuk you. При этом в комментариях к статье, посвящённой используемым системам контроля версий, Perforce часто упоминали, поэтому мне захотелось опубликовать пару обзорных статей по функциональности Perforce Helix, которые возможно кому-то помогли бы разобраться в данной платформе, то есть исключительно для информационной составляющей.

В числе самых обсуждаемых последних новостей в сообществе разработчиков были новые тарифы GitHub (см., например, здесь).

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

Некоторые прибегают к альтернативному решению и разворачивают GitLab (или другой git-сервис) на собственном или арендованном сервере.

Но и у этого решения есть свои подводные камни: GitLab очень требователен к системным ресурсам. Для частных лиц гораздо проще платить 7 долларов в месяц за GitHub, чем арендовать сервер надлежащей конфигурации.

Из сказанного, однако, не следует, что у GitHub на сегодняшний день альтернативы нет. Об одном весьма интересном и перспективном решении мы хотели бы рассказать в этой статье. Знакомьтесь: Gogs. Этот инструмент будет интересен как для индивидуальных разработчиков, так и для небольших компаний.

Вне зависимости от масштаба вашего проекта, ваш инструментарий должен:

а. быть удобным в работе
б. давать полезную обратную связь.

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

Все вы знаете систему Git. Хотя бы слышали — это наверняка. Разработчики, которые пользуются системой, ее или любят, или ругают за сложный интерфейс и баги. Система управления версиями Git де-факто является стандартом в индустрии. У разработчика могут быть мнения о преимуществах Mercurial, но чаще всего приходится мириться с требованием уметь пользоваться Git. Как у любой сложной системы, у нее множество полезных и необходимых функций. Однако, до гениальной простоты добираются не все, поэтому существующая реализация оставляла пространство для совершенствования.

Простыми словами — мудреным приложением было трудно пользоваться. Поэтому в лаборатории Массачусетского Технологического Института взялись за улучшения и отсекли все «проблемные элементы» (ведь то, что для одного проблема, для другого легко может быть преимуществом). Улучшенную и упрощенную версию назвали Gitless. Её разрабатывали с учетом 2400 вопросов, связанных с Git и взятых с сайта разработчиков StackOverflow.

Команда авторов вычленила самые проблемные места в Git, включая две концепции staging и stashing. Затем они предложили изменения, призванные решить известные проблемы.

Автор материала рассказывает об устройстве системы управления версий, которая реализована в компании Stripe.



Когда дело доходит до API, изменения — вещь непопулярная. В то время как многие разработчики ПО привыкли к работе в режиме частых и быстрых итераций, разработчики API теряют эту гибкость как только у них появляется хотя бы первый пользователь их интерфейса. Многие из нас знакомы с историей эволюции операционной системы Unix.

В 1994 году была издана книга «Настольное пособие Unix-ненавистника» (Unix-Haters Handbook), в которой затрагивался целый список самых разных острых тем, от имен оптимизированных под телетайпы команд с совершенно непонятной историей происхождения до необратимого удаления данных, непонятных интуитивно программ с избытком опций. Более 20 лет спустя, подавляющее большинство этих жалоб по-прежнему актуальны несмотря на все многообразие доступные сегодня систем-наследников и ответвлений. Unix стал настолько широко популярен, что изменение его поведения может привести к далеко идущим последствиям. Хорошо это или плохо, но между ним и его пользователями уже сложились определенные договоренности, определяющие поведение Unix-интерфейсов.

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

Несколько дней назад сотрудники компании Google и Центра математики и информатики в Амстердаме представили первый алгоритм генерации коллизий для SHA-1. За десять лет существования SHA-1 не было известно ни об одном практическом способе генерировать документы с таким же хешем SHA-1 и цифровой подписью, как в другом документе, но теперь такая возможность появилась.

Хеш-функция SHA-1 используется повсеместно, поэтому известие о генерации документов с идентичным хешей вызвало естественную обеспокоенность у пользователей. В том числе у пользователей системы управления версиями Git, в которой тоже используются хеши SHA-1. Развёрнутый ответ на эти опасения дал Линус Торвальс. Если вкратце, то бояться нечего.

Введение

Здравствуйте, уважаемые читатели. Сегодня на повестке дня у нас небольшое тестирование —
первых ≈100 тысяч по популярности сайтов в интернете (ранжирование на основе статистики посещаемости с Alexa Rank). Стоит отметить, что оное тестирование будет достаточно узконаправленным, а именно — проверим каждый сайт на предмет существования и открытости Git-репозитория без аутентификации прямо из веба по url-адресу искомого. Напомню, что такая брешь в безопасности зачастую позволяет прочитать актуальные исходные коды на сервере, получить чувствительную информацию (файлы конфигов, структуру системы и т.д.) и, в последствии, получить определенного рода права на сервере. Рай для различного рода негодяев, да и только :)
Совершенно аналогичную проверку я делал для себя порядка 100 дней назад, и сегодня мы сделаем это ещё раз, посмотрим что изменилось и что с этим делать.
Разумеется, использовать будем список сайтов, полученный в рамках первого тестирования.
Для заинтересовавшихся милости прошу под кат.