В этой книге было показано больше десятка различных команд Git и мы приложили много усилий, чтобы рассказать вам о них, выстроив некий логический порядок, постепенно внедряя команды в сюжет. Но такой подход "размазал" описания команд по всей книге.
В этом приложении мы пройдёмся по всем командам, о которых шла речь, и сгруппируем их по смыслу. Мы расскажем, что делает каждая команда и укажем главы в книге, где эта команда использовалась.
Две довольно распространённые команды, используемые как сразу после установки Git’а, так и в повседневной практике для настройки и получения помощи — это config и help.
Сотни вещей в Git’е работают без всякой конфигурации, используя параметры по умолчанию. Для большинства из них вы можете задать иные умолчания, либо вовсе использовать собственные значения. Это включает в себя целый ряд настроек, начиная от вашего имени и заканчивая цветами в терминале и вашим любимым редактором. Команда config хранит и читает настройки в нескольких файлах, так что вы можете задавать значения глобально или для конкретных репозиториев.
Команда git config используется практически в каждой главе этой книги.
В главе ch01-introduction.asc мы использовали эту команду для указания имени, адреса электронной почты и редактора ещё до того, как начать использовать Git.
В главе ch02-git-basics.asc мы показали, как можно использовать её для создания сокращённых вариантов команд с длинными списками опций, чтобы не печатать их все каждый раз.
В главе ch03-git-branching.asc мы использовали config чтобы задать поведение --rebase по умолчанию для команды git pull.
В главе ch07-git-tools.asc мы использовали её для задания хранилища ваших HTTP паролей.
В главе ch08-customizing-git.asc мы показали как настроить фильтры содержимого для данных, перемещаемых между индексом и рабочей директорией.
Ну и практически вся глава ch08-customizing-git.asc посвящена этой команде.
Команда git help служит для отображения встроенной документации Git о других командах. И хотя мы приводим описания самых популярных команд в этой главе, полный список параметров и флагов каждой команды доступен через git help <command>.
Мы представили эту команду в главе ch01-introduction.asc и показали как её использовать, чтобы найти больше информации о команде git shell в главе ch04-git-server.asc.
Существует два способа создать Git репозиторий. Первый — клонировать его из существующего репозитория (например, по сети); второй — создать репозиторий в существующей директории.
Чтобы превратить обычную директорию в Git репозиторий и начать версионировать файлы в ней, просто запустите git init.
Впервые мы продемонстрировали эту команду в главе ch02-git-basics.asc на примере создания нового репозитория для последующей работы с ним.
Мы немного поговорили о смене названия ветки по умолчанию с "master" на что-нибудь другое в главе ch03-git-branching.asc.
Мы использовали эту команду для создания чистого репозитория для работы на стороне сервера в главе ch04-git-server.asc.
Ну и наконец мы немного покопались во внутренностях этой команды в главе ch10-git-internals.asc.
На самом деле git clone работает как обёртка над некоторыми другими командами. Она создаёт новую директорию, переходит внутрь и выполняет git init для создания пустого репозитория, затем она добавляет новый удалённый репозиторий (git remote add) для указанного URL (по умолчанию он получит имя origin), выполняет git fetch для этого репозитория и, наконец, обновляет вашу рабочую директорию до последнего коммита, используя git checkout.
Команда git clone используется в десятке различных мест в этой книге, но мы перечислим наиболее интересные упоминания.
Первоначальное знакомство происходит в главе ch02-git-basics.asc, где мы даём немного объяснений и приводим несколько примеров.
В главе ch04-git-server.asc мы рассмотрели как использовать опцию --bare, чтобы создать копию Git репозитория без рабочей директории.
В главе ch07-git-tools.asc мы использовали git clone для распаковки упакованного с помощью git bundle репозитория.
Наконец, в главе ch07-git-tools.asc мы научились использовать опцию --recursive чтобы упростить клонирование репозитория с субмодулями.
И хотя git clone используется во многих других местах в книге, перечисленные выше так или иначе отличаются от других вариантов использования.
Всего несколько команд нужно для базового варианта использования Git для ведения истории изменений.
Команда git add добавляет содержимое рабочей директории в индекс (staging area) для последующего коммита. По умолчанию git commit использует лишь этот индекс, так что вы можете использовать git add для сборки слепка вашего следующего коммита.
Это одна из ключевых команд Git, мы упоминали о ней десятки раз на страницах книги. Ниже перечислены наиболее интересные варианты использования этой команды.
Знакомство с этой командой происходит в главе ch02-git-basics.asc.
О том как использовать git add для разрешения конфликтов слияния написано в главе ch03-git-branching.asc.
В главе ch07-git-tools.asc показано как использовать git add для добавления в индекс лишь отдельных частей изменённого файла.
В главе ch10-git-internals.asc показано как эта команда работает на низком уровне, чтобы вы понимали, что происходит за кулисами.
Команда git status показывает состояния файлов в рабочей директории и индексе: какие файлы изменены, но не добавлены в индекс; какие ожидают коммита в индексе. Вдобавок к этому выводятся подсказки о том, как изменить состояние файлов.
Мы познакомили вас с этой командой в главе ch02-git-basics.asc, разобрали стандартный и упрощённый формат вывода. И хотя мы использовали git status повсеместно в этой книге, практически все варианты использования покрыты в указанной главе.
Команда git diff используется для вычисления разницы между любыми двумя Git деревьями. Это может быть разница между вашей рабочей директорией и индексом (собственно git diff), разница между индексом и последним коммитом (git diff --staged), или между любыми двумя коммитами (git diff master branchB).
Мы познакомили вас с основами этой команды в главе ch02-git-basics.asc, где показали как посмотреть какие изменения уже добавлены в индекс, а какие — ещё нет.
О том как использовать эту команду для проверки на проблемы с пробелами с помощью аргумента --check можно почитать в главе ch05-distributed-git.asc.
Мы показали вам как эффективно сравнивать ветки используя синтаксис git diff A…B в главе ch05-distributed-git.asc.
В главе ch07-git-tools.asc показано использование опции -w для скрытия различий в пробельных символах, а также рассказано как сравнивать конфликтующие изменения с опциями --theirs, --ours и --base.
Использование этой команды с опцией --submodule для сравнения изменений в субмодулях показано в главе ch07-git-tools.asc.
Команда git difftool просто запускает внешнюю утилиту сравнения для показа различий в двух деревьях, на случай если вы хотите использовать что-либо отличное от встроенного просмотрщика git diff.
Мы лишь вкратце упомянули о ней в главе ch02-git-basics.asc.
Команда git commit берёт все данные, добавленные в индекс с помощью git add, и сохраняет их слепок во внутренней базе данных, а затем сдвигает указатель текущей ветки на этот слепок.
Вы познакомились с основами модели коммитов в главе ch02-git-basics.asc. Там же мы продемонстрировали использование опций -a для добавления всех изменений в индекс без использования git add, что может быть удобным в повседневном использовании, и -m для передачи сообщения коммита без запуска полноценного редактора.
В главе ch02-git-basics.asc мы рассказали об опции --amend, используемой для изменения последнего совершённого коммита.
В главе ch03-git-branching.asc мы более подробно познакомились с тем, что делает команда git commit и почему она делает это именно так.
Мы показали вам как подписывать ваши коммиты, используя опцию -S в главе ch07-git-tools.asc.
И наконец мы заглянули внутрь команды git commit в главе ch10-git-internals.asc и узнали что она делает за кулисами.
Команда git reset, как можно догадаться из названия, используется в основном для отмены изменений. Она изменяет указатель HEAD и, опционально, состояние индекса. Также эта команда может изменить файлы в рабочей директории при использовании параметра --hard, что может привести к потере наработок при неправильном использовании, так что убедитесь в серьёзности своих намерений прежде чем использовать его.
Мы рассказали об основах использования git reset в главе ch02-git-basics.asc, где эта команда использовалась для удаления файла из индекса, добавленного туда с помощью git add.
В главе ch07-git-tools.asc, полностью посвящённой этой команде, мы разобрались в деталях её использования.
Мы использовали git reset --hard чтобы отменить слияние в главе ch07-git-tools.asc, там же было продемонстрировано использование команды git merge --abort для этих целей, которая работает как обёртка над git reset.
Команда git rm используется в Git для удаления файлов из индекса и рабочей директории. Она похожа на git add с тем лишь исключением, что она удаляет, а не добавляет файлы для следующего коммита.
Мы немного разобрались с этой командой в главе ch02-git-basics.asc, показали как удалять файлы из рабочей директории и индекса и только из индекса, используя флаг --cached.
Ещё один вариант использования git rm приведён в главе ch10-git-internals.asc, где мы вкратце объяснили как использовать опцию --ignore-unmatch при выполнении git filter-branch, которая подавляет ошибки удаления несуществующих файлов. Это может быть полезно для автоматически выполняемых скриптов.
Команда git mv — это всего лишь удобный способ переместить файл, а затем выполнить git add для нового файла и git rm для старого.
Мы лишь вкратце упомянули это команду в главе ch02-git-basics.asc.
Команда git clean используется для удаления мусора из рабочей директории. Это могут быть результаты сборки проекта или файлы конфликтов слияний.
Мы рассмотрели множество опций и сценариев использования этой команды в главе ch07-git-tools.asc.
За создание новых веток и слияние их воедино отвечает несколько Git команд.
Команда git branch — это своего рода "менеджер веток". Она умеет перечислять ваши ветки, создавать новые, удалять и переименовывать их.
Большая часть главы ch03-git-branching.asc посвящена этой команде, она используется повсеместно в этой главе. Впервые команда branch была представлена в разделе ch03-git-branching.asc, а большинство таких её фич как перечисление и удаление веток были разобраны в разделе ch03-git-branching.asc.
В главе ch03-git-branching.asc мы показали как использовать сочетание git branch -u для отслеживания веток.
Наконец, мы разобрались что происходит за кулисами этой команды в главе ch10-git-internals.asc.
Команда git checkout используется для переключения веток и выгрузки их содержимого в рабочую директорию.
Мы познакомились с этой командой в главе ch03-git-branching.asc вместе с git branch.
В главе ch03-git-branching.asc мы узнали как использовать флаг --track для отслеживания веток.
В главе ch07-git-tools.asc мы использовали эту команду с опцией --conflict=diff3 для разрешения конфликтов заново, в случае если предыдущее решение не подходило по некоторым причинам.
Мы рассмотрел детали взаимосвязи этой команды и git reset в главе ch07-git-tools.asc.
Мы исследовали внутренние механизмы этой команды в главе ch10-git-internals.asc.
Команда git merge используется для слияния одной или нескольких веток в текущую. Затем она устанавливает указатель текущей ветки на результирующий коммит.
Мы познакомили вас с этой командой в главе ch03-git-branching.asc. И хотя git merge встречается в этой книге повсеместно, практически все использования имеют вид git merge <branch> с указанием единственной ветки для слияния.
Мы узнали как делать "сплющенные" слияния (когда Git делает слияние в виде нового коммита, без сохранения всей истории работы) в конце главы ch05-distributed-git.asc.
В главе ch07-git-tools.asc мы глубже разобрались с процессом слияния и этой командой, включая флаги -Xignore-all-whitespace и --abort, используемый для отмены слияния в случае возникновения проблем.
Мы научились проверять криптографические подписи перед слияниями если ваш проект использует GPG в главе ch07-git-tools.asc.
Ну и наконец в главе ch07-git-tools.asc мы познакомились со слиянием поддеревьев.
Команда git mergetool просто вызывает внешнюю программу слияний, в случае если у вас возникли проблемы слияния.
Мы вкратце упомянули о ней в главе ch03-git-branching.asc и рассказали как настроить свою программу слияния в главе ch08-customizing-git.asc.
Команда git log используется для просмотра истории коммитов, начиная с самого свежего и уходя к истокам проекта. По умолчанию, она показывает лишь историю текущей ветки, но может быть настроена на вывод истории других, даже нескольких сразу, веток. Также её можно использовать для просмотра различий между ветками на уровне коммитов.
Практически во всех главах книги эта команда используется для демонстрации истории проекта.
Мы познакомились c git log и некоторыми её деталями в главе ch02-git-basics.asc. Там мы видели использование опций -p и --stat для получения представления об изменениях в каждом коммите, а также --pretty and --oneline для настройки формата вывода этой команды — более полным и подробным или кратким.
В главе ch03-git-branching.asc мы использовали опцию --decorate чтобы отобразить указатели веток на истории коммитов, а также --graph чтобы просматривать историю в виде дерева.
В главах ch05-distributed-git.asc и ch07-git-tools.asc мы рассмотрели синтаксис branchA..branchB для просмотра уникальных для заданной ветки коммитов. Мы часто использовали этот приём в ch07-git-tools.asc.
В главах ch07-git-tools.asc и ch07-git-tools.asc мы рассмотрели синтаксис branchA…branchB и опцию --left-right для просмотра что находится в первой, либо второй ветке, но не сразу в обеих. Также в главе ch07-git-tools.asc рассмотрели опцию --merge, которая может быть полезной при разрешении конфликтов, а также --cc для просмотра конфликтов слияния в истории проекта.
В главе ch07-git-tools.asc мы использовали опцию -g для вывода git reflog, используя git log.
В главе ch07-git-tools.asc мы рассмотрели использование опций -S и -L для поиска событий в истории проекта, например, истории развития какой-либо фичи.
В главе ch07-git-tools.asc мы показали, как использовать опцию --show-signature для отображения строки валидации подписи для каждого коммита в git log.
Команда git stash используется для временного сохранения всех незакоммиченных изменений для очистки рабочей директории без необходимости коммитить незавершённую работу в новую ветку.
Эта команда практически целиком раскрыта в главе ch07-git-tools.asc.
Команда git tag используется для задания постоянной метки на какой-либо момент в истории проекта. Обычно она используется для релизов.
Мы познакомились и разобрались с ней в главе ch02-git-basics.asc и использовали на практике в ch05-distributed-git.asc.
Мы научились создавать подписанные с помощью GPG метки, используя флаг -s, и проверять их, используя флаг -v, в главе ch07-git-tools.asc.
Не так уж много команд в Git требуют сетевого подключения для своей работы, практически все команды оперируют с локальной копией проекта. Когда вы готовы поделиться своими наработками, всего несколько команд помогут вам работать с удалёнными репозиториями.
Команда git fetch связывается с удалённым репозиторием и забирает из него все изменения, которых у вас пока нет и сохраняет их локально.
Мы познакомились с ней в главе ch02-git-basics.asc и продолжили знакомство в ch03-git-branching.asc.
Мы использовали эту команду в нескольких примерах из главы ch05-distributed-git.asc.
Мы использовали её для скачивания запросов на слияние (pull request) из других репозиториев в главе ch06-github.asc, также мы рассмотрели использование git fetch для работы с упакованными репозиториями в главе ch07-git-tools.asc.
Мы рассмотрели тонкую настройку git fetch в главe и ch10-git-internals.asc.
Команда git pull работает как комбинация команд git fetch и git merge, т.е. Git вначале забирает изменения из указанного удалённого репозитория, а затем пытается слить их с текущей веткой.
Мы познакомились с ней в главе ch02-git-basics.asc и показали как узнать, какие изменения будут приняты в случае применения в главе ch02-git-basics.asc.
Мы также увидели как она может оказаться полезной для разрешения сложностей при перемещении веток в главе ch03-git-branching.asc.
Мы показали как можно использовать только URL удалённого репозитория без сохранения его в списке удалённых репозиториев в главе ch05-distributed-git.asc.
И наконец мы показали как проверять криптографические подписи полученных коммитов, используя опцию --verify-signatures в главе ch07-git-tools.asc.
Команда git push используется для установления связи с удалённым репозиторием, вычисления локальных изменений отсутствующих в нём, и собственно их передачи в вышеупомянутый репозиторий. Этой команде нужно право на запись в репозиторий, поэтому она использует аутентификацию.
Мы познакомились с этой командой в главе ch02-git-basics.asc. Там мы рассмотрели основы обновления веток в удалённом репозитории. В главе ch03-git-branching.asc мы подробнее познакомились с этой командой, а в ch03-git-branching.asc мы узнали как настроить отслеживание веток для автоматической передачи на удалённый репозиторий. В главе ch03-git-branching.asc мы использовали флаг --delete для удаления веток на сервере, используя git push.
На протяжении главы ch05-distributed-git.asc мы показали несколько примеров использования git push для совместной работы в нескольких удалённых репозиториях одновременно.
В главе ch07-git-tools.asc мы использовали опцию --recurse-submodules чтобы удостовериться, что все субмодули будут опубликованы перед отправкой на проекта на сервер, что может быть реально полезным при работе с репозиториями, содержащими субмодули.
В главе ch08-customizing-git.asc мы поговорили о триггере pre-push, который может быть выполнен перед отправкой данных, чтобы проверить возможность этой отправки.
Наконец, в главе ch10-git-internals.asc мы рассмотрели передачу данных с полным указанием передаваемых ссылок, вместо использования распространённых сокращений. Это может быть полезным если вы хотите очень точно указать, какими изменениями хотите поделиться.
Команда git remote служит для управления списком удалённых репозиториев. Она позволяет сохранять длинные URL репозиториев в виде понятных коротких строк, например "origin", так что вам не придётся забивать голову всякой ерундой и набирать её каждый раз для связи с сервером. Вы можете использовать несколько удалённых репозиториев для работы и git remote поможет добавлять, изменять и удалять их.
Эта команда детально рассмотрена в главе ch02-git-basics.asc, включая вывод списка удалённых репозиториев, добавление новых, удаление или переименование существующих.
Она используется практически в каждой главе, но всегда в одном и том же виде: git remote add <имя> <URL>.
Команда git archive используется для упаковки в архив указанных коммитов или всего репозитория.
Мы использовали git archive для для создания тарбола (tar.gz файла) всего проекта для передачи по сети в главе ch05-distributed-git.asc.
Команда git submodule используется для управления вложенными репозиториями. Например, это могут быть библиотеки или другие, используемые не только в этом проекте ресурсы. У команды submodule есть несколько под-команд — add, update, sync и др. — для управления такими репозиториями.
Эта команда упомянута и полностью раскрыта в главе ch07-git-tools.asc.
Команда git show отображает объект в простом и человекопонятном виде. Обычно она используется для просмотра информации о метке или коммите.
Впервые мы использовали её для просмотра информации об аннотированой метке в главе ch02-git-basics.asc.
В главе ch07-git-tools.asc мы использовали её для показа коммитов, подпадающих под различные селекторы диапазонов.
Ещё одна интересная вещь, которую мы проделывали с помощью git show в главе ch07-git-tools.asc — это извлечение содержимого файлов на различных стадиях во время конфликта слияния.
Команда git shortlog служит для подведения итогов команды git log. Она принимает практически те же параметры, что и git log, но вместо простого листинга всех коммитов, они будут сгруппированы по автору.
Мы показали, как можно использовать эту команду для создания классных списков изменений (changelogs) в главе ch05-distributed-git.asc.
Команда git describe принимает на вход что угодно, что можно трактовать как коммит (ветку, тег) и выводит более-менее человекочитаемую строку, которая не изменится в будущем для данного коммита. Это может быть использовано как более удобная, но по-прежнему уникальная, замена SHA-1.
Мы использовали git describe в главах ch05-distributed-git.asc и ch05-distributed-git.asc чтобы сгенерировать название для архивного файла с релизом.
В Git есть несколько команд, используемых для нахождения проблем в коде. Это команды для поиска места в истории, где проблема впервые проявилась и собственно виновника этой проблемы.
Команда git bisect — это чрезвычайно полезная утилита для поиска коммита в котором впервые проявился баг или проблема с помощью автоматического бинарного поиска.
О ней упоминается только в главе ch07-git-tools.asc, где она полностью и раскрыта.
Команда git blame выводит перед каждой строкой файла SHA-1 коммита, последний раз менявшего эту строку и автора этого коммита. Это помогает в поисках человека, которому нужно задавать вопросы о проблемном куске кода.
Эта команда полностью разобрана в главе ch07-git-tools.asc.
Команда git grep используется для поиска любой строки или регулярного выражения в любом из файлов вашего проекта, даже в более ранних его версиях.
Она полностью разобрана в разделе ch07-git-tools.asc и упоминается лишь там.
Некоторые команды в Git основываются на подходе к рассмотрению коммитов в терминах внесённых ими изменений, т.е. рассматривают историю коммитов как цепочку патчей. Ниже перечислены эти команды.
Команда git cherry-pick используется для того чтобы взять изменения, внесённые каким-либо коммитом, и попытаться применить их заново в виде нового коммита наверху текущей ветки. Это может оказаться полезным чтобы забрать парочку коммитов из другой ветки без полного слияния с той веткой.
Мы продемонстрировали работу этой команды в главе ch05-distributed-git.asc.
git rebase — это "автоматизированный" cherry-pick. Он выполняет ту же работу, но для цепочки коммитов, тем самым как бы перенося ветку на новое место.
Мы в деталях разобрались с механизмом переноса веток в главе ch03-git-branching.asc, включая рассмотрение потенциальных проблем переноса опубликованных веток при совместной работе.
Мы использовали эту команду на практике для разбиения истории на два репозитория в главе ch07-git-tools.asc, наряду с использованием флага --onto.
В главе ch07-git-tools.asc мы рассмотрели случай возникновения конфликта во время переноса коммитов.
Также мы познакомились с интерактивным вариантом git rebase, включающемся с помощью опции -i, в главе ch07-git-tools.asc.
Команда git revert — полная противоположность git cherry-pick. Она создаёт "антикоммит" для указанного коммита, таким образом отменяя изменения, внесённые в нём..
Мы использовали её в главе ch07-git-tools.asc чтобы отменить коммит слияния (merge commit).
Множество проектов, использующих Git (включая сам Git), активно используют списки рассылок для координирования процесса разработки. В Git есть несколько команд, помогающих в этом, начиная от генерации патчей, готовых к пересылке по электронной почте, заканчивая применением таких патчей прямиком из папки "входящие".
Команда git apply применяет патч, сформированный с помощью команды git diff или GNU diff. Она делает практически то же самое, что и команда patch.
Мы продемонстрировали использование этой команды в главе ch05-distributed-git.asc и описали случаи, когда вы возможно захотите ею воспользоваться.
Команда git am используется для применения патчей из ящика входящих сообщений электронной почты, в частности, тех что используют формат mbox. Это используется для простого получения изменений через email и применения их к проекту.
Мы рассмотрели использование этой команды в главе ch05-distributed-git.asc, включая такие опции как --resolved, -i и -3.
Существует набор триггеров, которые могут оказаться полезными при использовании git am для процесса разработки. О них рассказано в главе ch08-customizing-git.asc.
Также мы использовали git am для применения сформированного из Github’овского запроса на слияние patch-файла в главе ch06-github.asc.
Команда git format-patch используется для создания набора патчей в формате mbox которые можно использовать для отправки в список рассылки.
Мы рассмотрели процесс отсылки изменений в проект, использующий email для разработки в главе ch05-distributed-git.asc.
Команда git send-email используется для отсылки патчей, сформированных с использованием git format-patch, по электронной почте.
Процесс отсылки изменений по электронной почте в проект рассмотрен в главе ch05-distributed-git.asc.
Команда git request-pull используется для генерации примерного текста сообщения для отсылки кому-либо. Если у вас есть ветка, хранящаяся на публичном сервере, и вы хотите чтобы кто-либо забрал эти изменения без возни с отсылкой патчей по электронной почте, вы можете выполнить эту команду и послать её вывод тому человеку.
Мы показали, как пользоваться этой командой в главе ch05-distributed-git.asc.
В Git есть несколько стандартных команд для работы с другими системами контроля версий.
Команда git svn используется для работы с сервером Subversion. Это означает, что вы можете использовать Git в качестве SVN клиента, забирать изменения и отправлять свои собственные на сервер Subversion.
Мы разобрались с этой командой в главе ch09-git-and-other-scms.asc.
Для других систем контроля версий, либо для импорта произвольно форматированных данных, вы можете использовать git fast-import, которая умеет преобразовывать данные в формат, понятный Git’у.
Мы детально рассмотрели эту команду в главе ch09-git-and-other-scms.asc.
Если вы администрируете Git репозиторий или вам нужно исправить что-либо, Git предоставляет несколько административных команд вам в помощь.
Команда git gc запускает сборщик мусора в вашем репозитории, который удаляет ненужные файлы из хранилища объектов и эффективно упаковывает оставшиеся файлы.
Обычно, эта команда выполняется автоматически без вашего участия, но, если пожелаете, можете вызвать её вручную. Мы рассмотрели некоторые примеры её использования в главе ch10-git-internals.asc.
Команда git fsck используется для проверки внутренней базы данных на предмет наличия ошибок и несоответствий.
Мы лишь однажды использовали её в главе ch10-git-internals.asc для поиска более недостижимых (dangling) объектов.
Команда git reflog просматривает историю изменения голов веток на протяжении вашей работы для поиска коммитов, которые вы могли внезапно потерять, переписывая историю.
В основном, мы рассматривали эту команду в главе ch07-git-tools.asc, где мы показали пример использования этой команды, а также как использовать git log -g для просмотра той же информации, используя git log.
Мы на практике рассмотрели восстановление потерянной ветки в главе ch10-git-internals.asc.
Команда git filter-branch используется для переписывания содержимого коммитов по заданному алгоритму, например, для полного удаления файла из истории или для вычленения истории лишь части файлов в проекте для вынесения в отдельный репозиторий.
В главе ch07-git-tools.asc мы объяснили механизм работы этой команды и рассказали про использование опций --commit-filter, --subdirectory-filter и --tree-filter.
В главах ch09-git-and-other-scms.asc и ch09-git-and-other-scms.asc мы использовали эту команду для исправления импортированных репозиториев.
Также в этой книге встречались некоторые низкоуровневые ("сантехнические") команды.
Первая из них — это ls-remote, с которой мы столкнулись в главе ch06-github.asc и использовали для просмотра ссылок на сервере.
В главах ch07-git-tools.asc, ch07-git-tools.asc и ch07-git-tools.asc мы использовали команду ls-files чтобы просмотреть "сырые" данные в индексе.
Мы также упоминали о команде rev-parse в главе ch07-git-tools.asc, используемой для превращения практически произвольно отформатированных строк в SHA-1 указатели.
Так или иначе, большинство низкоуровневых команд собрано в главе ch10-git-internals.asc, которая на них и сосредоточена. Мы старались избегать этих команд в других местах в этой книге.