Системы управления версиями *

Fog Creek – компания созданная Джоелом Спольски и, возможно, известная вам по продукту Trello, на прошлой неделе представила свой новый проект державшийся долгое время в тайне: Kiln Harmony. Это хостинг Mercurial (hg) и git репозиториев. К сожалению, исключительно платный, есть только 45 дней пробного периода. В чём же новость, спросите вы, если Mercurial + git хостинги уже есть на рынке и, в том числе, бесплатные, как Bitbucket.org? Особенность Kiln Harmony в том, что один репозиторий на хостинге одновременно является и Mercurial и git репозиторием! По заявлениям разработчиков великий холивар закончен и теперь вы можете соредоточиться на кодинге, а не на выборе системы контроля версий. Push и pull в единый репозиторий размещённый на Kiln Harmony из вашей любимой системы контроля версий (Mercurial или git) не требует установки отдельных расширений, типа hg-git, или других особых телодвижений, вся магия происходит на сервере.

Удалённый репозиторий и система управления проектами

Компания Assembla предоставляет удобный сервис для удалённого хранения репозиториев, их управлением, и управлением проектами, к которым они относятся.

Предисловие

Всем доброго времени суток. Наткнулся на хабре на топик, в котором просят посоветовать хорошие удалённые гит репозитории. К сожалению на хабре я недавно (зарегистрировался конечно же, его посетителем являюсь уже очень давно), так что в комментарии ответить не смог (read-only). Вот и подумал — посоветую в отдельном топике, заодно, сделаю небольшой обзор дополнительных возможностей сервиса, который предоставляет эту возможность. Кстати, там можно создавать не только Git, а так же и другие (например SVN) репозитории. Так, хватит предисловия — к делу.

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

Переименование файлов

Теперь при редактировании файла можно указать новое имя.

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

Вступление

Как справедливо заметил Fred Brooks, серебряной пули, способной поразить зверя разработки программного обеспечения, не существует. Пока возникают новые требования, идеи и находятся новые баги, программы живут и изменяются. Путь, который проходит код от версии к версии, может быть крайне сложен и извилист. К его созданию причастно много людей: разработчики, тестировщики, бизнес-аналитики, заказчики и т.п. Несмотря на то, что существует много разных видов разработки – аутсорсинг, продуктовая разработка, open-source и т.п., проблемы, стоящие перед командой, остаются примерно одинаковыми. Программное обеспечение – вещь сложная, потребитель хочет получить его как можно быстрее (и дешевле). Качество при этом должно быть приемлемым. Перед командой разработки стоит серьезная задача – наладить эффективное взаимодействие. Одним из самых главных средств коллаборации внутри команды разработчиков является сам код, который они пишут.

Некий Питер Коттл (Peter Cottle) сделал интерактивную обучалку по основам ветвления в Git. Есть несколько простых обучающих уровней, где нужно сделать пару коммитов, а затем merge или rebase, есть и сложные уровни, над которыми придется подумать. Можно также сохранять уровни и делиться ими с друзьями.

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

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

В среду, 23 января, Github запустил новый, значительно переработанный и улучшенный поиск кода, репозиториев и разработчиков. Теперь инфраструктуру обеспечивает кластер серверов ElasticSearch, который индексирует весь добавляемый код на лету, заметно переработан интерфейс, и, самое главное, есть много функциональных улучшений.

Добрый день.

Хочу поделиться способом подстановки в код 1С 7.7 номера ревизии и других значений из рабочей копии SVN.
Реализовать нижеописанное навеяло статьей, автору выражаю благодарность за вдохновение.

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

Прочитав статью
«Простой релиз-менеджмент средствами Git»
захотелось поделиться парой своих мыслей по поводу релиз-менеджмента maven проектов.

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

В кратце: главная проблема релиз-менеджмента maven проектов — это сам maven, который, не был разработан с учетом требований CI (Continuous Integration) подхода к разработке ПО.
Парадигма SNAPSHOT версий устарела с тех пор, как CI стало стандартным подходом к разработке ПО.

Более подробно далее.

Добрый день!

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

SVN

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

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

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

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

 

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

Bitbucket — это хостинг для Mercurial и Git репозиториев. Ближайший аналог и прямой конкурент — github. По популярности Bitbucket отстаёт, однако у него есть пара заметных фич по сравнению с github — это поддержка Mercurial и возможность создать сколь угодно приватных репозиториев на бесплатном аккаунте, однако дать доступ можно максимум пяти пользователям (у github вообще нет приватных репозиториев для бесплатных аккаунтов).

Сегодня команда Bitbucket выпустила большое обновление своего сервиса. Полностью обновился дизайн и добавилось много новых функций. Сделаю краткий обзор нововведений на основе записи в официальном блоге команды разработчиков.

Было разработано расширение Caché Studio, которое называется Caché-SVN. Это расширение позволяет работать с репозиторием (хранилищем) SVN, не покидая Caché Studio. С его помощью можно выполнять checkout, commit и update.

Caché-SVN работает не с отдельными файлами (классами, программами, csp-страницами и т.д.), а с проектом целиком.

Caché-SVN создаёт временную папку на сервере, где установлено Caché, выгружает туда файлы проекта и выполняет svn commit. Аналогично при svn update полученные xml-описания файлов импортируются в Caché.

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

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

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

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

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

На хабре уже было много статей о распределенных системах управления версиями (DVCS), их сравнений, а также сравнений GUI-клиентов для них. Также были обсуждения плагинов к IDE для работы с git и mercurial. Но практически не было информации об инструментах визуального сравнения и разрешения конфликтов слияния.


Недавно я «перескочил» с mercurial (который до сих пор считаю более удобным и логичным) на git, потому что, подавляющее большинство проектов, которые мне интересны, используют git и хостятся на github. В связи с этим, встал вопрос о пересмотре арсенала инструментов, в частности вопрос выбора инструмента визуального сравнения и слияния (diff and merge). Дабы восполнить недостаток информации на хабре, я решил написать этот мини-обзор. Как говориться — по горячим следам.

Под катом Вы также найдете примеры настроек Git для использования с DiffMerge и WinMerge под Windows. Думаю многим сэкономит время.