Git *

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

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

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

При установке и конфигурировании Git-сервера встаёт вопрос об организации доступа нескольких пользователей к нескольким проектам. Я провёл исследование вопроса и нашёл решение, удовлетворяющее всем моим требованиям: простое, безопасное, надёжное.

Мои пожелания таковы:

• каждый пользователь подключается со своим собственным аккаунтом
• над одним проектом может работать несколько пользователей
• один и тот же пользователь может работать над несколькими проектами
• каждый пользователь имеет доступ только в те проекты, над которыми он работает
• должна быть возможность подключения через командую строку, а не только через какой-то веб-интерфейс

Также было бы здорово:

• предоставлять права только для чтения для контролирующих лиц
• удобно администрировать права доступа пользователей в Git

Прим. перев.: В сообществе Kubernetes явную популярность набирает тренд под названием GitOps, в чём мы лично убедились, посетив KubeCon Europe 2019. Этот термин был относительно недавно придуман главой компании Weaveworks — Alexis Richardson — и означает применение привычных для разработчиков инструментов (в первую очередь — Git, откуда и само название) для решения задач эксплуатации. В частности, речь об эксплуатации Kubernetes через хранение его конфигураций в Git и автоматического выката изменений в кластер. О двух подходах к этому выкату и рассказывает Matthias Jg в данной статье.



В прошлом году (на самом деле, формально это произошло в августе 2017 г. — прим. перев.) появился новый подход к развёртыванию приложений в Kubernetes. Он называется GitOps, а в его основе лежит базовое представление о том, что отслеживание версий deployment'ов ведется в безопасной среде Git-репозитория.

У меня давно вошло в привычку создавать репозитории на GitHub. Это куда эффективнее, чем держать все на Google Drive или, того хуже, на жестком диске. Но здесь сразу появляется вопрос: как выполнить деплой на рабочий сервер?

Большинство поисковых запросов выводили меня на Jenkins и другие средства непрерывного развертывания. Но мне хотелось найти иное решение. Так я вышел на бесплатный сервис Webhook.