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

Этот текст — перевод релизного поста из блога ГитЛаба. Перевод подготовлен компанией Softmart. Мы понимаем, что наш перевод далек от идеала, но считаем что даже такой перевод будут полезен многим, кто не владеет английским языком в достаточной мере. Иван Немытченко — nem — евангелист ГитЛаба по мере возможности редактирует текст. Если вы готовы предложить свою помощь в переводе статей, будем только рады. Спасибо за понимание!

С GitLab 8.9 комфортнее работать в больших сложных проектах. Блокировка файлов, назначение приоритетов меткам, гибкие настройки уровня вовлеченности в проект, и возможность запретить объединение веток(merge) до момента, пока билд не выполнится успешно. В GitLab CI теперь можно указывать среды(production, staging, и т.д.) и задавать срок хранения артефактов. Появились шаблоны настроек CI, так что начать им пользоваться теперь еще проще.

Персона месяца(MVP) — Руи Сантос. Он разработал возможность ограничивать обьединение веток до прохождения билда. Спасибо Руи!

С версии 8.8.0 добавилось 1761 коммитов, 1947 файла были изменены. Что конкретно изменилось — смотрите ниже.
Читать полностью »

Gogs: легковесный git-сервис - 1

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

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

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

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

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

9 ¾ действительно полезных советов по работе над крупными проектами - 1
Я предпочитаю работать в маленьких командах: до 10 человек. Всех участников команды ты знаешь лично, чаще всего не нужно специально «бронировать время», чтобы обсудить что-то и принять решения.

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

  1. Более 50 проектов в solution’е. Назначение не всех из них вы знаете
  2. Билд и выкладка длятся более 5 минут
  3. Над кодом работают десятки или сотни человек в разных офисах (возможно и странах)
  4. Существует четкое разделение труда и область ответственности каждой команды
  5. Существуют строгие регламенты, стандарты оформления кода, прохождение ревью является обязательным критерием выполнения задачи
  6. Учет рабочего времени производится позадачно, анализируются причины расхождения оценок и реальных трудозатрат

Бюрократия в этом случае – необходимое зло, тем ни менее, действующее на нервы. Чтобы избежать потерь драгоценных клеток я советую сразу подготовиться к тому, что придется поменять свой привычный workflow. Хорошая новость состоит в том, что, переучившись, вам не составит труда поступать также и на небольших проектах. Скорее всего, ваши коллеги будут приятно удивлены такой педантичностью
Читать полностью »

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

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

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

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

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

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

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

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

Уменьшаем размер публикуемых npm модулей - 1По умолчанию npm публикует в registry весь модуль целиком. За исключением явно указанных в .gitignore файлов. Это отбрасывает зависимости, но все равно позволяет куче не очень нужных файлов просочиться в опубликованное. После чего благодарные пользователи ждут, пока все это скачается. Для grunt, кстати, ждать придется порядка 6 мегабайт. А он такой обычно не один.

Я решил разобраться, как измерить размер своих модулей после публикации и, по возможности, этот размер уменьшить. В качестве примера буду использовать модуль check-more-types, который содержит всего несколько файлов. Плюс юнит тесты и документацию, которая собирается в README markdown файл.
Читать полностью »

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

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

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

Git

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

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

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

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

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

Efficient Rails — новая книга по оптимизации процесса разработки Rails-приложений - 1

Эффективные Рельсы — более точного названия для книги придумать было бы сложно. Всё содержание описывается этими двумя словами и раскрывается для нас в сотне рецептов на 380+ страницах. В ожидании выхода финальной версии Rails 5, данное чтиво — то, на что стоит потратить время, благо потребуется его не так много. Но данное вложение вернётся колоссальной прибылью знаний и позволит, как говорится на обложке, «создавать Rails-приложения с нечеловеческой скоростью». Да и не только Rails, да и не только Ruby. Первые две главы включают в себя обилие информации по работе с терминалом и СКВ. Подробности под катом.
Читать полностью »

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

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

Конфигурация сервиса Azure

Сначала мы займемся созданием нашей виртуальной машины на платформе Azure. В портале управления Azure ("Azure Management Portal") мы переходим по пунктам меню New > Compute > From Gallery ("Новый > Расчет > Из галереи").
1

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


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js