Git *

Привет!

В этом релизе мы сосредоточились на производительности и качестве. Вместе с другими командами JetBrains, мы занимались оптимизацией производительности, повышением отзывчивости интерфейса, улучшением существующей функциональности.

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

Мы также работали над поддержкой новых фреймворков для создания микросервисов, таких как Micronaut, Quarkus и Helidon, и сделали долгожданную поддержку MongoDB.

Вышел новый релиз GitLab с созданием и развертыванием кластеров EKS, поддержкой Crossplane, панелью окружений и многими другими классными фичами!

Сегодня мы расскажем о принципах и моделях GitOps, а также о том, как эти модели реализуются на платформе OpenShift. Интерактивное руководство на эту тему доступно по ссылке.



Если вкратце, то GitOps – это набор практических методов использования pull-запросов Git для управления конфигурациями инфраструктуры и приложений. Git-репозиторий в рамках GitOps рассматривается как один единственный источник сведений о состоянии системы, причем любые изменения этого состояния полностью отслеживаются и поддаются аудиту.

В этой статье сравним с технической точки зрения самые известные системы управления версиями (в будущем планируем расширить список):

1. Первое поколение
   
   • SCCS (Source Code Control System)
   • RCS (Revision Control System)
2. Второе поколение
   • CVS (Concurrent Versions System)
   • SVN (Apache Subversion)
3. Третье поколение
   • Git
   • Mercurial

Примечание от переводчика: это первая часть монументальной (на самом деле монументальной) статьи о Vim и его возможностях от разработчика из Миннеаполиса и автора проекта PostgREST Джо begriffs Нельсона.

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

---

Эта статья основана на исследовании истории Vim и прочтении его руководства пользователя от корки до корки. Надеюсь, эти заметки помогут вам открыть (или переоткрыть?) для себя основные функциональные возможности этого редактора, а также позволят отказаться от использования предупакованных файлов vimrc и более вдумчиво использовать плагины.

Список литературы

Чтобы выйти за границы привычных тем, я бы порекомендовал обзавестись бумажной копией этого руководства и емким карманным справочником. Я не смог найти печатную копию руководства пользователя для Vim, так что в итоге просто распечатал идущий вместе с редактором PDF-файл с помощью printme1.com. Он идет вместе с софтом в $VIMRUNTIME/doc/usr_??. В качестве удобного списка команд могу посоветовать справочник «Vi and Vim Editors Pocket».

Содержание

• История
• Иерархия конфигурации
• Сторонние плагины
• Бекапы и откаты
• Include и path
• Редактирование и компиляция цикла
• Диффы и патчи
• Буфер ввода / вывода
• Типы файлов
• Не забывайте про мышь
• Разное

История

Рождение vi

Команды и функции Vi существуют уже более пятидесяти лет, начиная с редактора QED. Вот его таймлайн:

Оглавление

Предисловие
1. Настройка git
....1.1 Конфигурационные файлы
....1.2 Настройки по умолчанию
....1.3 Псевдонимы (aliases)
2. Основы git
....2.1 Создание репозитория
....2.2 Состояние файлов
....2.3 Работа с индексом
....2.4 Работа с коммитами
....2.5 Просмотр истории
....2.6 Работа с удалённым репозиторием
3. Ветвление в git
....3.1 Базовые операций
....3.2 Слияние веток
....3.3 Rerere
4. Указатели в git
....4.1 Перемещение указателей
5. Рекомендуемая литература

Предисловие

Git — самая популярная распределённая система контроля версиями.[1][2]

Основное предназначение Git – это сохранение снимков последовательно улучшающихся состояний вашего проекта (Pro git, 2019).

Прим. перев.: Эта публикация британского программиста, ставшая настоящим хитом в англоязычном интернете, ссылается на Git-коммит 6-летней давности. Он был зафиксирован в одном из открытых репозиториев Government Digital Service — службы, занимающейся развитием цифровых услуг в Великобритании и поддерживающей проект GOV.UK. Сам коммит интересен не столько изменениями в коде, сколько сопровождающим их описанием…


Картинка из xkcd #1296

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

Доброго дня

У нас имеется несколько облачных кластеров с большим количеством виртуальных машин в каждом. Все это дело у нас хостится в Hetzner'e. В каждом кластере у нас имеется по одной мастер-машине, с нее делается снэпшот и автоматически разносится по всем виртуалкам внутри кластера.

Эта схема не позволяет нам нормально использовать gitlab-runner'ы, так как возникает очень много проблем при появлении множества одинаковых зарегистрированных раннеров, что и побудило к нахождению обходного пути и к написанию этой статьи/мануала.

Вероятно, это не best practice, но это решение показалось максимально удобным и простым.

За туториалом прошу под кат.

Любой, кто использует Git, знает, что у него крутая линия обучения. Мы узнали от разработчиков, что большинство людей, как правило, учатся у знакомых, будь то коллега, профессор, друг или даже видео на YouTube. В GitHub Desktop 2.2 мы добавляем первую версию интерактивного учебника по Git и GitHub, который может стать вашим другом и помочь вам начать работу. Если вы новичок в Desktop, вы можете скачать и попробовать учебник по адресу desktop.github.com.

Из проекта в проект мы замечаем, что наш код, выполняет одни и те же функции и выглядит почти одинаково. Это заставляет задуматься — а не выполняем ли мы лишнюю работу, переписывая одно и то же? Мы начинаем копировать классы из предыдущих проектов и все равно понимаем, что делаем что-то не то и оказываемся правы — просто копируя классы из проекта в проект, мы запросто можем что-то потерять/заменить/затереть, а если еще наша команда ведет несколько проектов одновременно, то обнаружение ошибок в заимствованных классах потребует изменений вручную во всех проектах. Устав наступать на эти грабли, мы решаем, что нужен общий код, который будет расшариваться на все наши проекты и любые изменения в нем будут легко подтягиваться. Да, мы создаем свою библиотеку переиспользуемых компонентов! О разных способах организовать свою библиотеку, о всех плюсах и минусах подходов вы узнаете под катом :)

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

Команде AppsCast, конечно, захотелось узнать больше, и за консультацией по практическому применению всех возможностей Git ребята обратились к Егору Андреевичу из Square.

Привет, Хабр! Представляю вашему вниманию перевод статьи "Git for Computer Scientists" автора Tommi Virtanen.

GIT изнутри: введение

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

Кому будет интересно и, возможно, полезно: людям, ежедневно работающим с Git (т.е. каждому второму, если не первому разработчику ПО), и желающим лучше понять механизм его работы.

Примечание: для лучшего понимания статьи следует иметь представление о таком звере, как направленный ациклический граф (directed acyclic graph, DAG).

Представляем вашему вниманию вторую часть перевода материала о борьбе команды gitlab.com с тиранией времени.



→ Вот, кстати, первая часть.

Материал, первую часть перевода которого мы публикуем сегодня, посвящён масштабной проблеме, которая возникла в gitlab.com. Здесь пойдёт речь о том, как её обнаружили, как с ней боролись, и как, наконец, её решили. Кроме того, столкнувшись с этой проблемой, команда gitlab.com узнала о том, что такое тирания часов.



→ Вторая часть.

Данная заметка имеет собой цель продемонстрировать автоматический git bisect на примере ядра Linux. С последующим поиском официальной версии начиная с которой всё поломалось и последней хорошей версии.

Привет! Традиционно рассказываем, что нового в IntelliJ IDEA 2019.2. Список большой и все равно неполный: если хочется подробностей, добро пожаловать на страницу What’s new in IntelliJ IDEA 2019.2.

В одной из статей опубликованных на хабре я в комментах вычитал, что на gitlab.com есть копии deepNude, чисто из любопытства нашел ее и сделал форк «на всякий случай». Через 3 часа после этого я не смог запушить код, т.к. улетел в бан…

10 мая мы запустили ограниченный бета-тест GitHub Package Registry, службы управления пакетами, которая позволяет легко публиковать публичные или частные пакеты рядом с исходным кодом. В настоящее время сервис поддерживает знакомые инструменты управления пакетами: JavaScript (npm), Java (Maven), Ruby (RubyGems), .NET (NuGet), образы Docker, а также многое другое.

Рады анонсировать, что добавим поддержку пакетов Swift в GitHub Package Registry. Пакеты Swift позволяют легко делиться вашими библиотеками и исходным кодом в собственных проектах и с сообществом Swift. Работать над этим мы будем в партнерстве с ребятами из Apple.

На GitHub представлено больше 300 языков программирования, начиная с общеизвестных языков, таких как Python, Java, и Javascript, и заканчивая эзотерическими языками, такими как Befunge, известными только малым группам людей.

Топ-10 языков программирования, размещенных на GitHub, по количеству репозиториев

Одна из проблем, с которой сталкивается GitHub — распознавание разных языков программирования. Когда какой-то код размещается в репозитории, очень важным является распознавание его типа. Это нужно из соображений поиска, оповещений об уязвимостях, подсветки синтаксиса, а также структурного представления контента репозитория пользователям.

На первый взгляд, распознавание языка является простой задачей, но это не совсем так. Linguist — это инструмент, который мы сейчас используем для определения языка программирования на GitHub. Linguist — это приложение на Ruby, использующее различные стратегии про распознаванию языка, в том числе данные о названиях и расширения файлов. Кроме того оно принимает во внимание модели Vim или Emacs, а также содержимое в верхней части файла (shebang). Linguist обрабатывает языковую неоднозначность эвристически и, если таким способом не получается, то использует наивный байесовский классификатор, обученный на небольшой выборке данных.

Хотя Linguist достаточно хорошо предсказывает на уровне файла (точность 84%), все ломается, когда файлы названы странно, а тем более, когда у файлов нет расширений. Это делает Linguist бесполезным для такого контента, как GitHub Gists или фрагментов кода в README, ошибках и pull requests.

Каждый может сделать так:

локальный проект → github

С (платным) ssh доступом вы сможете сделать так:

локальный проект → PythonAnywhere

В статье показано как (бесплатно) сделать так:

локальный проект → github → PythonAnywhere

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