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

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

В мае этого года вышел релиз ГитЛаба 8.8. Частью этого релиза был запуск встроенного Docker Container Registry. Ниже перевод майской статьи, посвященной этому.

Недавно нами был выпущен GitLab версии 8.8, в которой поддержка CI стала еще лучше. Теперь в GitLab можно строить конвейеры (pipelines) для визуализации сборок, тестов, развертывания и любых других этапов жизненного цикла вашего ПО. Сегодня мы представляем вам следующий этап: GitLab Container Registry .

GitLab Container Registry — это безопасный приватный реестр для образов (images) Docker, разработанный с помощью ПО с открытым кодом. GitLab Container Registry полностью интегрирован в GitLab.

Ключевыми особенностями GitLab являются непрерывность процесса разработки и взаимная интеграция различных элементов; эти принципы сохраняются и при работе с нашим реестром. Теперь при помощи GitLab Container Registry вы можете использовать ваши Docker-образы для GitLab CI, создавать специальные образы для отдельных тегов и веток, а также многое другое.

Стоит отметить, что GitLab Container Registry является первым реестром Docker, полностью интегрированным в систему управления Git-репозиториями. Кроме того, GitLab Container Registry не требует отдельной установки, так как является частью GitLab 8.8; c его помощью можно легко скачивать и загружать образы на GitLab CI. И еще он бесплатный.

Для того, чтобы узнать, как включить использование GitLab Container Registry, обратитесь к документации для администратора.

Эта статья — перевод релизной статьи компании GitLab. Релизы выходят каждый месяц 22 числа.

Если вы пропустили предыдущие, вот ссылки: 8.10, 8.9, 8.8

---

В новом GitLab 8.11 столько всего интересного, что мы с трудом сдерживаем себя в рамках конструктивного повествования!

Итак, в новой версии появились:

• принципиально новый новый способ представления и работы с тикетами (issues);
• слеш-команды (/command) для работы с тикетами;
• возможность создавать шаблоны тикетов (в неограниченном количестве);
• онлайн-среда разработки;
• возможность разрешать конфликты мержа не выходя из GitLab;
• настройка прав на пуш в ветку для отдельных участников и групп (только в ЕЕ);
• … и много других фич, о которых мы тоже расскажем.
  

Всем привет, если вы не в курсе, мы начали публиковать переводы релизных статей ГитЛаба.
Если вы пропустили предыдущие, вот ссылки: 8.10, 8.9, 8.8

ГитЛаб выпускает релизы 22 числа каждого месяца.
Перевод поста про релиз 8.11 в работе, а пока представляю на ваш суд еще одну статью из блога ГитЛаба про различие терминологии у GitLab, GitHub и Bitbucket.

---

В зависимости от рабочих задач и потребностей клиентов разработчикам приходится использовать разные платформы управления репозиториями. Типичный разработчик участвует в каком-нибудь открытом проекте на GitHub, а на работе хостит проект одного клиента на GitLab, а другого — в Mercurial и на Bitbucket. Переключения между платформами осложняются тем, что в них одни и те же вещи могут называться совершенно по-разному. В этой статье мы поможем вам сопоставить различия и заодно объясним, почему мы выбрали именно такие названия.

Начиная с версии 8.4 в GitLab значительно улучшился процесс миграции репозиториев из GitHub. Теперь GitLab импортирует не только репозитории, но ещё и вики-страницы, тикеты и пулл-реквесты. При этом большинство сущностей не меняют своего названия. Например, специфические термины Git, такие как commit или push, везде одинаковы. Не меняются и такие общие термины, как users, webhooks и issues.

Привет, мне показалось хорошей идеей начать переводить не только релизные посты из блога ГитЛаба. Для разминки я взял этот пост почти наугад, так что не судите строго. Буду рад, если поможете определиться с выбором статьи для перевода, выбрав один из вариантов в опроснике

---

Git – это система контроля версий с огромным количеством возможностей. Пытаться изучить их все довольно утомительно, поэтому большинство пользователей ограничивается использованием лишь базового набора команд. В этой статье представлены несколько советов по работе с Git, о которых вы, возможно, не знали. Эти советы помогут вам оптимизировать ваш процесс разработки.

Всем привет. В этот раз задержка с переводом релизного поста получилась всего 10 дней, и это радует.
Переводом в этот раз занимался chebureque, за что ему большая благодарность!

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

Сам текст перевода:

---

Основная задача GitLab — позволить вам как можно быстрее пройти путь от идеи до готового к использованию продукта. Каждый наш релиз направлен на то, чтобы сделать этот путь еще проще, и версия 8.10 особенно преуспела в этом!

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

Наш июльский (MVP) — Winnie! Он очень сильно помог нам, исправляя баги и наводя порядок в нашем issue tracker-е.

Github — важная часть жизни современного разработчика: он стал стандартом для размещения opensource-проектов. В «2ГИС» мы используем гитхаб для разработки проектов web-отдела и хостинга проектов с открытым кодом.

Хотя большинство из нас пользуются сервисом практически каждый день, не все знают, что у него есть много фишек, помогающих облегчить работу или рутинные операции. Например, получение публичного ключа из URL; отслеживание того, с каких сайтов пользователи приходят в репозиторий; правильный шаринг ссылок на файлы, которые живут в репозиториях гитхаба; горячие клавиши и тому подобное. Цель этой статьи — рассказать о неочевидных вещах и вообще о том, что сделает вашу работу с гитхабом продуктивнее и веселее (я не буду рассматривать здесь работу с API гитхаба, так как эта тема заслуживает отдельной статьи).

Содержание

• Трюки с URL
• Горячие клавиши
• Тикеты и пулл-реквесты
• Github markdown
• Аккаунт
• Работа с репозиториями
• Поиск кода
• Командная строка и Github
• User scripts
• Github-вандализм
• Дополнительные Github-ресурсы
• Полезные ссылки

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

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

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

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

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

Думаю, нет нужды рассказывать хабрапользователю что такое Git / GitHub, pre-commit и как наносить ему hook справа. Перейдем сразу к делу.

В сети много примеров хуков, большинство из них на shell'ах, но ни один автор не уделил внимание одному важному моменту — хук приходится таскать из проекта в проект. На первый взгляд — ничего страшного. Но вдруг появляется необходимость внести изменения в хук, который уже живет в 20 проектах… Или внезапно нужно переносить разработку с Windows на Linux, а хук на PowerShell'е… Что делать? ??????? PROFIT…

«Лучше так: 8 пирогов и одна свечка!»

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

• выполнять проверку отправляемого в репозиторий кода на валидность (например: соответствие требованиям PEP8, наличие документации итд);
• выполнять комплексную проверку проекта (юнит-тесты итд);
• прерывать операцию commit'а в случае обнаружения ошибок и отображать подробный журнал для разбора полетов.

И выглядел приблизительно так:

python pre-commit.py --check pep8.py --test tests.py

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

Немного истории

В самом начале 2010 года Vincent Driessen пишет отличную статью A successful Git branching model. Для понимания того, о чем пойдет речь дальше, со статьей нужно, конечно же, познакомиться. А для тех, кому сложен язык оригинальной статьи, на хабре есть её отличный перевод.

С этого момента описанная модель ветвления GitFlow, начинает, что называется, расходиться по миру. Её берут на вооружение многие команды. Авторы пишут много статей об успешном её использовании. Она получает поддержку в большинстве инструментов, которые используют разработчики:

• Плагин к самому Git'у
• Плагины к различным IDE: IDEA, Eclipse
• Встроенная поддержка в GUI клиентах: SourceTree и Git Extensions
• Плагины для систем сборки: Maven, Gradle, и т.д.
• Встроенная поддержка в менеджерах репозиториев: GitHub, BitBucket, GitLab и т.д.

Кажется, что модель идеальна. Быть может так оно и есть, если у вас небольшая команда, неизменяемый скоуп релизов, высокая культура работы с VCS. Тогда, действительно, GitFlow может и удовлетворит все ваши потребности. Но, к сожалению, описанные условия подходят не всем командам и не всем проектам. К слову, найти статьи, в которых бы авторы описывали проблемы этой модели не так уж и просто даже в 2016 году. Но как мы все знаем, серебряной пули нет, а, значит, и в этой модели всё хорошо далеко не для всех.

Теперь платить нужно за число пользователей, а не приватные репозитории

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

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

С ростом компании меняются люди и проекты. Не так давно в блоге GitHub появилась интересная статья, в которой автор рассказывает, как делать, а как лучше не делать Pull Request’ы. Перевод, традиционно, спрятан под катом.

Вышел новый Git 2.8.0! В течение пары последних недель, когда релиз был в стадии кандидата, я прошёлся по списку коммитов и заметок к нему, пробуя новые вещи и отмечая интересные моменты. Чтобы сохранить ваше время, предлагаю субъективную выборку фич, которые стоит попробовать. Пользуйтесь!

Краткий вариант push -d, синоним push --delete

Это отличное дополнение как для полноты множества опций, так и для скорости набора команд. Возможно, вы уже используете git branch -d, чтобы удалять локальную ветку, а теперь можно так же сократить команду удаления remote-ветки до git push -d.

git branch -d my-branch       # удаляет локальную ветку, если она уже слита
git push -d origin my-branch  # удаляет remote-ветку в origin-репозитории

Доброго времени суток.
Я работаю Ruby разработчиком в стремительно растущей IT-компании. И вот однажды нами было принято стратегическое решение смены сервиса для работы с Git. Всех, кому интересно, прошу под кат.

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


Скала Улуру в Австралии как пример монолита — КДПВ, не более

Что такое монорепозиторий?

Определения разнятся, но мы будем считать репозиторий монолитным при выполнении следующих условий:

• Репозиторий содержит более одного логического проекта (например, iOS-клиент и веб-приложение)
• Эти проекты могут быть не связаны, слабо связаны или связаны сторонними средствами (например, через систему управления зависимостями)
• Репозиторий большой во многих смыслах:
  
  • По количеству коммитов
  • По количеству веток и/или тегов
  • По количеству файлов
  • По размеру содержимого (то есть размеру папки .git)

С удовольствием делюсь новостью, которая, надеюсь, порадует некоторых читателей Хабра: в Bitbucket Server вот-вот появится возможность поиска по коду. Буквально на днях вышел релиз по программе раннего доступа (EAP).

Начну с вольного перевода обращения менеджера продукта, опубликованного в блоге Atlassian:

Как часто это случалось с вами: вы видите сообщение об ошибке, но не знаете, в какой части кода она происходит, или вам известно название функции, но не репозиторий, в коде которого она определена. Многие из вас просили добавить в Bitbucket Server поиск по коду, и я рад сообщить, что ваше ожидание подошло к концу. Сегодня мы приглашаем наших пользователей опробовать поиск по коду в Bitbucket Server через программу раннего доступа (EAP). Теперь вы можете искать и находить нужный код с помощью строки поиска:

Исследователь информационной безопасности Лаел Целлье (Laël Cellier) обнаружил две критические уязвимости в клиенте и серверной части Git (CVE-2016-2324 и CVE‑2016‑2315).

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

Один из принципов дизайна в Atlassian — лаконичность. В ходе эволюции UX некоторые непопулярные действия, расчитанные на опытных пользователей, были спрятаны в выпадающих списках или за горячими клавишами. Там они ждут предприимчивого пользователя, который случайно наткнётся на них благодаря случайному нажатию клавиш или клику мышки (ну, или заглянет в руководство). Вот шесть моих любимых трюков Bitbucket Cloud, о которых вы, возможно, никогда не слышали:

Омнибар

Омнибар в Bitbucket — это строка быстрого доступа к действиям, похожая на ⇧⇧ в средах разработки JetBrains или ⌘+P в Sublime Text. Запустить омнибар можно на любой странице, нажав клавишу точки.

По умолчанию, он покажет набор действий, соответствующих текущему контексту:

Меня зовут Оксана Харчук, я работаю QA-инженером в DataArt чуть больше года. Расскажу, как в нашем проекте организован процесс работы, и как быть, если релиз каждый день.

Сначала, когда я только пришла в DataArt, слово «релиз» ассоциировалось у меня с чем-то страшным. Но, как оказалось, если процесс работы построен правильно, релизы даже каждый день — совсем не страшно, а очень даже удобно.Чтобы этого достичь, процесс разработки в нашем проекте построен на принципах непрерывной поставки (continuous delivery) и непрерывной интеграции (continuous integration).

Что такое Continuous delivery и Сontinuous integration?

Continuous delivery или непрерывная поставка ПО — набор практик и принципов, нацеленных на сборку, тестирование и поставку ПО быстрее и чаще. Непрерывная поставка качественного кода опирается, в свою очередь, на непрерывную интеграцию.

Сontinuous integration, или непрерывная интеграция — это практика разработки ПО, которая заключается в выполнении частых автоматизированных сборок проекта для скорейшего выявления и решения интеграционных проблем. Ведь ясно: если над разными частями кода работают несколько программистов, при интеграции этих частей возникает много трудностей. Непрерывная интеграция помогает справиться с ними.

Несколько дней назад David Demaree, главный по Typekit в Adobe, издал крутую книжку "git для людей". Чтобы привлечь к ней внимание, он опубликовал выжимку самой, на мой взгляд, интересной главы — как оформлять коммиты чтобы и волки были целы, и овцы сыты, и песец не пришел. А я за эти выходные подготовил выжимку из выжимки — сокращенный и адаптированный перевод, чтобы можно было быстро прочитать и добавить в копилку своего опыта самое ценное.