Рубрика «Git» - 14

в 6:37, , рубрики: Git, монорепозиторий, перевод, Системы управления версиями, управление разработкой

От переводчика: Привет, Хабр! Да, это очередная статья о преимуществах и недостатках монорепозиториев. Собирался написать свою статью о том, как мы используем монорепозиторий, как мы переходили с maven на bazel и что из этого получилось. Но пока собирался с мыслями, вышла отличная статья от разработчика из Lyft, которую я и решил для вас перевести. Обещаю опубликовать свои дополнения к статье, а также опыт с bazel в виде продолжения.

Мы в Новом 2019 году, и я настроен на еще одну дискуссию о преимуществах (или отсутствии таковых) в хранении всего исходного кода организации в «Монорепозитории». Для тех из вас, кто не знаком с этим подходом, идея состоит в том, чтобы хранить весь исходный код в едином репозитории системы контроля версий. Альтернатива, конечно, заключается в том, чтобы хранить исходный код в нескольких независимых репозиториях, разделяя их обычно по границе сервисов/приложений/библиотек.
В данном посте я буду называть такой подход «полирепозиторий».
Читать полностью »

в 9:06, , рубрики: data, data storage, diy или сделай сам, Git, git repositories, gitlab, NAS, protected git storage, repos, SAN, storage, storage system, контроль версий, репозитории, Системы управления версиями, хранилища данных

GitLab в NAS - 1

При наличии работоспособного NAS с докером, установка Gitlab не представляет особых сложностей.

Читать полностью »

в 6:35, , рубрики: commit, conflict, Git, merge, rebase, tree, Системы управления версиями

trees

В этой статье я расскажу об одном полезном, но малоизвестном приеме работы с git — как можно легко создать коммит, используя дерево из другого коммита. Проще говоря, как получить нужное состояние проекта на какой-либо ветке, если это состояние уже когда-то и где-то было в репозитории раньше. Будет приведено несколько примеров того, как это позволяет элегантно решать некоторые практические задачи. И в частности я расскажу о найденном мной методе, который позволяет значительно упростить исправление множественных конфликтов при rebase. Кроме того, эта статья — отличный способ понять на практике, что из себя представляет коммит в git-е.

Читать полностью »

в 19:54, , рубрики: bugs, Git, git log, Go, go-critic, go-lintpack, gocritic, golang, linter, lintpack, open source, static code analysis, Программирование, Совершенный код, управление разработкой

Путешествие gocritic'а в прошлое - 1

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

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

Читать полностью »

в 13:19, , рубрики: Git, merge, rebase, система контроля версий

Часто у разработчиков возникает выбор между Merge (слияние) и Rebase (перемещение). В Гугле вы увидите разное мнение, многие советуют не использовать Rebase, так как это может вызвать серьезные проблемы. В статье я объясню, что такое слияние и перемещение, почему вы должны (или не должны) использовать их и как это сделать.

image

Git Merge и Git Rebase преследуют одну и ту же цель. Они предназначены для интеграции изменений из одной ветки в другую. Хотя конечная цель одинаковая, принципы работы разные.

Некоторые считают, что вы всегда должны использовать Rebase, другие предпочитают Merge. В этом есть свои плюсы и минусы.

Git Merge

Слияние — обычная практика для разработчиков, использующих системы контроля версий. Независимо от того, созданы ли ветки для тестирования, исправления ошибок или по другим причинам, слияние фиксирует изменения в другом месте. Слияние принимает содержимое ветки источника и объединяет их с целевой веткой. В этом процессе изменяется только целевая ветка. История исходных веток остается неизменной.Читать полностью »

в 8:47, , рубрики: CD, ci, ci/cd, continuous delivery, continuous deployment, continuous integration, devops, Git, gitlab, open source, softmart, системы сборки, Системы управления версиями

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

Панель управления безопасностью в рамках группы

Разработчики уже давно используют GitLab как инструмент для обеспечения безопасности своего кода. Теперь GitLab дает больше прав и возможностей специалистам, отвечающим за безопасность, так что они могут использовать его для повышения безопасности приложений и обеспечения совместимости. С релизом 11.5, новая панель безопасности группы собирает воедино всю информацию, которая может потребоваться специалистам по безопасности, в удобном виде, разработанном специально для них. Эта панель содержит новые возможности отображения: общий обзор информации о безопасности разных проектов, а также углубленная информация о каждом из них. В 11.5 мы начинаем с отчетов SAST, в дальнейших релизах будем добавлять новые отчеты на эту панель. Наша цель — создать удобный инструмент, единую панель безопасности, которую специалисты по безопасности смогут использовать вместо переключения между множеством инструментов.

Читать полностью »

в 11:01, , рубрики: continuous delivery, continuous deployment, continuous integration, development process, devops, docker, Git, Блог компании TIMEWEB, управление разработкой, хостинг, хостинг-провайдеры

1 ноября 2017 года я стал руководителем рабочей группы разработки в отделе программных разработок Timeweb. А 12 ноября 2018 руководитель отдела спросил, когда же будет готова статья для Хабрахабр, потому что отдел маркетинга спрашивает, добровольцы кончились, а контент-план требует чего-то ещё)

Поэтому хочу дать ретроспективу, как менялись процессы разработки, тестирования и поставки наших продуктов в течение последнего года. Про унаследованные процессы и инструменты, docker, gitlab и то, как идёт у нас разработка.
Читать полностью »

в 7:27, , рубрики: commit, Git, Блог компании Яндекс, инструменты разработчика, Программирование, Разработка веб-сайтов, разработка мобильных приложений, разработка под windows

Как генерировать осмысленные коммиты. Применяем стандарт Conventional Commits - 1

Привычный хаос в названиях коммитов. Знакомая картина?

Наверняка вы знаете git-flow. Это отличный набор соглашений по упорядочиванию работы с ветками в Git. Он хорошо документирован и широко распространен. Обычно мы знакомы с правильным ветвлением и много говорим об этом, но, к сожалению, уделяем слишком мало внимания вопросу наименования коммитов, поэтому часто сообщения в Git пишутся бессистемно.

Меня зовут Ержан Ташбенбетов, я работаю в одной из команд Яндекс.Маркета. И сегодня я расскажу читателям Хабра, какие инструменты для создания осмысленных коммитов мы используем в команде. Приглашаю присоединиться к обсуждению этой темы.

Читать полностью »

в 14:07, , рубрики: 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) является наиболее популярным и мощным средством работы с поддеревьями.

Читать полностью »

в 14:04, , рубрики: CD, ci, ci/cd, continuous delivery, continuous deployment, continuous integration, devops, Git, gitlab, open source, softmart, системы сборки, Системы управления версиями

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

Мы рады представить новый релиз GitLab 11.4 с долгожданными обновлениями, призванными помочь командам работать эффективнее. Большинство команд, применяющих DevOps, стремятся к сокращению времени цикла поставки. Поэтому разработчики всегда рады улучшениям, которые уменьшат количество работы и потери во времени, так как за счет этого ускоряется поставка продукта и повышаются бизнес-показатели.

Читать полностью »

1...10...131415...2030...52
Главная   |  Архив новостей  |   Android  |   Google  |   Apple  |   Microsoft  |   Информационная безопасность  |   Веб – разработка
Публикации RSS  |  Комментарии RSS
https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js