При наличии работоспособного NAS с докером, установка Gitlab не представляет особых сложностей.
Рубрика «Git» - 19
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, контроль версий, репозитории, Системы управления версиями, хранилища данныхКак и зачем красть деревья в 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 и то, как идёт у нас разработка.
Читать полностью »
Как генерировать осмысленные коммиты. Применяем стандарт Conventional Commits
2018-12-03 в 7:27, admin, рубрики: commit, Git, Блог компании Яндекс, инструменты разработчика, Программирование, Разработка веб-сайтов, разработка мобильных приложений, разработка под windows
Привычный хаос в названиях коммитов. Знакомая картина?
Наверняка вы знаете git-flow. Это отличный набор соглашений по упорядочиванию работы с ветками в Git. Он хорошо документирован и широко распространен. Обычно мы знакомы с правильным ветвлением и много говорим об этом, но, к сожалению, уделяем слишком мало внимания вопросу наименования коммитов, поэтому часто сообщения в Git пишутся бессистемно.
Меня зовут Ержан Ташбенбетов, я работаю в одной из команд Яндекс.Маркета. И сегодня я расскажу читателям Хабра, какие инструменты для создания осмысленных коммитов мы используем в команде. Приглашаю присоединиться к обсуждению этой темы.
Git subtree в деталях
2018-11-07 в 14:07, admin, рубрики: Git, git hooks, git-receive-pack, git-subrepo, githooks, github, pre-receive, Системы управления версиямиПринимая решение об использовании того или иного средства в собственных проектах, инженеру приходится не только изучать сопроводительную документацию, но и проводить серию экспериментов для того, чтобы избежать потенциальных проблем в будущем. Если же речь идет о CM-политике, рассчитанной на длительную перспективу, цена ошибки выбора становится достаточно высока.
Целью настоящей работы является практическое изучение средства управления поддеревьями Git.
Начиная с ревизии 1.7.11 upstream-репозиторий Git, в каталоге contrib/subtree, содержит средство автоматизации работы с поддеревьями.
Сервис git-subtree(1) фактически является полезной надстройкой, использующей функции git-read-tree(1) и git-write-tree(1). Поэтому ссылки в командах git-subtree(1) add/pull/push:
git subtree add --prefix=<subdir> <remote> <ref>
могут представлять собой, как имена веток, так и имена тегов удаленного репозитория.
Кроме того, если заранее добавить удаленный репозиторий в конфигурационный файл локального репозитория .git/config, с помошью команды:
bash-4.4$ git remote add build-system ../../remote/build-system.git
где build-system является именем удаленного репозитория ../../remote/build-system.git, то в дальнейшем, при использовании команд git-subtree(1) add/pull/push, мы сможем ссылаться на upstream-репозиторий remote/build-system.git по имени.
На данный момент git-subtree(1) практически не развивается, а лишь поддерживается в актуальном состоянии для текущей степени развития проекта Git.
Однако git-subtree(1) является наиболее популярным и мощным средством работы с поддеревьями.
Вышел GitLab 11.4 с ревью мерж-реквестов и подключаемыми фичами
2018-11-06 в 14:04, admin, рубрики: CD, ci, ci/cd, continuous delivery, continuous deployment, continuous integration, devops, Git, gitlab, open source, softmart, системы сборки, Системы управления версиями
Мы рады представить новый релиз GitLab 11.4 с долгожданными обновлениями, призванными помочь командам работать эффективнее. Большинство команд, применяющих DevOps, стремятся к сокращению времени цикла поставки. Поэтому разработчики всегда рады улучшениям, которые уменьшат количество работы и потери во времени, так как за счет этого ускоряется поставка продукта и повышаются бизнес-показатели.
Git Subrepo
2018-11-01 в 11:01, admin, рубрики: Git, git-subrepo, github, Системы управления версиямиПроект git-subrepo существует достаточно давно, однако упоминаний о нем незаслуженно мало. Автором git-subrepo является Ingy döt Net.
Если посмотреть на историю комитов master-ветки проекта, то может показаться, что проект остановился в развитии 2 года назад. Однако работы над проектом ведутся и хочется надеяться, что скоро будет выпущена версия 0.4.0.
Важным свойством данного средства является то, что на стороне пользователя нет необходимости устанавливать git-subrepo до тех пор, пока пользователь не решит делать комиты в upstream-репозитории подпроектов. Кроме того, пользователь получает полностью готовое и настроенное дерево исходного кода в момент копирования основного репозитория посредством стандартной команды git-clone(1).