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

Вне всяких сомнений, Pro Git — это одна из лучших книг про систему контроля версий git. Совсем недавно появилось второе издание этой замечательной книжки. Большие изменения произошли в издательском процессе: исходный код книги теперь хранится в AsciiDoc, а не в Markdown, а различные форматы (PDF, ePub и Mobi) автоматически генерируются с помощью O'Reilly Atlas platform. Разработка книги активно ведётся на гитхабе, актуальная online-версия находится в открытом доступе на официальном сайте, а любители печатной продукции могут заказать себе экземпляр на Amazon. Второе издание получилось почти в два раза больше первого: на сегодняшний день PDF-версия содержит 570 страниц. Помимо улучшения старого материала, книжка также пополнилась новыми главами и разделами:

Некоторое время назад при старте нового проекта было решено попробовать использовать Git вместо Subversion. Через некоторое время коллектив разделился на тех, кто любит Git (программисты), и тех, кто его ненавидит (дизайнеры и художники). Эксперимент по замене Subversion на Git провалился и на горизонте замаячила перспектива возвращения Subversion.

Почесав репу и содрогнувшись от связанных с Subversion воспоминаний мужики решили: «А что, мы же программисты!» и запилили свой Subversion с Git-ом и печеньками. Так родился проект git-as-svn.

Теперь мы можем использовать и Git, и Subversion с одним и тем же репозиторием. Причем доступ через Subversion напрямую использует данные Git-репозитория, в отличие, скажем, от SubGit, где для Subversion используется отдельный репозиторий.

Халява — студенческая богиня, к которой студенты взывают накануне экзамена, вместо подготовки к нему. Но несмотря на то, что сессия далеко, её величество халява может дать знать о себе даже сейчас и принести пользу. И речь в данном случае о инструментах доступных студентам бесплатно.

Продолжаем разговор о Fossil.

В первой части мы познакомились с использованием Fossil в однопользовательском режиме на одном рабочем месте. Следующий шаг — перенос репозитория на другой компьютер — с работы на домашний, или на ноутбук, который мы берем с собой в поездку. Самый простой вариант — это просто скопировать репозиторий, благо это всего один файл, на новое рабочее место. Можно так и сделать, но самое простое решение не всегда самое лучшее, есть вероятность, что возникнут небольшие проблемы.

Петр Лухин

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

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

Вступление

Я отработал 1,5 года в большой большой компании, которая занимается оптовыми и розничными поставками нефте-газового оборудования (оборот около 30ккк рублей). Внутри внедрена система управления (разработана на 1С), включающая несколько конфигураций для нескольких бухгалтерий, складов и т.д. Около 2к пользователей, работающих в системе ежедневно.

Поддерживает и развивает всю систему команда аналитиков. За это время у нас выработались правила, которые, по моему мнению, помогут всем аналитикам (бизнес, требований) и менеджерам, сотрудникам поддержки и даже немного разработчикам в крупном enterprise сегменте.

Приветствую вас, коллеги!

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

Какие системы контроля версий Вы используете (для собственных проектов и для работы)?

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

Многие опытные пользователи github-а знают, что отнюдь не для всего обязательно нужно использовать командную строку. Все это так.

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

Введение.

Продолжаю удивляться делиться опытом перехода из SVN на TFS (или как правильно подметили Team Foundation Version Control (TFVC)).
В предыдущем посте был описан опыт чисто системы управления версиями.
В этом посте я хотел бы поделиться маленьким (но важным) сценарием использования интеграции системы «контроля версиями» с системой «управления дефектами» (или как это называется Work Item Tracking).

Введение.

Не так давно один из проектов, в котором я участвую, перевели из SVN на TFS. Этот проект (десятки тысяч файлов, включая двоичные файлы) много лет жил и развивался под SVN. Поработав несколько месяцев после перехода, появился некий опыт, которым хочется поделиться.
Важно понять, что это опыт человека после SVN. Я использовал TortoiseSVN (плагин для Windows Explorer) и AnkhSvn — для Студии.

мои впечатления под катом

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

В текущей версии GitHub для Windows, мы сделали небольшое изменение, которое имеет едва заметный эффект, который вы, вероятно, уже заметили. Мы изменили подход к слиянию *.csproj и похожих файлов, используемый по умолчанию.
Если вы измените .csproj файл в ветке и затем объедините ее с другой веткой, то вы возможно столкнетесь с большим количеством конфликтов слияния, нежели вы могли иметь раньше.

Почему?

Итак, представим, что у нас девственно чистая система, в которой нет ни Putty, ни msysgit. Приступим к настройке нашего рабочего окружения.

Установка Putty

Качаем, устанавливаем, генерим и настраиваем ключ c Pagent (инструкция, ?).

Добавляем ключ на git-сервер

Открываем страницу с SSH ключами и добавляем из буфера наш ключ

Создаём и сохраняем в Putty профиль «git@github.com» и проверяем, что удаётся зайти по ключу – должна открыться и сразу закрыться консоль.

Устанавливаем и настраиваем msysgit

GitHub сегодня анонсировал запуск GitHub Developer Program, предназначенной для лучшего информирования разработчиков о происходящих изменения и коллективной работы над улучшением сервиса.



Члены GitHub Developer Program будут получать уведомления об изменениях в GitHub API, а также самый ранний доступ к новым функциям. У участников программы кроме того будет возможность запросить лицензию разработчика для GitHub Enterprise и размещать свои инструменты для рассмотрения на новой странице интеграции, также запущенной сегодня.

За несколько дней до наступления 2014 года Гитхаб успел перешагнуть отметку в 10 миллионов репозиториев. Причём больше половины из них — 5,5 миллиона — было создано в этом году. Гитхаб, несмотря на уже огромные размеры, продолжает расти экспоненциально. Если на создание первого миллиона репозиториев ушло три года и восемь с половиной месяцев, то последний миллион нарегистрировали за сорок восемь дней.

Разработка любого современного программного продукта не обходится без использования системы управления версиями программного кода (например, Subversion). Данный пост о том, что в некоторых случаях для успешного выпуска продукта одной только системы управления версиями становится недостаточно, и необходимо использовать некоторый инструмент для расширения ее функциональности.

Гладко было на бумаге

Разработчики имели разный опыт работы в нашем проекте Intel® Media SDK, и, как следствие, разное понимание рисков и последствий, которые несли их коммиты. Коммиты не тестировались разработчиками вовсе, или объем их тестирования был недостаточен.
Некоторые некорректные/не вовремя сделанные коммиты (например, ориентированные не на текущую, а на следующую версию продукта) приводили к появлению существенных (show stopper) ошибок на стадии, непосредственно предшествующей выпуску продукта. В условиях ограниченного временного ресурса разработчики испытывали немалые трудности в установлении причин их появления. Так как ошибки не могли быть исправлены немедленно, это приводило к сдвигу даты выпуска продукта.
Все это усложнялось еще и тем, что не всегда коммиты в системе управления версиями достаточно хорошо комментировались. Любые попытки изменить такое положение дел в нашем проекте были безуспешными.

Как решение вышеназванных проблем в нашем проекте был разработан CCB

От команды Гитхаба всё чаще слышны высказывания о том, что совместная разработка ПО — далеко не единственный сценарий применения их сайта. Сооснователь и CEO Гитхаба Том Престон-Вернер заявил недавно: «Мы хотим, сделать Гитхаб настолько гибким и простым, чтобы им могли пользоваться юристы, чиновники, кто угодно… Сейчас мы постоянно обсуждаем со множеством людей то, как они используют Гитхаб, и как ещё его можно использовать».

Уже есть несколько примеров использования Гитхаба не для разработки софта, а для написания книг, законов, публикации наборов данных. А 15 октября на Гитхабе открылся раздел government.github.com, специально предназначенный для проектов, связанных с электронным правительством, открытыми данными, гражданскими инициативами и законотворчеством. Список государственных учреждений, общественных организаций, правительств и муниципалитетов, использующих Гитхаб, уже насчитывает десятки наименований.

Вступительное слово

Считается, что «киллер фичей» СКВ Git является легковесное ветвление. Я ощутил это преимущество в полной мере, ведь я перешел на Git с SVN, где ветвление было достаточно дорогим процессом: для создания ветки нужно было скопировать весь рабочий каталог. В Git все проще: создание ветки подразумевает лишь создание нового указателя на определенный коммит в папке .git/refs/heads, который является файлом с 40 байтами текста, хешем коммита.

Основными командами пользовательского уровня для ветвления в Git являются git-branch, git-checkout, git-rebase, git-log и, конечно же, git-merge. Для себя я считаю git-merge зоной наибольшей ответственности, точкой огромной магической энергии и больших возможностей. Но это достаточно сложная команда, и даже достаточно длительный опыт работы с Git порой бывает недостаточным для освоение всех ее тонкостей и умения применить ее наиболее эффективно в какой-либо нестандартной ситуации.

Попробуем же разобраться в тонкостях git-merge и приручить эту великую магию.

Здесь я хочу рассмотреть только случай благополучного слияния, под которым я понимаю слияние без конфликтов. Обработка и разрешение конфликтов — отдельная интересная тема, достойная отдельной статьи. Я очень рекомендую так же ознакомиться со статьей Внутреннее устройство Git: хранение данных и merge, содержащей много важной информации, на которую я опираюсь.

GitHub — популярный сервис который позволяет осуществлять «социальную разработку», другими словами предоставляет веб-оболочку для Git и предоставляет бесплатный хостинг для вашего кода.

Но если у вас бесплатный аккаунт — то вы можете создавать только открытые репозитории, закрытые же доступны только для платных тарифов, либо для студентов.

О том как получить возможность создавать приватные репозитории мы и поговорим.