В этой книге было показано больше десятка различных команд Git и мы приложили много усилий, чтобы рассказать вам о них, выстроив некий логический порядок, постепенно внедряя команды в сюжет. Но такой подход «размазал» описания команд по всей книге.
В этом приложении мы пройдёмся по всем командам, о которых шла речь, и сгруппируем их по смыслу. Мы расскажем, что делает каждая команда и укажем главы в книге, где эта команда использовалась.
|
Tip
|
Можно использовать аббревиатуры для опций.
Например, можно использовать команду |
Две довольно распространённые команды, используемые как сразу после установки Git, так и в повседневной практике для настройки и получения помощи — это config и help.
Сотни вещей в Git работают без всякой конфигурации, используя параметры по умолчанию.
Для большинства из них вы можете задать иные умолчания, либо вовсе использовать собственные значения.
Это включает в себя целый ряд настроек, начиная от вашего имени и заканчивая цветами в терминале и вашим любимым редактором.
Команда config хранит и читает настройки в нескольких файлах, так что вы можете задавать значения глобально или для конкретных репозиториев.
Команда git config используется практически в каждой главе этой книги.
В разделе ch01-getting-started.asc главы 1 мы использовали эту команду для указания имени, адреса электронной почты и редактора ещё до того, как начать использовать Git.
В разделе ch02-git-basics-chapter.asc главы 2 мы показали, как можно использовать её для создания сокращённых вариантов команд с длинными списками опций, чтобы не печатать их все каждый раз.
В разделе ch03-git-branching.asc главы 3 мы использовали config чтобы задать поведение --rebase по умолчанию для команды git pull.
В разделе ch07-git-tools.asc главы 7 мы использовали её для задания хранилища ваших HTTP-паролей.
В разделе ch08-customizing-git.asc главы 7 мы показали как настроить фильтры содержимого для данных, перемещаемых между индексом и рабочей копией.
И наконец, этой команде посвящён практически весь раздел ch08-customizing-git.asc главы 8.
Согласно инструкциям, приведённым в разделе ch01-getting-started.asc главы 1, большинство редакторов может быть установлено следующим образом:
core.editor| Редактор | Команда |
|---|---|
Atom |
|
BBEdit (Mac, with command line tools) |
|
Emacs |
|
Gedit (Linux) |
|
Gvim (Windows 64-bit) |
|
Kate (Linux) |
|
nano |
|
Notepad (Windows 64-bit) |
|
Notepad++ (Windows 64-bit) |
|
Scratch (Linux) |
|
Sublime Text (macOS) |
|
Sublime Text (Windows 64-bit) |
|
TextEdit (macOS) |
|
Textmate |
|
Textpad (Windows 64-bit) |
|
Vim |
|
Visual Studio Code |
|
VSCodium (Free/Libre Open Source Software Binaries of VSCode) |
|
WordPad |
|
Xi |
|
|
Note
|
Если у вас установлена 32 битная версия редактора в 64 битной системе, то путь к ней будет содержать |
Команда git help служит для отображения встроенной документации Git о других командах.
И хотя мы приводим описания самых популярных команд в этой главе, полный список параметров и флагов каждой команды доступен через git help <command>.
Мы представили эту команду в разделе ch01-getting-started.asc главы 1 и показали как её использовать, чтобы найти больше информации о команде git shell в разделе ch04-git-on-the-server.asc главы 4.
Существует два способа создать Git репозиторий. Первый — клонировать его из существующего репозитория (например, по сети); второй — создать репозиторий в существующем каталоге.
Чтобы превратить обычный каталог в Git репозиторий и начать версионировать файлы в нём, просто запустите git init.
Впервые мы продемонстрировали эту команду в разделе ch02-git-basics-chapter.asc главы 2 на примере создания нового репозитория для последующей работы с ним.
Мы немного поговорили о смене названия ветки по умолчанию с «master» на что-нибудь другое в разделе ch03-git-branching.asc главы 3.
Мы использовали эту команду для создания чистого репозитория для работы на стороне сервера в разделе ch04-git-on-the-server.asc главы 4.
Ну и наконец мы немного покопались во внутренностях этой команды в разделе ch10-git-internals.asc главы 10.
На самом деле git clone работает как обёртка над некоторыми другими командами.
Она создаёт новый каталог, переходит внутрь и выполняет git init для создания пустого репозитория, затем она добавляет новый удалённый репозиторий (git remote add) для указанного URL (по умолчанию он получит имя origin), выполняет git fetch для этого репозитория и, наконец, извлекает последний коммит в ваш рабочий каталог, используя git checkout.
Команда git clone используется в десятке различных мест в этой книге, но мы перечислим наиболее интересные упоминания.
Первоначальное знакомство происходит в разделе ch02-git-basics-chapter.asc главы 2, где мы даём немного объяснений и приводим несколько примеров.
В разделе ch04-git-on-the-server.asc главы 4 мы рассмотрели как использовать опцию --bare, чтобы создать копию Git репозитория без рабочей копии.
В разделе ch07-git-tools.asc главы 7 мы использовали git clone для распаковки упакованного с помощью git bundle репозитория.
Наконец, в разделе ch07-git-tools.asc главы 7 мы научились использовать опцию --recursive чтобы упростить клонирование репозитория с подмодулями.
И хотя git clone используется во многих других местах в книге, перечисленные выше так или иначе отличаются от других вариантов использования.
Всего несколько команд нужно для базового варианта использования Git для ведения истории изменений.
Команда git add добавляет содержимое рабочего каталога в индекс (staging area) для последующего коммита.
По умолчанию git commit использует лишь этот индекс, так что вы можете использовать git add для сборки слепка вашего следующего коммита.
Это одна из ключевых команд Git, мы упоминали о ней десятки раз на страницах книги. Ниже перечислены наиболее интересные варианты использования этой команды.
Знакомство с этой командой происходит в разделе ch02-git-basics-chapter.asc главы 2.
О том как использовать git add для разрешения конфликтов слияния написано в разделе ch03-git-branching.asc главы 3.
В разделе ch07-git-tools.asc главы 7 показано как использовать git add для добавления в индекс лишь отдельных частей изменённого файла.
В разделе ch10-git-internals.asc показано как эта команда работает на низком уровне, чтобы вы понимали, что происходит за кулисами.
Команда git status показывает состояния файлов в рабочем каталоге и индексе: какие файлы изменены, но не добавлены в индекс; какие ожидают коммита в индексе.
Вдобавок к этому выводятся подсказки о том, как изменить состояние файлов.
Мы познакомили вас с этой командой в разделе ch02-git-basics-chapter.asc главы 2, разобрали стандартный и упрощённый формат вывода.
И хотя мы использовали git status повсеместно в этой книге, практически все варианты использования покрыты в указанной главе.
Команда git diff используется для вычисления разницы между любыми двумя Git деревьями.
Это может быть разница между вашей рабочей копией и индексом (собственно git diff), разница между индексом и последним коммитом (git diff --staged), или между любыми двумя коммитами (git diff master branchB).
Мы познакомили вас с основами этой команды в разделе ch02-git-basics-chapter.asc главы 2, где показали как посмотреть какие изменения уже добавлены в индекс, а какие — ещё нет.
О том как использовать эту команду для проверки на проблемы с пробелами с помощью аргумента --check можно почитать в разделе ch05-distributed-git.asc главы 5.
Мы показали вам как эффективно сравнивать ветки используя синтаксис git diff A…B в разделе ch05-distributed-git.asc главы 5.
В разделе ch07-git-tools.asc главы 7 показано использование опции -w для скрытия различий в пробельных символах, а также рассказано как сравнивать конфликтующие изменения с опциями --theirs, --ours и --base.
Использование этой команды с опцией --submodule для сравнения изменений в подмодулях показано в разделе ch07-git-tools.asc главы 7.
Команда git difftool просто запускает внешнюю утилиту сравнения для показа различий в двух деревьях, на случай если вы хотите использовать что-либо отличное от встроенного просмотрщика git diff.
Мы лишь вкратце упомянули о ней в разделе ch02-git-basics-chapter.asc главы 2.
Команда git commit берёт все данные, добавленные в индекс с помощью git add, и сохраняет их слепок во внутренней базе данных, а затем сдвигает указатель текущей ветки на этот слепок.
Вы познакомились с основами модели коммитов в разделе ch02-git-basics-chapter.asc главы 2.
Там же мы продемонстрировали использование опций -a для добавления всех изменений в индекс без использования git add, что может быть удобным в повседневном использовании, и -m для передачи сообщения коммита без запуска полноценного редактора.
В разделе ch02-git-basics-chapter.asc главы 2 мы рассказали об опции --amend, используемой для изменения последнего совершённого коммита.
В разделе ch03-git-branching.asc главы 3 мы более подробно познакомились с тем, что делает команда git commit и почему она делает это именно так.
Мы показали вам как подписывать ваши коммиты, используя опцию -S в разделе ch07-git-tools.asc главы 7.
И наконец мы заглянули внутрь команды git commit в разделе ch10-git-internals.asc главы 10 и узнали что она делает за кулисами.
Команда git reset, как можно догадаться из названия, используется в основном для отмены изменений.
Она изменяет указатель HEAD и, опционально, состояние индекса.
Также эта команда может изменить файлы в рабочем каталоге при использовании параметра --hard, что может привести к потере наработок при неправильном использовании, так что убедитесь в серьёзности своих намерений прежде чем использовать его.
Мы рассказали об основах использования git reset в разделе ch02-git-basics-chapter.asc главы 2, где эта команда использовалась для удаления файла из индекса, добавленного туда с помощью git add.
В разделе ch07-git-tools.asc, полностью посвящённой этой команде, мы разобрались в деталях её использования.
Мы использовали git reset --hard чтобы отменить слияние в разделе ch07-git-tools.asc главы 7, там же было продемонстрировано использование команды git merge --abort для этих целей, которая работает как обёртка над git reset.
Команда git rm используется в Git для удаления файлов из индекса и рабочей копии.
Она похожа на git add с тем лишь исключением, что она удаляет, а не добавляет файлы для следующего коммита.
Мы немного разобрались с этой командой в разделе ch02-git-basics-chapter.asc главы 2, показали как удалять файлы из рабочего каталога и индекса и только из индекса, используя флаг --cached.
Ещё один вариант использования git rm приведён в разделе ch10-git-internals.asc главы 10, где мы вкратце объяснили как использовать опцию --ignore-unmatch при выполнении git filter-branch, которая подавляет ошибки удаления несуществующих файлов.
Это может быть полезно для автоматически выполняемых скриптов.
Команда git mv — это всего лишь удобный способ переместить файл, а затем выполнить git add для нового файла и git rm для старого.
Мы лишь вкратце упомянули эту команду в разделе ch02-git-basics-chapter.asc главы 2.
Команда git clean используется для удаления мусора из рабочего каталога.
Это могут быть результаты сборки проекта или файлы конфликтов слияний.
Мы рассмотрели множество опций и сценариев использования этой команды в разделе ch07-git-tools.asc главы 7.
За создание новых веток и слияние их воедино отвечает несколько Git команд.
Команда git branch — это своего рода "менеджер веток".
Она умеет перечислять ваши ветки, создавать новые, удалять и переименовывать их.
Большая часть главы ch03-git-branching.asc посвящена этой команде, она используется повсеместно в этой главе.
Впервые команда branch была представлена в разделе ch03-git-branching.asc главы 3, а большинство таких её возможностей как перечисление и удаление веток были разобраны в разделе ch03-git-branching.asc главы 3.
В разделе ch03-git-branching.asc главы 3 мы показали как использовать сочетание git branch -u для отслеживания веток.
Наконец, мы разобрались что происходит за кулисами этой команды в разделе ch10-git-internals.asc главы 10.
Команда git checkout используется для переключения веток и выгрузки их содержимого в рабочий каталог.
Мы познакомились с этой командой в разделе ch03-git-branching.asc главы 3 вместе с git branch.
В разделе ch03-git-branching.asc главы 3 мы узнали как использовать флаг --track для отслеживания веток.
В разделе ch07-git-tools.asc главы 7 мы использовали эту команду с опцией --conflict=diff3 для разрешения конфликтов заново, в случае если предыдущее решение не подходило по некоторым причинам.
Мы рассмотрели детали взаимосвязи этой команды и git reset в разделе ch07-git-tools.asc главы 7.
Мы исследовали внутренние механизмы этой команды в разделе ch10-git-internals.asc главы 10.
Команда git merge используется для слияния одной или нескольких веток в текущую.
Затем она устанавливает указатель текущей ветки на результирующий коммит.
Мы познакомили вас с этой командой в разделе ch03-git-branching.asc главы 3.
И хотя git merge встречается в этой книге повсеместно, практически все использования имеют вид git merge <branch> с указанием единственной ветки для слияния.
Мы узнали как делать «сплющенные» слияния (когда Git делает слияние в виде нового коммита, без сохранения всей истории работы) в конце раздела ch05-distributed-git.asc.
В разделе ch07-git-tools.asc главы 7 мы глубже разобрались с процессом слияния и этой командой, включая флаги -Xignore-all-whitespace и --abort, используемый для отмены слияния в случае возникновения проблем.
Мы научились проверять криптографические подписи перед слияниями если ваш проект использует GPG в разделе ch07-git-tools.asc главы 7.
Ну и наконец в разделе ch07-git-tools.asc главы 7 мы познакомились со слиянием поддеревьев.
Команда git mergetool просто вызывает внешнюю программу слияний, в случае если у вас возникли проблемы слияния.
Мы вкратце упомянули о ней в разделе ch03-git-branching.asc главы 3 и рассказали как настроить свою программу слияния в разделе ch08-customizing-git.asc главы 8.
Команда git log используется для просмотра истории коммитов, начиная с самого свежего и уходя к истокам проекта.
По умолчанию, она показывает лишь историю текущей ветки, но может быть настроена на вывод истории других, даже нескольких сразу, веток.
Также её можно использовать для просмотра различий между ветками на уровне коммитов.
Практически во всех главах книги эта команда используется для демонстрации истории проекта.
Мы познакомились c git log и некоторыми её деталями в разделе ch02-git-basics-chapter.asc главы 2.
Там мы видели использование опций -p и --stat для получения представления об изменениях в каждом коммите, а также --pretty and --oneline для настройки формата вывода этой команды — более полным и подробным или кратким.
В разделе ch03-git-branching.asc главы 3 мы использовали опцию --decorate чтобы отобразить указатели веток на истории коммитов, а также --graph чтобы просматривать историю в виде дерева.
В разделах ch05-distributed-git.asc главы 5 и ch07-git-tools.asc главы 7 мы познакомили вас с синтаксисом branchA..branchB, позволяющем команде git log показывать только коммиты, присутствующие в одной ветке, но отсутствующие в другой.
Мы довольно подробно рассматриваем этот вопрос в разделе ch07-git-tools.asc.
В разделах ch07-git-tools.asc и ch07-git-tools.asc главы 7 мы рассмотрели синтаксис branchA…branchB и опцию --left-right позволяющие увидеть, что находится в одной или в другой ветке, но не в них обеих сразу.
Также в разделе ch07-git-tools.asc мы рассмотрели опцию --merge, которая может быть полезной при разрешении конфликтов, а также --cc для просмотра конфликтов слияния в истории проекта.
В разделе ch07-git-tools.asc главы 7 мы использовали опцию -g для вывода git reflog, используя git log.
В разделе ch07-git-tools.asc главы 7 мы рассмотрели использование опций -S и -L для поиска событий в истории проекта, например, истории развития какой-либо фичи.
В разделе ch07-git-tools.asc главы 7 мы показали, как использовать опцию --show-signature для отображения строки валидации подписи для каждого коммита в git log.
Команда git stash используется для временного сохранения всех незафиксированных изменений с целью очистки рабочего каталога без необходимости фиксировать незавершённую работу в текущей ветке.
Эта команда практически целиком раскрыта в разделе ch07-git-tools.asc главы 7.
Команда git tag используется для задания постоянной метки на какой-либо момент в истории проекта.
Обычно она используется для релизов.
Мы познакомились и разобрались с ней в разделе ch02-git-basics-chapter.asc главы 2 и использовали на практике в разделе ch05-distributed-git.asc главы 5.
Мы научились создавать подписанные с помощью GPG метки, используя флаг -s, и проверять их, используя флаг -v, в разделе ch07-git-tools.asc главы 7.
Не так уж много команд в Git требуют сетевого подключения для своей работы, практически все команды оперируют с локальной копией проекта. Когда вы готовы поделиться своими наработками, всего несколько команд помогут вам работать с удалёнными репозиториями.
Команда git fetch связывается с удалённым репозиторием и забирает из него все изменения, которых у вас пока нет и сохраняет их локально.
Мы познакомились с ней в разделе ch02-git-basics-chapter.asc главы 2 и продолжили знакомство в разделе ch03-git-branching.asc главы 3.
Мы использовали эту команду в нескольких примерах из раздела ch05-distributed-git.asc.
Мы использовали её для скачивания запросов на слияние (pull request) из других репозиториев в разделе ch06-github.asc главы 6, также мы рассмотрели использование git fetch для работы с упакованными репозиториями в разделе ch07-git-tools.asc главы 7.
Мы рассмотрели тонкую настройку git fetch в главе и ch10-git-internals.asc.
Команда git pull работает как комбинация команд git fetch и git merge, т. е. Git вначале забирает изменения из указанного удалённого репозитория, а затем пытается слить их с текущей веткой.
Мы познакомились с ней в разделе ch02-git-basics-chapter.asc главы 2 и показали как узнать, какие изменения будут приняты в случае применения в разделе ch02-git-basics-chapter.asc главы 2.
Мы также увидели как она может оказаться полезной для разрешения сложностей при перемещении веток в разделе ch03-git-branching.asc главы 3.
Мы показали как можно использовать только URL удалённого репозитория без сохранения его в списке удалённых репозиториев в разделе ch05-distributed-git.asc главы 5.
И наконец мы показали как проверять криптографические подписи полученных коммитов, используя опцию --verify-signatures в разделе ch07-git-tools.asc главы 7.
Команда git push используется для установления связи с удалённым репозиторием, вычисления локальных изменений отсутствующих в нём, и собственно их передачи в вышеупомянутый репозиторий.
Этой команде нужно право на запись в репозиторий, поэтому она использует аутентификацию.
Мы познакомились с этой командой в разделе ch02-git-basics-chapter.asc главы 2.
Там мы рассмотрели основы обновления веток в удалённом репозитории.
В разделе ch03-git-branching.asc главы 3 мы подробнее познакомились с этой командой, а в разделе ch03-git-branching.asc главы 3 мы узнали как настроить отслеживание веток для автоматической передачи на удалённый репозиторий.
В разделе ch03-git-branching.asc главы 3 мы использовали флаг --delete для удаления веток на сервере, используя git push.
На протяжении раздела ch05-distributed-git.asc мы показали несколько примеров использования git push для совместной работы в нескольких удалённых репозиториях одновременно.
В разделе ch07-git-tools.asc главы 7 мы использовали опцию --recurse-submodules чтобы удостовериться, что все подмодули будут опубликованы перед отправкой проекта на сервер, что может быть реально полезным при работе с репозиториями, содержащими подмодули.
В разделе ch08-customizing-git.asc главы 8 мы поговорили о триггере pre-push, который может быть выполнен перед отправкой данных, чтобы проверить возможность этой отправки.
Наконец, в разделе ch10-git-internals.asc главы 10 мы рассмотрели передачу данных с полным указанием передаваемых ссылок, вместо использования распространённых сокращений. Это может быть полезным если вы хотите очень точно указать, какими изменениями хотите поделиться.
Команда git remote служит для управления списком удалённых репозиториев.
Она позволяет сохранять длинные URL репозиториев в виде понятных коротких строк, например «origin», так что вам не придётся забивать голову всякой ерундой и набирать её каждый раз для связи с сервером.
Вы можете использовать несколько удалённых репозиториев для работы и git remote поможет добавлять, изменять и удалять их.
Эта команда детально рассмотрена в разделе ch02-git-basics-chapter.asc главы 2, включая вывод списка удалённых репозиториев, добавление новых, удаление или переименование существующих.
Она используется практически в каждой главе, но всегда в одном и том же виде: git remote add <имя> <URL>.
Команда git archive используется для упаковки в архив указанных коммитов или всего репозитория.
Мы использовали git archive для создания тарбола (tar.gz файла) всего проекта для передачи по сети в разделе ch05-distributed-git.asc главы 5.
Команда git submodule используется для управления вложенными репозиториями.
Например, это могут быть библиотеки или другие, используемые не только в этом проекте ресурсы.
У команды submodule есть несколько под-команд — add, update, sync и др. — для управления такими репозиториями.
Эта команда упомянута и полностью раскрыта в разделе ch07-git-tools.asc главы 7.
Команда git show отображает объект в простом и человекопонятном виде.
Обычно она используется для просмотра информации о метке или коммите.
Впервые мы использовали её для просмотра информации об аннотированной метке в разделе ch02-git-basics-chapter.asc главы 2.
В разделе ch07-git-tools.asc главы 7 мы использовали её для показа коммитов, подпадающих под различные селекторы диапазонов.
Ещё одна интересная вещь, которую мы проделывали с помощью git show в разделе ch07-git-tools.asc главы 7 — это извлечение содержимого файлов на различных стадиях во время конфликта слияния.
Команда git shortlog служит для подведения итогов команды git log.
Она принимает практически те же параметры, что и git log, но вместо простого листинга всех коммитов, они будут сгруппированы по автору.
Мы показали, как можно использовать эту команду для создания классных списков изменений (changelogs) в разделе ch05-distributed-git.asc главы 5.
Команда git describe принимает на вход что угодно, что можно трактовать как коммит (ветку, тег) и выводит более-менее человекочитаемую строку, которая не изменится в будущем для данного коммита.
Это может быть использовано как более удобная, но по-прежнему уникальная, замена SHA-1.
Мы использовали git describe в главах ch05-distributed-git.asc и ch05-distributed-git.asc чтобы сгенерировать название для архивного файла с релизом.
В Git есть несколько команд, используемых для нахождения проблем в коде. Это команды для поиска места в истории, где проблема впервые проявилась и собственно виновника этой проблемы.
Команда git bisect — это чрезвычайно полезная утилита для поиска коммита в котором впервые проявился баг или проблема с помощью автоматического бинарного поиска.
О ней упоминается только в разделе ch07-git-tools.asc главы 7, где она полностью и раскрыта.
Команда git blame выводит перед каждой строкой файла SHA-1 коммита, последний раз менявшего эту строку и автора этого коммита.
Это помогает в поисках человека, которому нужно задавать вопросы о проблемном куске кода.
Эта команда полностью разобрана в разделе ch07-git-tools.asc главы 7.
Команда git grep используется для поиска любой строки или регулярного выражения в любом из файлов вашего проекта, даже в более ранних его версиях.
Она полностью разобрана в разделе ch07-git-tools.asc главы 7 и упоминается лишь там.
Некоторые команды в Git основываются на подходе к рассмотрению коммитов в терминах внесённых ими изменений, т. е. рассматривают историю коммитов как цепочку патчей. Ниже перечислены эти команды.
Команда git cherry-pick берёт изменения, вносимые одним коммитом, и пытается повторно применить их в виде нового коммита в текущей ветке.
Эта возможность полезна в ситуации, когда нужно забрать парочку коммитов из другой ветки, а не сливать ветку целиком со всеми внесёнными в неё изменениями.
Этот процесс описан и показан в разделе ch05-distributed-git.asc главы 5.
git rebase — это «автоматизированный» cherry-pick.
Он выполняет ту же работу, но для цепочки коммитов, тем самым как бы перенося ветку на новое место.
Мы в деталях разобрались с механизмом переноса веток в разделе ch03-git-branching.asc главы 3, включая рассмотрение потенциальных проблем переноса опубликованных веток при совместной работе.
Мы использовали эту команду на практике для разбиения истории на два репозитория в разделе ch07-git-tools.asc главы 7, наряду с использованием флага --onto.
В разделе ch07-git-tools.asc главы 7 мы рассмотрели случай возникновения конфликта во время переноса коммитов.
Также мы познакомились с интерактивным вариантом git rebase, включающемся с помощью опции -i, в разделе ch07-git-tools.asc главы 7.
Команда git revert — полная противоположность git cherry-pick.
Она создаёт новый коммит, который вносит изменения, противоположные указанному коммиту, по существу отменяя его.
Мы использовали её в разделе ch07-git-tools.asc главы 7 чтобы отменить коммит слияния (merge commit).
Множество проектов, использующих Git (включая сам Git), активно используют списки рассылок для координирования процесса разработки. В Git есть несколько команд, помогающих в этом, начиная от генерации патчей, готовых к пересылке по электронной почте, заканчивая применением таких патчей прямиком из почты.
Команда git apply применяет патч, сформированный с помощью команды git diff или GNU diff.
Она делает практически то же самое, что и команда patch.
Мы продемонстрировали использование этой команды в разделе ch05-distributed-git.asc главы 5 и описали случаи, когда вы возможно захотите ею воспользоваться.
Команда git am используется для применения патчей из входящих сообщений электронной почты, в частности, тех что используют формат mbox.
Это используется для простого получения изменений через email и применения их к проекту.
Мы рассмотрели использование этой команды в разделе ch05-distributed-git.asc главы 5, включая такие опции как --resolved, -i и -3.
Существует набор триггеров, которые могут оказаться полезными при использовании git am для процесса разработки.
О них рассказано в разделе ch08-customizing-git.asc главы 8.
Также мы использовали git am для применения сформированного из GitHub-запроса на слияние patch-файла в разделе ch06-github.asc главы 6.
Команда git format-patch используется для создания набора патчей в формате mbox которые можно использовать для отправки в список рассылки.
Мы рассмотрели процесс отсылки изменений в проект, использующий email для разработки в разделе ch05-distributed-git.asc главы 5.
Команда git send-email используется для отсылки патчей, сформированных с использованием git format-patch, по электронной почте.
Процесс отсылки изменений по электронной почте в проект рассмотрен в разделе ch05-distributed-git.asc главы 5.
Команда git request-pull используется для генерации примерного текста сообщения для отсылки кому-либо.
Если у вас есть ветка, хранящаяся на публичном сервере, и вы хотите чтобы кто-либо забрал эти изменения без возни с отсылкой патчей по электронной почте, вы можете выполнить эту команду и послать её вывод тому человеку.
Мы показали, как пользоваться этой командой в разделе ch05-distributed-git.asc главы 5.
В Git есть несколько стандартных команд для работы с другими системами контроля версий.
Команда git svn используется для работы с сервером Subversion.
Это означает, что вы можете использовать Git в качестве SVN клиента, забирать изменения и отправлять свои собственные на сервер Subversion.
Мы разобрались с этой командой в разделе ch09-git-and-other-systems.asc главы 9.
Для других систем контроля версий, либо для импорта произвольно форматированных данных, вы можете использовать git fast-import, которая умеет преобразовывать данные в формат, понятный Git.
Мы детально рассмотрели эту команду в разделе ch09-git-and-other-systems.asc главы 9.
Если вы администрируете Git репозиторий или вам нужно исправить что-либо, Git предоставляет несколько административных команд вам в помощь.
Команда git gc запускает сборщик мусора в вашем репозитории, который удаляет ненужные файлы из хранилища объектов и эффективно упаковывает оставшиеся файлы.
Обычно, эта команда выполняется автоматически без вашего участия, но, если пожелаете, можете вызвать её вручную. Мы рассмотрели некоторые примеры её использования в разделе ch10-git-internals.asc главы 10.
Команда git fsck используется для проверки внутренней базы данных на предмет наличия ошибок и несоответствий.
Мы лишь однажды использовали её в разделе ch10-git-internals.asc главы 10 для поиска более недостижимых (dangling) объектов.
Команда git reflog просматривает историю изменения голов веток на протяжении вашей работы для поиска коммитов, которые вы могли внезапно потерять, переписывая историю.
В основном, мы рассматривали эту команду в разделе ch07-git-tools.asc главы 7, где мы показали пример использования этой команды, а также как использовать git log -g для просмотра той же информации, используя git log.
Мы на практике рассмотрели восстановление потерянной ветки в разделе ch10-git-internals.asc главы 10.
Команда git filter-branch используется для переписывания содержимого коммитов по заданному алгоритму, например, для полного удаления файла из истории или для вычленения истории лишь части файлов в проекте для вынесения в отдельный репозиторий.
В разделе ch07-git-tools.asc главы 7 мы объяснили механизм работы этой команды и рассказали про использование опций --commit-filter, --subdirectory-filter и --tree-filter.
Также в этой книге встречались некоторые низкоуровневые («сантехнические») команды.
Первая из них — это ls-remote, с которой мы столкнулись в разделе ch06-github.asc главы 6 и использовали для просмотра ссылок на сервере.
В главах ch07-git-tools.asc, ch07-git-tools.asc и ch07-git-tools.asc мы использовали команду ls-files чтобы просмотреть «сырые» данные в индексе.
Мы также упоминали о команде rev-parse в разделе ch07-git-tools.asc главы 7, используемой для превращения практически произвольно отформатированных строк в SHA-1 указатели.
Так или иначе, большинство низкоуровневых команд собрано в главе ch10-git-internals.asc, которая на них и сосредоточена. Мы старались избегать этих команд в других местах в этой книге.