Pro Git

Рекомендую читать электронную версию — там картинки цветные:) В этой книге это важно, бумажный ЧБ воспринимается значительно хуже. И английский здесь простой, редко приходится ходить в словарь, так что можете читать на английском для тренировки языка в том числе. На сайте Git эта книга выложена бесплатно в PDF и EPUB, есть английская и русская версии.

Касательно содержимого — отличный материал. Начинающим работать с Git стоит прочесть как минимум Getting Started, Git basics и Git branching. Этого уже будет достаточно и для реальной работы, и для понимания того, как Git устроен. Можно догнаться главой Git tools и главой про GitHub.

Книга доступна в открытом исходнике, что полностью соответствует концепции Open Source.

Процесс сборки и электронной публикации книги полностью автоматизирован.

Читал в оригинале, на английском, чтобы не потерять специфики.

Разработчикам, пожалуй, отдельно не стоит писать рецензию, зачем нужно изучать Git.

Скажу пару слов  для тех, кто далёк от программирования.

Хранение и переиспользование текстовой информации в концепции Git очень напоминает ДНК.

Нет единственно «правильной» версии, как в широко известном Вики формате представления информации.

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

Всегда можно посмотреть сколько общих частей в текстах разных инстанций.

Чем они отличаются и в какой момент времени эти различия появились.

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

И эта книга на простых примерах с картинками объясняет все нюансы.

Начиная с краткой истории эволюционного появления Git.

Давно подумывал освоить какую-нибудь систему контроля версий исходного кода. Git - одна из наиболее популярных сейчас систем. Для меня важно, что реализована она на языке Си. Довольно популярна сейчас и другая распределённая система контроля версий - Mercurial. По свойствам они очень похожи, однако Mercurial реализован на языке Python. В отличие от централизованных систем контроля версий, распределённые системы позволяют разным разработчикам делать форки чужих проектов с особой лёгкостью. Каждый из форков является вполне самостоятельным, но его авторы могут обмениваться друг с другом фрагментами кода, применимыми к их вариантам кода. Конечно, всё то же самое можно делать и с централизованными системами, но особенности их реализации таковы, что делать форки чужих проектов и обмениваться кодом в централизованных системах значительно тяжелее.

Изначально мотивацией для освоения Git у меня было желание представить свои разработки в виде, удобном для просмотра через интернет. Поэтому сначала я захотел подобрать для себя подходящее веб-приложение для управления репозиториями. Попробовал настроить GitBlit, написанный на Java, но в нём меня не устроило отсутствие локализации интерфейса на русский язык. Затем настроил Gogs, написанный на Go, где такая локализация была. Начинал осваивать Git без книги. Создал репозитории программ, научился добавлять коммиты, создавать ветки и осуществлять слияния веток. Но захотелось изучить вопрос немного глубже, поэтому я решил прочитать книгу.

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

Купил бумажную книгу, прочитал и порадовался как глубине изложенного материала, так и очень высокому качеству перевода. В тексте книги мне не попадались ни предложения с мутным смыслом, ни рассогласованной терминологии, ни ошибок в ссылках на другие разделы, чего было довольно много, например, в книге IPv6. Администрирование сетей. Хочется выразить благодарность за качество перевода Рузмайкиной И., о которой я не нашёл никакой информации, даже имени, кроме списка переведённых книг. Ошибки мне попадались только на иллюстрациях, но скорее всего они присутствуют и в оригинале книги. Например, в книге имеется такая вот иллюстрация, на которой красным цветом я обозначил исправления, соответствующие описанию:

Читал я довольно долго. Материал непростой, а иногда и не особо интересный. Например, я читал без особого интереса главы про сайт GitHub, а также главы про Subversion, Perforce и приложения с графическим интерфейсом. Поэтому в перерывах между чтениями этой книги успел прочитать ещё три других.

Небольшим субъективным недостатком я посчитал то, что в книге не описана одна из моих любимых операций - git add с опцией -e. Эта опция позволяет редактировать патч, превращающий старую версию файла в новую. При этом можно удалить часть изменений из патча, а часть поменять. После выхода из редактора в коммит будут добавлены только те изменения, которые остались. Остальные изменения не попадут в коммит, но и никуда не пропадут - их можно будет добавить в следующий коммит целиком командой git add или очередную часть командой git add с опцией -e. Часто бывает так, что редактируя файл, я обнаруживаю в нём какие-то мелкие ошибки, закомментированные фрагменты кода. В таком случае я обычно тут же исправляю обнаруженные ошибки и удаляю устаревший код, но эти изменения логически не связаны с основными изменениями, которые я вношу в файл. Поэтому такие мелкие правки я выделяю в отдельные коммиты.

Вторая моя любимая операция - git rebase с опцией -i, описана достаточно подробно. После подготовки серии коммитов я могу переставить их местами или объединить в один коммит. Объединение коммитов бывает особенно полезно, когда первоначальная правка кода оказывается неправильной или не полной. В последующих правках код может быть исправлен, поэтому перед отправкой коммитов в публичный репозиторий неплохо объединить такие изменения в один коммит, чтобы коммит сразу оказался бы верным. Человеку, который будет читать журналы изменений, не придётся переживать о том, что коммит явно содержит ошибку и проверять, была ли исправлена эта ошибка в последней версии кода.

Мне особо полезной показалась глава 10, рассказывающая о внутреннем устройстве системы. Поначалу я осваивал высокоуровневые возможности системы и некоторые особенности системы приводили меня в замешательство. Например, однажды я переименовал каталог при помощи команды git mv, а потом добавил в репозиторий ещё один каталог, внутри которого был файл, совпадающий с тем, который был в первом каталоге. После создания коммита я обнаружил, что оригинальный файл переместился не в переименованный каталог, как ожидалось, а во вновь добавленный каталог. При этом новый файл возник в переименованном каталоге, а не во вновь добавленном. Дело в том, что git не записывает в коммите действия, приведшие к изменению файлов. git оперирует снимками файлов, относящихся к каждому коммиту.

Каждый коммит, за исключением начального, ссылается на предыдущий или на несколько предыдущих, если произошло слияние веток. Каждый коммит ссылается на дерево файлов. Дерево файлов ссылается на двоичные объекты и поддеревья. Двоичный объект представляет собой содержимое определённой версии определённого файла. Если файл не меняется в рамках коммита, то в следующем коммите создаётся ссылка на уже имеющийся двоичный объект. Если файл изменён, то в репозитории создаётся новый двоичный объект с новым содержимым, а очередной коммит содержит в одном из поддеревьев ссылку на вновь добавленный объект. Это не самый оптимальный способ хранения данных внутри репозитория, поэтому время от времени git упаковывает объекты в pack-файл, копируя туда последнюю версию каждого файла, а все предыдущие файлы записывает в виде отличий от следующей версии. Но сути такая упаковка не меняет: в git в принципе невозможно точно указать, какой файл и как был переименован. Если один файл исчез в одном снимке, а другой появился в следующем снимке, то система пытается сравнить их между собой и если обнаруживает достаточно общих фрагментов, то считает что файл был переименован. В моём случае проблему с неправильным определением переименования файла можно было бы решить, если этот коммит разделить на два: в первом происходило бы только переименование каталога, а во втором - добавление нового каталога.

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

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

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

Классная книга. Много полезных и наглядных примеров.
Самая полезная глава - "Git изнутри". После сложится понимание как работает большинство команд. И можно будет выполнять базовые команды с git репозиторием имея только директорию .git без установленного гита.

Например. Простотр коммит сообщения по хешу:

❯ cat .git/objects/e6/879c0c3e358e8400f3fc5e9677a48ceb661740|perl -MCompress::Zlib -0777 -e 'print uncompress <'|tr '\0' '\n'

commit 234
tree c2635674529d78a11624302cc23480a4d00e6984
parent 420f3aeeaa0c45bfac885856ad24dd9c2569d14b
author Victor Gaydov 1696324180 +0400
committer Victor Gaydov 1696324220 +0400

Refine colorhttp func

Например. Просмотр какие файлы входят в снапшот:

❯ cat .git/objects/c2/635674529d78a11624302cc23480a4d00e6984|perl -MCompress::Zlib -0777 -e '
$_ = uncompress();
s/^tree \d+\0//;
while (/(.?)\0(.{20})/sg) {
my ($header, $sha) = ($1, $2);
$header =~ /^(\d+) (.)$/;
my $hex = unpack("H*", $sha);
print "$1\t$hex\t$2\n";
}
'

40000 d3f3c0e53b33d211697bea88a56f7e62deb6d115 .github
100644 6bcd33c7f8945c6526bc2b3442fc591946448eff .gitignore
100644 4f0aa540e6980fd3fe27f6921b923541a9b5f469 .golangci.yml
100644 f4e3cec654057e6b7d011f9d004fc17e412393d4 .ignore
100644 da361dcc087c3d081a5ceae48ae064f2e6df9260 .spelling
100644 c72b02ee8e98654ae8b92732a0c8429a17e1ba51 HACKING.md
100644 a022050415f901d9e2bb76880f7e14a879c70404 LICENSE
100644 6f31bfaa909a0f435076e73140b029e49750428b Makefile
100644 6a9971e0d3ae6df648ac98e61deb32d0e8d9ebd8 README.md
.....

И многое другое

Здесь много рассуждать нет смысла: если вы разработчик, либо по какой-то другой причине столкнулись с необходимостью работать с Git, то данная книга точно — абсолютно точно — должна быть вами прочитана.
Во-первых, авторы причастны к созданию рассматриваемого инструмента.
Во-вторых, если вас интересует лишь "легкий старт", то достаточно будет хорошо проработать 1-3 главы. Причём полученных навыков будет достаточно для решения большинства рядовых задач при разработке ПО.
В-третьих, для тех, чей девиз — "Хочу всё знать", существует разделы, позволяющие узнать:
— как настроить собственный сервер с Git;
— как заставить систему Git вести себя так, как этого хочется разработчику;
— как выстроить хорошо налаженное взаимодействие при работе над общим проектом и автоматизировать почти все, что только возможно;
— что скрыто "под капотом" Git (как он устроен внутри);
— как полностью перейти на Git с другой системы контроля версий, либо как связать их вместе;
— и т.д., и т. п.
Желаю всем интересующимся скорее расставить для себя все по полочкам и научиться работать с Git даже с закрытыми глазами.

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

Данная книга не является полной документацией и обьяснением всех команд и параметров git. Думаю книга содержит информацию которая поможет в 80-90% рабочих случаев и дополнительную информацию о внетреннем устройстве git.

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

Если говорить о самой книге, то это максимально полное руководство по использованию Git. Для старта можно прочесть буквально одну главу (вторую), и приступать к работе с git. Во всех последующих главах проводится полное описание каждой функции git, методов работы и тд.