Мы рады представить релиз GitLab 11.6, в котором мы расширили возможности бессерверной архитектуры на GitLab и добавили групповые кластеры Kubernetes для упрощения работы с нативной облачной инфраструктурой.
Рубрика «Git» - 18
Вышел GitLab 11.6 с бессерверными функциями и кластерами Kubernetes для групп
2019-01-09 в 13:48, admin, рубрики: CD, ci, ci/cd, continuous delivery, continuous deployment, continuous integration, devops, Git, gitlab, open source, softmart, системы сборки, Системы управления версиямиНовый год, новый GitHub: неограниченные бесплатные приватные репозитории
2019-01-08 в 14:11, admin, рубрики: 2019, Git, github, microsoft, Блог компании Microsoft, Программирование, Системы управления версиямиСегодня мы анонсируем два важных нововведения на GitHub, которые сделают его более доступным для разработчиков: неограниченные бесплатные приватные репозитории и более удобный продукт для компаний. Подробности под катом!
Бесплатные аккаунты на GitHub смогут [почти] без ограничений работать с приватными репозиториями
2019-01-07 в 18:52, admin, рубрики: Git, github, Блог компании JUG.ru Group, Программирование, Системы управления версиямиЭта новость опубликована на The Next Web, с пометкой:
"Из-за ошибок в планировании, мы опубликовали эту новость на день раньше снятия эмбарго на разглашение. Фича всё ещё не запущена, о ней официально расскажут завтра. Когда это произойдёт, мы обновим пост новым официальным анонсом".
А ещё есть вот такой замечательный тред в Twitter:
![Бесплатные аккаунты на GitHub смогут [почти] без ограничений работать с приватными репозиториями - 1](https://www.pvsm.ru/images/2019/01/07/besplatnye-akkaunty-na-GitHub-smogut-pochti-bez-ogranichenii-rabotat-s-privatnymi-repozitoriyami.jpeg "Бесплатные аккаунты на GitHub смогут [почти] без ограничений работать с приватными репозиториями - 1")
Ясно, что человек писал это дрожащими руками — точно так же, как я сейчас пишу дрожащими руками этот перевод.
Фейк ли это? Нет. Есть и официальное подтверждение в твиттере GitHub, так что — назад дороги нет.
Фичу явно выкатывали на спех, до сих пор на сайте не поправлена часть текстов, касающихся тарифов, а попытка даунгрейднуть план встречает таким вот опасно выглядящим сообщением:
![Бесплатные аккаунты на GitHub смогут [почти] без ограничений работать с приватными репозиториями - 2](https://www.pvsm.ru/images/2019/01/07/besplatnye-akkaunty-na-GitHub-smogut-pochti-bez-ogranichenii-rabotat-s-privatnymi-repozitoriyami-2.jpeg "Бесплатные аккаунты на GitHub смогут [почти] без ограничений работать с приватными репозиториями - 2")
В общем, запасаемся попкорном, скрещиваем пальцы на ногах и ждём годноты!
Монорепозитории: пожалуйста не надо
2019-01-07 в 6:37, admin, рубрики: Git, монорепозиторий, перевод, Системы управления версиями, управление разработкойОт переводчика: Привет, Хабр! Да, это очередная статья о преимуществах и недостатках монорепозиториев. Собирался написать свою статью о том, как мы используем монорепозиторий, как мы переходили с maven на bazel и что из этого получилось. Но пока собирался с мыслями, вышла отличная статья от разработчика из Lyft, которую я и решил для вас перевести. Обещаю опубликовать свои дополнения к статье, а также опыт с bazel в виде продолжения.
Мы в Новом 2019 году, и я настроен на еще одну дискуссию о преимуществах (или отсутствии таковых) в хранении всего исходного кода организации в «Монорепозитории». Для тех из вас, кто не знаком с этим подходом, идея состоит в том, чтобы хранить весь исходный код в едином репозитории системы контроля версий. Альтернатива, конечно, заключается в том, чтобы хранить исходный код в нескольких независимых репозиториях, разделяя их обычно по границе сервисов/приложений/библиотек.
В данном посте я буду называть такой подход «полирепозиторий».
Читать полностью »
GitLab в NAS
2018-12-30 в 9:06, admin, рубрики: data, data storage, diy или сделай сам, Git, git repositories, gitlab, NAS, protected git storage, repos, SAN, storage, storage system, контроль версий, репозитории, Системы управления версиями, хранилища данных
При наличии работоспособного NAS с докером, установка Gitlab не представляет особых сложностей.
Как и зачем красть деревья в git
2018-12-20 в 6:35, admin, рубрики: commit, conflict, Git, merge, rebase, tree, Системы управления версиями
В этой статье я расскажу об одном полезном, но малоизвестном приеме работы с git — как можно легко создать коммит, используя дерево из другого коммита. Проще говоря, как получить нужное состояние проекта на какой-либо ветке, если это состояние уже когда-то и где-то было в репозитории раньше. Будет приведено несколько примеров того, как это позволяет элегантно решать некоторые практические задачи. И в частности я расскажу о найденном мной методе, который позволяет значительно упростить исправление множественных конфликтов при rebase. Кроме того, эта статья — отличный способ понять на практике, что из себя представляет коммит в git-е.
Путешествие gocritic’а в прошлое
2018-12-11 в 19:54, admin, рубрики: bugs, Git, git log, Go, go-critic, go-lintpack, gocritic, golang, linter, lintpack, open source, static code analysis, Программирование, Совершенный код, управление разработкой
Хочу поделиться результатами работы последних нескольких дней, которые включали в себя анализ git истории некоторых крупных Go проектов с целью нахождения коммитов, которые исправляли ошибки c последующей их формализацией для детектирования в случае их появления в новом коде.
Во второй части статьи рассмотрим некоторые новые диагностики в go-critic, которые позволяют находить код, который с высокой степенью вероятности содержит ошибку.
Введение в Git Merge и Git Rebase: зачем и когда их использовать
2018-12-07 в 13:19, admin, рубрики: Git, merge, rebase, система контроля версийЧасто у разработчиков возникает выбор между Merge (слияние) и Rebase (перемещение). В Гугле вы увидите разное мнение, многие советуют не использовать Rebase, так как это может вызвать серьезные проблемы. В статье я объясню, что такое слияние и перемещение, почему вы должны (или не должны) использовать их и как это сделать.
Git Merge и Git Rebase преследуют одну и ту же цель. Они предназначены для интеграции изменений из одной ветки в другую. Хотя конечная цель одинаковая, принципы работы разные.
Некоторые считают, что вы всегда должны использовать Rebase, другие предпочитают Merge. В этом есть свои плюсы и минусы.
Git Merge
Слияние — обычная практика для разработчиков, использующих системы контроля версий. Независимо от того, созданы ли ветки для тестирования, исправления ошибок или по другим причинам, слияние фиксирует изменения в другом месте. Слияние принимает содержимое ветки источника и объединяет их с целевой веткой. В этом процессе изменяется только целевая ветка. История исходных веток остается неизменной.Читать полностью »
Вышел GitLab 11.5 с панелями управления для операторов и специалистов по безопасности и контролем доступа GitLab Pages
2018-12-06 в 8:47, admin, рубрики: CD, ci, ci/cd, continuous delivery, continuous deployment, continuous integration, devops, Git, gitlab, open source, softmart, системы сборки, Системы управления версиями
Панель управления безопасностью в рамках группы
Разработчики уже давно используют GitLab как инструмент для обеспечения безопасности своего кода. Теперь GitLab дает больше прав и возможностей специалистам, отвечающим за безопасность, так что они могут использовать его для повышения безопасности приложений и обеспечения совместимости. С релизом 11.5, новая панель безопасности группы собирает воедино всю информацию, которая может потребоваться специалистам по безопасности, в удобном виде, разработанном специально для них. Эта панель содержит новые возможности отображения: общий обзор информации о безопасности разных проектов, а также углубленная информация о каждом из них. В 11.5 мы начинаем с отчетов SAST, в дальнейших релизах будем добавлять новые отчеты на эту панель. Наша цель — создать удобный инструмент, единую панель безопасности, которую специалисты по безопасности смогут использовать вместо переключения между множеством инструментов.
Ретроспектива автоматизации и изменений в процессах разработки Timeweb
2018-12-05 в 11:01, admin, рубрики: continuous delivery, continuous deployment, continuous integration, development process, devops, docker, Git, Блог компании TIMEWEB, управление разработкой, хостинг, хостинг-провайдеры1 ноября 2017 года я стал руководителем рабочей группы разработки в отделе программных разработок Timeweb. А 12 ноября 2018 руководитель отдела спросил, когда же будет готова статья для Хабрахабр, потому что отдел маркетинга спрашивает, добровольцы кончились, а контент-план требует чего-то ещё)
Поэтому хочу дать ретроспективу, как менялись процессы разработки, тестирования и поставки наших продуктов в течение последнего года. Про унаследованные процессы и инструменты, docker, gitlab и то, как идёт у нас разработка.
Читать полностью »