По работе приходится участвовать в разных проектах, поэтому я хорошо знаю, как работают все мои коллеги. Помню, что компания начала использовать Git буквально за пару недель до моего прихода. На мониторах разработчиков кругом висели наклейки с напоминанием: сначала add, потом коммит, затем пуш.
Они не знали, зачем. Программистам просто сказали строго следовать инструкции, иначе беда. Но проблемы возникали так часто, что я решила провести семинар по Git.
Читать полностью »
Всем привет!
Итак, новая порция обещанного холивара про монорепозитории. В первой части мы обсуждали перевод статьи уважаемого инженера из Lyft (и ранее Twitter) о том, какие есть недостатки у монорепозиториев и почему они нивелируют почти все достоинства этого подхода. Лично я во многом согласен с доводами, приведенными в оригинальной статье. Но, как и обещал, чтобы поставить точку в этом обсуждении, я бы хотел озвучить еще несколько моментов, на мой взгляд даже более важных и более практических.
Читать полностью »
Мы рады представить релиз GitLab 11.6, в котором мы расширили возможности бессерверной архитектуры на GitLab и добавили групповые кластеры Kubernetes для упрощения работы с нативной облачной инфраструктурой.
Сегодня мы анонсируем два важных нововведения на GitHub, которые сделают его более доступным для разработчиков: неограниченные бесплатные приватные репозитории и более удобный продукт для компаний. Подробности под катом!
Эта новость опубликована на 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")
В общем, запасаемся попкорном, скрещиваем пальцы на ногах и ждём годноты!
От переводчика: Привет, Хабр! Да, это очередная статья о преимуществах и недостатках монорепозиториев. Собирался написать свою статью о том, как мы используем монорепозиторий, как мы переходили с maven на bazel и что из этого получилось. Но пока собирался с мыслями, вышла отличная статья от разработчика из Lyft, которую я и решил для вас перевести. Обещаю опубликовать свои дополнения к статье, а также опыт с bazel в виде продолжения.
Мы в Новом 2019 году, и я настроен на еще одну дискуссию о преимуществах (или отсутствии таковых) в хранении всего исходного кода организации в «Монорепозитории». Для тех из вас, кто не знаком с этим подходом, идея состоит в том, чтобы хранить весь исходный код в едином репозитории системы контроля версий. Альтернатива, конечно, заключается в том, чтобы хранить исходный код в нескольких независимых репозиториях, разделяя их обычно по границе сервисов/приложений/библиотек.
В данном посте я буду называть такой подход «полирепозиторий».
Читать полностью »
При наличии работоспособного NAS с докером, установка Gitlab не представляет особых сложностей.
В этой статье я расскажу об одном полезном, но малоизвестном приеме работы с git — как можно легко создать коммит, используя дерево из другого коммита. Проще говоря, как получить нужное состояние проекта на какой-либо ветке, если это состояние уже когда-то и где-то было в репозитории раньше. Будет приведено несколько примеров того, как это позволяет элегантно решать некоторые практические задачи. И в частности я расскажу о найденном мной методе, который позволяет значительно упростить исправление множественных конфликтов при rebase. Кроме того, эта статья — отличный способ понять на практике, что из себя представляет коммит в git-е.
Хочу поделиться результатами работы последних нескольких дней, которые включали в себя анализ git истории некоторых крупных Go проектов с целью нахождения коммитов, которые исправляли ошибки c последующей их формализацией для детектирования в случае их появления в новом коде.
Во второй части статьи рассмотрим некоторые новые диагностики в go-critic, которые позволяют находить код, который с высокой степенью вероятности содержит ошибку.
Часто у разработчиков возникает выбор между Merge (слияние) и Rebase (перемещение). В Гугле вы увидите разное мнение, многие советуют не использовать Rebase, так как это может вызвать серьезные проблемы. В статье я объясню, что такое слияние и перемещение, почему вы должны (или не должны) использовать их и как это сделать.
Git Merge и Git Rebase преследуют одну и ту же цель. Они предназначены для интеграции изменений из одной ветки в другую. Хотя конечная цель одинаковая, принципы работы разные.
Некоторые считают, что вы всегда должны использовать Rebase, другие предпочитают Merge. В этом есть свои плюсы и минусы.
Слияние — обычная практика для разработчиков, использующих системы контроля версий. Независимо от того, созданы ли ветки для тестирования, исправления ошибок или по другим причинам, слияние фиксирует изменения в другом месте. Слияние принимает содержимое ветки источника и объединяет их с целевой веткой. В этом процессе изменяется только целевая ветка. История исходных веток остается неизменной.Читать полностью »
