Обычно при работе с гитом придерживаются одного из двух подходов: либо держать большой красивый граф всех веток, либо поддерживать граф плоским при помощи rebase. Я больше люблю первый подход, но второй всегда надо иметь в виду, поэтому статья именно про него. Как работает rebase, как не сломать основной репозиторий и все такое прочее. Пис ✌️🏻

#git
https://medium.com/@cesarmcferreira/mastering-git-why-rebase-is-amazing-a954485b128a

Краткая история появления Git: что было до него, почему он появился и все в таком духе.

#git #history
http://hackaday.com/2017/05/11/history-of-git/

Если ты любишь консольный Git также, как люблю его я, то тебя наверняка заинтересуют несколько пунктов из этой статьи. Автор рассказывает про не очень известные, но порой очень полезные фишки. Эти однострочники можно спрятать под alias и безмятежно радоваться жизни.

#git
https://csswizardry.com/2017/05/little-things-i-like-to-do-with-git/

@yegor256 описал своё видение того, каким должен быть README файл.

#readme #git #github

Прикольная идея с отслеживанием болей в проекте (так автор характеризует файлы, которые часто нужно менять) через git history.
 
#git #legacy #tool

В тему предыдущего поста про археологию кода @vgrishechko прислал twitter тред и его более читаемую notion версию.
 
#tool #git #code

Тут в Git mailing list создатель JGit интересно расписал, с чем приходится сталкиваться, чтобы ускорить Git, написанный на чём-то более высокоуровневом (Java в его случае), чем C, и всё равно быть более медленным.

#git #c #java

В начале было Слово, и Слово было Боль. Потому что как ещё можно назвать мёрж огромного количества патчей в Linux Kernel вручную? Потом был BitKeeper, но не получилось. Потом появился Git. И вот мы здесь.
По ссылке - история появления Git. Какие VCS были на тот момент, чем не устраивали, чего хотел Линус, как он в какой-то момент плюнул и сделал то, чем подавляющее большинство разработчиков сегодня пользуется.

#git #history

Вообще мы у себя давно так делаем, оно появилось как-то само собой, чисто интуитивно, но оказывается у этого подхода есть умное название: Stacked PRs. Вкратце: не выкатываешь всю фичу разом на ревью, а отправляешь небольшими порциями в виде зависимых PRов. С github это всё довольно хорошо работает, но всё ещё приходится кое-что делать ручками. И вот тут в статье автор описывает, что хочется уметь делать минимальными усилиями, и какие тулы в этом могут помочь.

#git #tool

Очень прикольный тул, зацените, красота невероятная! Даёт визуализировать историю проекта по репозиторию. Репо тут.

#tool #git

Оу, кто-то внутри Google взялся пилить новую модную распределённую VCS? Забавно, что можно пользоваться поверх существующего Git репо незаметно для остальных, если вдруг хочется приключений.

#git #vcs #google

Какое-то время назад в git mailing list предложили core разработчикам следующее: уберите все свои .gitconfig настройки, поюзайте git, как его юзают люди после чистой установки, а потом поделитесь, какие новые настройки по умолчанию вы бы включили для всех. Дефолты менять никто конечно же не стал, но зато появилось вот такое интересное пересечение множеств удобных настроек.

#git #config

Git недавно отпраздновал 20 лет. Ещё годик, и везде будут наливать! А тут можно посмотреть разговор с Линусом по теме.

#talk #git #history

Что-то много в последнее время про менеджеры зависимостей попадается. Тут рассказывают, почему использовать Git в качестве БД для пакетов - плохая идея, каких проблем разные проекты из-за этого наелись, и как в итоге их решали. Оно на самом деле о двух концах. С одной стороны, когда проект только начинается, гораздо проще всё забутстрэпить. С другой - даже на таких начальных стадиях Git привносит дополнительных проблем и ограничений, с которыми потом придётся как-то жить.

#package #deps #git