Git *

Мне на глаза попался документ с правилами и рекомендациями по процессу ревью кода внутри компании. Я решил, что такой полезной информацией надо поделиться с внешним миром. С благословения автора я публикую работу.

Привет. Меня зовут Сергей, последние пять лет я работаю в Яндексе. За это время участвовал в разработке одиннадцати проектов. Писал код на JavaScript, Python и C++. Некоторые проекты делал в одиночку, другие разрабатывал в группе из восьми человек. Но в каждой команде, на всех проектах, вне зависимости от языка программирования я использовал код-ревью.

С помощью код-ревью я постоянно узнаю что-то новое. Иногда, глядя на чужой код, хочется воскликнуть: "А что, так тоже можно?". В чужом коде я нахожу интересные приёмы и беру их себе на вооружение. Много новых знаний черпаю из комментариев к моему коду. Для меня стало открытием, что люди любят делиться своим опытом. Даже когда я разрабатываю проект в одиночку, то прошу ребят из другой команды посмотреть мои пулреквесты. Это мотивирует писать красивый и понятный код.

Но так было не всегда. Когда-то ревью было для меня наказанием. Я мог неделю с вдохновением писать код, вкладывая в него все силы. Отправлял пулреквест, трижды пинговал ревьювера, а в ответ получал сухое "вроде ок" или, что ещё хуже, десятки комментариев не по существу.

Мне на ревью приходили пулы из пяти тысяч строк. Я часами пытался разобраться в коде, по сотне раз скроллил от функции к тесту и обратно. Писал десятки бесполезных комментариев о пропущенной точке с запятой. Всё это жутко меня раздражало. Часто откладывал ревью на потом, и у меня накапливались десятки непросмотренных пулов.

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

Вчера часть пользователей Gitlab Pages могли столкнуться с тем, что их сайты перестали открываться. Например, мне пришло уведомление об этом от Яндекс Метрики в пн, 27 авг., 19:20.

А ночью пришло уведомление от Гитлаб, текст письма:

Не знаю, на каком языке программирования вы пишете, но уверен, что используете Гит при разработке. Инструментов для сопровождения разработки становится всё больше, но даже самый маленький тестовый проект, я неизменно начинаю с команды git init. А в течение рабочего дня набираю в среднем ещё 80 команд, обращаясь к этой системе контроля версий.

Я потратил кучу нервов, когда стал переучиваться на десятипальцевый метод печати. В итоге это стало самым правильным решением по улучшению личного рабочего процесса. В числе следующих по важности оптимизаций стоит углубленное освоение Гита.

На Хабр написано много статей о Гите, но они не уходят дальше официальной документации, а упрощать работу авторы предлагают самописными костылями. Я уверен, что изучать Гит нужно на конкретных примерах задач, а повышать эффективность работы с ним – стандартизированными средствами.

Кому будет полезна эта статья?

Вы уже освоили джентльменский набор Гита и готовы двигаться дальше? Существует 2 пути:

1. Освоить сокращённые команды – алиасы. Они почти всегда составлены мнемонически и легко запоминаются. Забыть оригиналы команд проблематично, я легко их набираю, когда это требуется. Плюс не сбиваюсь с мысли, проверяя что-то в Гите в процессе написания кода.
2. Узнать о дополнительных флагах к командам, а также их объединении между собой. Я понимаю, что кто-то ненавидит сокращения. Для вас тоже есть интересный материал в статье – как повысить полезность и удобство вывода команд, а также как решать не самые тривиальные, но часто встречающиеся на практике задачи.

Посвятите описанным в статье экспериментам пару часов сегодня, и сэкономьте по приблизительным расчётам полгода рабочей жизни.

Добро пожаловать под кат!

Эта статья — продолжение статьи про организацию процессов Continuous Integration / Continuous Delivery, автоматизирующих сборку, тестирование и доставку приложений применимо к решениям на платформе InterSystems.

Рассмотрим такие темы как:

• Контейнеры 101
• Контейнеры на разных этапах цикла разработки ПО
• Continuous Delivery с контейнерами

В этой статье я научу вас создавать собственные псевдонимы команд bash, а также как одновременно запускать несколько команд с помощью одной команды bash.

TL;DR В первой части описывается, почему псевдонимы — это так важно, сколько времени они экономят и т.д., но, если вы просто хотите узнать, как создать собственные псевдонимы, то перейдите к шагу 1.

Часто бывает так, что у разработчика со-временем накапливается некоторая коллекция кода который он использует в своих проектах.

Одни скрипты он использует в одних проектах, другие в других.

Эти скрипты со-временем совершенствуются, убираются баги, оптимизируются. Поэтому появляется вопрос, как синхронизировать новые версии скриптов с теми, которые в проектах.

Тут есть несколько вариантов:

Первый вариант:

Создать один репозиторий и поместить туда все скрипты. Затем этот репозиторий подключается как подмодуль к проекту и используется.

Минусы:

1. в проект копируются все скрипты включая ненужные.
2. подмодуль не commit-ится в репозиторий проекта, поэтому если будет недоступен удаленный репозиторий подмодуля, то мы не сможет выкачать проект целиком.

Второй вариант:

Каждый скрипт отдельно хранить на Github gist и подключать нужные как подмодули
Минус тот-же, что и в первом варианте во втором пункте.

Третий вариант:

Использовать Git Subtree.

(Данное решение является альтернативой для Git submodules)

Юля: Так, кто вчера менял мою процедуру?
Лёша: не я
Максим: не я
— Ребят, может Git заведём ?
Серёжа: давно пора!
прошло 2 недели…

Юля: ребяяят?
— Юль, а ты не коммитила?
Юля: damn нет(…

Вот так всё и началось. Ну а что, каждый символ и каждую строчку коммитить?

А может всё это будет происходить само?) На этом моменте в голову начинают приходить
DDL-триггеры, Temporal table и картина складывается. Решено, будем хранить версии внутри
SQL Server'a !)

Прим. перев.: На днях в блоге для инженеров любимого нами проекта GitLab появилась небольшая, но весьма полезная заметка с инструкциями, которые помогают сохранить время и нервы в случае различных проблем, случающихся по мере работы с Git. Вряд ли они будут новы для опытных пользователей, но обязательно найдутся и те, кому они пригодятся. А в конец этого материала мы добавили небольшой бонус от себя. Хорошей всем пятницы!

Все мы делаем ошибки, особенно при работе с такими сложными системами, как Git. Но помните: Git happens!

В GitLab 11.1 мы улучшили отображение безопасности за счёт панелей, усовершенствовали поиск по коду для своевременного получения нужной информации, внесли изменения в UX и многое другое.

Предыстория

Когда на руках появляется более одного рабочего устройства, то к тебе, %username%, приходит желание иметь одинаковую конфигурацию и тут, и там, и на работе, и дома. Когда я только-только начинал попытки синхронизировать файлы, мне было достаточно Dropbox и Yandex.disk. Особенно хорошо они помогали синхронизировать документы и историю джаббера, но как только я попытался приспособить их к .bashrc, .vimrc и им подобным, тут же повылезали различные сайд-эффекты. Например, с symlink'ами в обоих системах полнейшая беда, ± какая-то история есть только в дропбоксе, ну и писать скрипты управления зоопарком пришлось бы самому. Наверняка ведь что-то уже написано,

Предисловие от переводчика

На протяжении многих лет разработки ПО, будучи участником многих команд, работая с разными хорошими и опытными людьми, я часто наблюдал (да и чего греха таить, до определенного момента — создавал) одну и ту же проблему — тотальный бардак в репозитории. Каждый писал комментарии к коммитам в своем стиле (и хорошо, если постоянно в одном); половина комментариев была бесполезна (из разряда "это мост"), половина оставшейся половины — едва понятна.

И вот в один прекрасный момент я увидел данную статью, до перевода которой у меня наконец дошли руки. Всего 7 простых и коротких правил, и — о чудо — смотреть на историю коммитов стало не только полезно, но и приятно. Ничего революционного, все довольно очевидно, но сформулировано и резюмировано просто отлично.

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

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

Мы с радостью представляем вам новую версию GitLab со множеством нововведений и улучшений! В данном релизе мы улучшили автоматизацию релизов, вывели в общий доступ ранее платную функциональность, ускорили исправление уязвимостей безопасности и многое другое.

В день рождения «солнца русской поэзии» представим, как выглядела бы его его сегодняшняя жизнь: система контроля версий стихов, цензор Бенкендорф как проджект-менеджер и горящие дедлайны.



Пушкин сидит, пишет стихи. Прибегает Бенкендорф.
— Слушай, Пушкин, у нас все сроки горят! Надо релизиться. Инвесторы спрашивают: где контент?
— Не, ну я так не могу! Бенкендорф, я тебе сколько раз говорил, что я так не могу.
— Александр! От меня требуют, я ничего поделать не могу. Давай релизиться. Что у тебя там?
— Вот…

Это всё же случилось. Недавние сливы оказались правдой.

Факт продажи официально подтвердили в своих блогах и GitHub, и Microsoft.

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

Наша команда в Directum разрабатывает инструмент разработки для платформенных решений. Если вы видели 1С, то примерно сможете представить рабочее окружение наших "клиентов" — прикладных разработчиков. С помощью этого самого инструмента разработки прикладной разработчик создает прикладное решение для заказчиков.

Перед нашей командой встала задача упростить жизнь нашим прикладникам. Мы разбалованы современными фишками из Visual Studio, ReSharper и IDEA. Прикладники требовали от нас внедрить в инструмент работу с git "из коробки".

Я 10 лет разрабатываю ПО, участвовал в нескольких open source-проектах и в многочисленных не-open source-проектах, работал в больших и малых командах, и везде мы использовали Github в качестве репозитория версионирования.

За это время я перепробовал разные рабочие процессы, и хочу поделиться советами, как построить эффективный и прагматичный рабочий процесс по созданию и сопровождению качественного ПО, который можно применять в любом проекте.

Материал, перевод которого мы сегодня публикуем, посвящён настройке Git-серверов. Git — это система управления версиями, разработанная Линусом Торвальдсом. Git пользуются миллионы людей во всём мире. Компании, вроде GitHub, предлагают службы хостинга кода, основанные на Git. По информации, которую можно найти в различных публикациях, GitHub является крупнейшим сервисом для хостинга IT-проектов. В частности, в 2017-м году сообщество GitHub достигло 24 миллионов разработчиков, которые трудятся над 67 миллионами репозиториев. В наши дни GitHub пользуются абсолютно все — от программистов-одиночек, до крупных организаций. Надо сказать, что даже компания Google перешла на GitHub, закрыв собственный проект схожей направленности.