В книгата представихме много Git команди и се опитвахме това да бъде възможно най-информативно като постепенно добавяхме нови такива. Обаче, това ни оставя с примери разпръснати из цялото съдържание.
В това приложение ще преминем накратко през всички изброени дотук Git команди и ще се постараем да ги групираме, доколкото е възможно, според предназначението им. Ще говорим за това какво е общото предназначение на всяка команда и след това ще посочваме къде в книгата може да намерите примери с нея.
|
Tip
|
Можете да съкращавате дългите опции.
Например, може да напишете |
Две от командите в Git се използват почти ежедневно, config и help.
Git има начини за изпълнение по подразбиране на стотици операции. За много от тях, можете да инструктирате Git да прави по подразбиране нещата по малко по-различен начин. Това включва всичко, от това да кажете на Git какво е името ви до това да укажете специфични цветове в терминала или кой е редакторът ви, който предпочитате. Тази команда чете и пише в няколко различни файла, така че можете да задавате стойности глобално или за определени хранилища.
Командата git config се използва в почти всяка глава от книгата.
В ch01-getting-started.asc я ползвахме за задаване на име и имейл на потребителя, както и за указване на текстовия ни редактор — преди още да бяхме започнали да използваме Git.
В ch02-git-basics-chapter.asc показахме как бихте могли да я използвате за създаването на съкратени варианти на команди, които автоматично се разширяват до пълните еквиваленти, така че да не се налага да ги въвеждате изцяло всеки път.
В ch03-git-branching.asc използвахме командата за да направим --rebase опция по подразбиране при изпълнение на git pull.
В ch07-git-tools.asc я използвахме за определяне на default store за HTTP пароли.
В ch08-customizing-git.asc показахме как се създават smudge and clean филтри за съдържанието влизащо или излизащо от Git.
Почти всичко в ch08-customizing-git.asc е посветено на тази команда.
Съгласно конфигурационните инструкции в ch01-getting-started.asc, много редактори могат да се настроят както следва:
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) |
|
UltraEdit (Windows 64-bit) |
|
Vim |
|
Visual Studio Code |
|
VSCodium (Free/Libre Open Source Software Binaries of VSCode) |
|
WordPad |
|
Xi |
|
|
Note
|
Ако имате 32-битов редактор на 64-битов Windows, програмата ще бъде инсталирана в |
Командата git help се използва за показване на документацията на командите в Git.
Ние правим кратък преглед тук, но ако искате пълния списък с всички възможни аргументи и флагове за коя да е команда, можете винаги да изпълните git help <command>.
Представихме git help в ch01-getting-started.asc и показахме как да я използвате за да намерите повече информация за git shell в ch04-git-on-the-server.asc.
Има два начина за сдобиване с Git хранилище. Единият е да го копираме от налично такова в мрежата или където и да се намира. Другият е да си го създадем от налична директория.
За да вземем произволна директория и да я превърнем в Git хранилище, просто изпълняваме git init.
Показахме това първо в ch02-git-basics-chapter.asc, където създадохме ново хранилище, по което да работим.
Накратко споменахме как можем да сменим името на клона по подразбиране от “master” до друго такова в ch03-git-branching.asc.
Използваме тази команда и за създаване на празно bare хранилище на сървъра в ch04-git-on-the-server.asc.
Последно, погледнахме какво командата прави задкулисно в ch10-git-internals.asc.
Командата git clone по същество е нещо като wrapper около няколко други команди.
Тя създава нова директория, влиза в нея и изпълнява git init за да създаде празно Git хранилище, след това добавя remote (git remote add) към URL-а, който ѝ подавате (по подразбиране с име origin), изпълнява git fetch от това отдалечено хранилище и извлича в работната ви директория най-новия къмит с git checkout.
git clone се използва на цял куп места в книгата, ще изброим само най-интересните.
Командата бе представена и обяснена в ch02-git-basics-chapter.asc, където дадохме няколко примера.
В ch04-git-on-the-server.asc погледнахме опцията --bare за създаване на Git хранилище без работна директория.
В ch07-git-tools.asc я използвахме за да възстановим пакетирано Git хранилище.
В ch07-git-tools.asc научихме за опцията --recurse-submodules, с чиято помощ улесняваме клонирането на хранилище с подмодули.
Въпреки, че командата се използва на много други места в книгата, гореизброените са тези, при които тя се използва по по-различен и специфичен начин.
За основния работен процес по индексиране на съдържание и къмитването му в историята, съществуват само няколко основни команди.
Командата git add добавя съдържание от работната директория в staging area (или “индексната област”) за следващия къмит.
Когато се изпълни git commit, по подразбиране тя гледа какво има само в индекса, така git add се използва за определяне на това какво точно искате да включите в следващия snapshot.
Това е много важна за Git команда и се споменава десетки пъти в книгата. Ето по-важните места.
Представихме git add първо в ch02-git-basics-chapter.asc.
Показахме как да я използваме за разрешаване на конфликти при сливане в ch03-git-branching.asc.
Демонстрирахме как да я използваме интерактивно за да индексираме само специфични части от модифициран файл в ch07-git-tools.asc.
Последно, емулирахме я на ниско ниво в ch10-git-internals.asc, така че да получите представа какво се случва под повърхността.
Командата git status ще ви покаже различните статуси на файловете в работната директория и индексната област.
Кои файлове са променени и неиндексирани и кои са индексирани, но все още не са къмитнати.
В нормалната си форма, тя също така подава основни съвети за това как да премествате файлове между тези етапи.
Видяхме status за първи път в ch02-git-basics-chapter.asc.
Използваме я почти навсякъде в книгата, но почти всичко, което можете да вършите с нея е обяснено там.
Командата git diff се използва, когато искате да видите разликите между кои да е две дървета.
Това би могло да бъде разликата между работната област и индексната (което прави git diff без аргументи), между индексната област и последния къмит (git diff --staged), или между два къмита (git diff master branchB).
За пръв път срещнахме git diff в ch02-git-basics-chapter.asc, където показахме как да видим кои промени са индексирани и кои все още не са.
Използвахме я и за търсене на възможни whitespace проблеми преди къмитване с опцията --check в ch05-distributed-git.asc.
Видяхме как да проверим за разлики между клонове по ефективен начин използвайки синтаксиса git diff A…B в ch05-distributed-git.asc.
Използвахме я за да филтрираме whitespace разлики с флага -b а също и за сравнение на различни етапи от конфликтни файлове с --theirs, --ours и --base в ch07-git-tools.asc.
Накрая, използвахме я за ефективно сравнение на submodule промени със --submodule опцията в ch07-git-tools.asc.
Командата git difftool просто стартира външен инструмент за показване на разликите между две дървета, в случай че предпочитате нещо различно от вградената git diff.
Споменахме я в ch02-git-basics-chapter.asc.
Командата git commit взема съдържанието на всички файлове индексирани преди това с git add и записва нов перманентен snapshot в базата данни, след което премества указателя на текущия клон към него.
Основите на къмитването показахме в ch02-git-basics-chapter.asc.
Там също така показахме как с удобния флаг -a можем да прескочим git add стъпката в ежедневния работен процес и как с -m да подадем къмит съобщението директно от командния ред, вместо да пускаме редактора.
Във ch02-git-basics-chapter.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-chapter.asc, където я използвахме за да извадим от индекса файл, върху който е изпълнена git add.
След това я разгледахме в повече детайли в ch07-git-tools.asc, секцията беше изцяло посветена на нея.
Използвахме git reset --hard за да отменим сливане в ch07-git-tools.asc, където също така използвахме и git merge --abort, която е един вид wrapper за git reset.
Използваме git rm за изваждане на файлове от индексната област и работната директория в Git.
Тя е подобна на git add в това, че индексира файл (само че за изваждане) от следващия къмит.
Погледнахме я в малко детайли в ch02-git-basics-chapter.asc, включително за рекурсивно изтриване на файлове и също така за изтриване на файлове само от индекса, но не и от работната директория с опцията --cached.
Единственият вид различно приложение на git rm в книгата е в ch10-git-internals.asc, където използвахме и обяснихме опцията --ignore-unmatch при изпълнение на git filter-branch, която просто игнорира грешката, ако файлът който се опитваме да изтрием не съществува.
Това може да е полезно за ползване в скриптове.
Командата git mv е просто удобен заместител за ситуациите, когато трябва да преместите файл, да изпълните git add за новия файл и след това git rm за стария.
Само я споменахме накратко в ch02-git-basics-chapter.asc.
Командата git clean се използва за премахване на нежелани файлове от работната директория.
Това може да включва премахването на временни обекти от компилиране или merge conflict файлове.
Разглеждаме много от опциите и сценариите, в които може да се използва clean командата в ch07-git-tools.asc.
Няколко команди имплементират по-голямата част от branching и merging функционалностите в Git.
git branch по същество е инструмент за управление на клоновете в Git.
Може да създава, изброява, изтрива и преименува клонове.
Повечето от написаното в ch03-git-branching.asc е посветено на branch командата и тя се използва в цялата глава.
Първо я представихме в ch03-git-branching.asc и преминахме през повечето ѝ възможности (печатане и изтриване) в ch03-git-branching.asc.
В ch03-git-branching.asc използваме git branch -u за да укажем tracking клон.
Последно, погледнахме какво прави тя на заден план в ch10-git-internals.asc.
Командата git checkout се използва за превключване на клонове и за извличане на съдържание в работната директория.
За пръв път я срещнахме в ch03-git-branching.asc заедно с командата git branch.
Видяхме как да я използваме за да започнем да следим клонове с флага --track в ch03-git-branching.asc.
Използваме я за повторно въвеждане на конфликти във файлове с опцията --conflict=diff3 в ch07-git-tools.asc.
Навлизаме в по-дълбоки подробности за връзката ѝ с git reset в ch07-git-tools.asc.
Детайли по имплементацията ѝ показахме в ch10-git-internals.asc.
Инструментът git merge се използва за сливане на един или повече клонове в клона, който е текущо извлечен.
След сливането, текущият клон се премества напред с резултата от сливането.
Командата git merge видяхме за пръв път в ch03-git-branching.asc.
Въпреки, че се използва на различни места в книгата, тя има много малко на брой вариации — в общи линии само git merge <branch> с името на единичен клон, който искаме да слеем.
Видяхме как се прави squashed сливане (където Git слива работата, но го прави под формата на единичен обединяващ къмит, вместо да записва цялата история на сливащия се клон) в края на ch05-distributed-git.asc.
Преминахме през доста детайли по merge процеса и самата команда, включително -Xignore-space-change командата и флага --abort за отказ на проблематично сливане в ch07-git-tools.asc.
Видяхме как да проверяваме сигнатури преди сливане, ако проектът ви използва GPG подписване в ch07-git-tools.asc.
Накрая научихме за Subtree сливането в ch07-git-tools.asc.
Командата git mergetool служи за стартиране на външен merge helper в случай, че не харесвате вграденото сливане в Git.
Погледнахме го набързо в ch03-git-branching.asc и навлязохме в детайли за това как да имплементирате собствен външен merge tool във ch08-customizing-git.asc.
Командата git log се използва за показване на достъпна записана история на проект от най-късно записания къмит snapshot назад.
Тя по подразбиране ще покаже само историята на текущия клон, но може да ѝ се подадат различни или дори повече heads или клонове, от които да трасира.
Също често се използва за показване на разлики между два или повече клона на ниво къмит.
Тази команда се среща в почти всяка глава в книгата за демонстрация на различни аспекти от историята на проект.
Представихме я първо в ch02-git-basics-chapter.asc.
Там разгледахме аргументите ѝ -p и --stat за да получим представа какво е било въведено във всеки къмит, както и --pretty и --oneline опциите за да видим историята по-стегнато заедно с някои прости опции за филтриране по дата и автор.
В ch03-git-branching.asc я използваме с аргумента --decorate за лесно визуализиране на това къде сочат указателите на клоновете, а също и с опцията --graph за да видим как изглеждат разклонени истории.
В ch05-distributed-git.asc и ch07-git-tools.asc обяснихме синтаксиса branchA..branchB за да инструктираме git log да намери кои къмити са уникални за даден клон в сравнение с друг клон.
В ch07-git-tools.asc разгледахме това сравнително обстойно.
В ch07-git-tools.asc и ch07-git-tools.asc използваме формата branchA…branchB и --left-right синтаксиса, за да видим какво е налично в един от двата клона, но не и в двата едновременно.
В ch07-git-tools.asc също видяхме как да използваме --merge опцията за помощ при изследване на merge конфликти, както и --cc опцията за търсене на merge commit конфликти в историята.
В ch07-git-tools.asc демонстрирахме флага -g за да видим Git reflog-а през този инструмент вместо да правим branch traversal.
В ch07-git-tools.asc използвахме флаговете -S и -L за търсене на неща, които са се случили хронологично в кода във времето, например историята на дадена функция.
В ch07-git-tools.asc виждаме как да използваме --show-signature за да добавим верификационен стринг към всеки къмит в изхода от git log в зависимост от това дали той е валидно подписан или не.
Командата git stash се използва за временно съхранение/скриване на некъмитната работа с цел да се изчисти работната директория без да е необходимо къмитване на недовършената работа в клона.
Това е обяснено изцяло в ch07-git-tools.asc.
git tag командата предоставя възможност за създаване на перманентен маркер (bookmark) към специфична точка в историята на кода.
В общи линии се използва за маркиране на неща от рода на releases.
Тази команда е представена и разгледана в подробности в ch02-git-basics-chapter.asc и я използваме в действие в ch05-distributed-git.asc.
Погледнахме как да създадем GPG signed таг с флага -s и също така как да проверим такъв с -v в ch07-git-tools.asc.
Не са много командите в Git, които правят мрежови операции, почти всички работят с локалната база данни. Когато сте готови да споделите работата си обаче, ето какви са възможностите:
git fetch комуникира с отдалечено хранилище и издърпва всичката информация от него, която липсва в локалната база данни.
Представихме я във ch02-git-basics-chapter.asc и продължихме с примери за нея в ch03-git-branching.asc.
Използвахме я и в няколко примера в ch05-distributed-git.asc.
Използваме я за издърпваме на конкретна референция, която е извън областта по подразбиране в ch06-github.asc и видяхме как да издърпваме от bundle в ch07-git-tools.asc.
Направихме строго потребителски refspecs с цел да накараме git fetch да направи нещо малко по-различно от подразбиращото се в ch10-git-internals.asc.
Командата git pull по същество е комбинация от git fetch и git merge командите като Git ще се опита да изтегли и слее промените от отдалеченото хранилище в една стъпка.
Представихме я първоначално във ch02-git-basics-chapter.asc и демонстрирахме как да видим какво ще бъде слято, ако бъде изпълнена в ch02-git-basics-chapter.asc.
Видяхме как да я използваме в помощ при rebasing затруднения в ch03-git-branching.asc.
Показваме как да я използваме с URL за да интегрираме промени в one-off маниер в ch05-distributed-git.asc.
Набързо отбелязваме, че може да използвате опцията --verify-signatures за да проверите дали къмитите, които интегрирате са били GPG подписани в ch07-git-tools.asc.
Командата git push използваме за комуникация с отдалечено хранилище, за изчисляване и изпращане към него на информацията, която е налична локално, но не присъства на отдалечения сървър.
Тя изисква права за запис в отдалеченото хранилище и нормално се използва с някакъв вид автентикация.
За пръв път се срещнахме с git push в ch02-git-basics-chapter.asc.
Там видяхме основите на публикуването на клонове в отдалечени хранилища.
В ch03-git-branching.asc навлязохме малко по-дълбоко в публикуването на специфични клонове, а в ch03-git-branching.asc видяхме как да направим tracking клонове, към които да публикуваме автоматично.
В ch03-git-branching.asc използвахме флага --delete за да изтрием клон от сървъра с git push.
В ch05-distributed-git.asc видяхме множество примери на използване на командата за споделяне на работа с множество отдалечени хранилища.
Научихме как да я използваме за споделяне на тагове с опцията --tags в ch02-git-basics-chapter.asc.
В ch07-git-tools.asc използвахме опцията --recurse-submodules за да проверим дали цялата ни работа по подмодулите е била публикувана преди да публикуваме основния проект. Това може да е много полезно, когато използваме подмодули.
В ch08-customizing-git.asc говорихме за pre-push hook скрипта, който можем да настроим да се стартира преди публикуването да завърши и да проверява дали съдържанието е валидно.
Последно, в ch10-git-internals.asc видяхме как се публикува с пълни refspec, вместо с общоприетите shortcuts, които се използват нормално. Това може да ви помогне да сте много прецизни в това каква точно работа искате да публикувате.
git remote е управляващ инструмент за данните за отдалечени хранилища.
Позволява да изписвате дългите URL-и под формата на съкратени описателни имена като например “origin”.
Може да имате много такива и git remote се използва за добавяне, редактиране и изтриването им.
Командата разгледахме в подробности в ch02-git-basics-chapter.asc, включително показване, добавяне, изтриване и преименуване на отдалечени референции.
Тя също се използва почти във всяка глава в книгата, но винаги в стандартния формат git remote add <name> <url>.
Командата git archive използваме за създаване на архивен файл от специфичен snapshot на проекта.
Използвахме git archive за да създадем tarball на проект, подходящ за споделяне в ch05-distributed-git.asc.
Командата git submodule се използва за управление на външни хранилища в рамките на основния проект.
Може да се използва за библиотеки или други споделени ресурси.
submodule има няколко подкоманди като (add, update, sync) за управлението им.
Присъства и се обяснява изцяло само в ch07-git-tools.asc.
Командата git show може да покаже Git обект в опростен и по-интуитивен вид.
Нормално се използва за показване на информация за таг или къмит.
Използвахме я първо в ch02-git-basics-chapter.asc за да покажем информация за анотирани тагове.
По-късно я използвахме често в ch07-git-tools.asc за да изведем къмитите, към които се отнасят конкретни ревизии на проекта.
Едно от по-интересните неща, които направихме с git show беше в ch07-git-tools.asc, когато я използвахме за да извлечем специфично съдържание от файлове от различни етапи по време на merge конфликт.
git shortlog се използва за съкратено обобщение на изхода от git log.
Тя приема много от аргументите на git log, но вместо да извежда всички къмити, ще отпечата обобщение на къмитите групирани по автор.
Показахме как да я използваме за да създадем прегледен changelog в ch05-distributed-git.asc.
Командата git describe приема Git обект и извежда стринг, който е четим за хората и не се променя.
Това е начин да получим описание на къмит, което да е уникално като SHA-1 хеша, но малко по-разбираемо.
Използвахме git describe в ch05-distributed-git.asc и ch05-distributed-git.asc за да получим стринг, с който да именуваме нашия release файл.
Git има няколко команди, които могат да бъдат от помощ при дебъгване на проблеми в кода. Те помагат да определите къде нещо е било въведено и кой го е въвел.
git bisect е много полезен инструмент за дебъгване, използва се за да определим кой специфичен къмит първи е въвел определена грешка в кода чрез автоматично двоично търсене.
Среща се в ch07-git-tools.asc, където е обяснен напълно.
Командата git blame анотира редовете на произволен файл с информация за това кой къмит последно е направил промяна по тях и кой е разработчика направил промените.
Това е удобно, когато трябва да намерите човека, когото да питате за повече информация по специфична секция от кода.
Среща се единствено в ch07-git-tools.asc.
Командата git grep може да използвате за да търсите за произволен стринг или регулярен израз в произволен файл от кода, дори и в по-стари версии на проекта.
Използваме я единствено в ch07-git-tools.asc.
Има няколко команди в Git обединени около концепцията да възприемаме къмитите от гледна точка на това какви промени въвеждат, тоест като серия от пачове. Тези команди помагат да управлявате клоновете си в подобен маниер.
git cherry-pick взема промяната въведена в единичен къмит и се опитва да я въведе наново като нов къмит в текущия клон.
Това може да е полезно в случай, че искате да вземете един или два къмита индивидуално от даден клон вместо да го слеете целия, което взема всичките му промени.
Cherry picking процесът е обяснен и демонстриран в ch05-distributed-git.asc.
Командата git rebase в общи линии е автоматична версия на cherry-pick.
Тя определя серия от къмити и след това ги cherry-pick-ва един по един в същия ред на друго място.
Пребазирането е разгледано в детайли в ch03-git-branching.asc, където освен това обръщаме внимание на възможните проблеми, които възникват в резултат на пребазиране на вече публикувани клонове.
Използваме я също в примера за разделяне на историята в две отделни хранилища в ch07-git-tools.asc с помощта на флага --onto.
Разглеждаме и ситуации, при които може да се окажем в merge конфликт по време на пребазиране в ch07-git-tools.asc.
Използваме я в интерактивен скриптов режим с опцията -i в ch07-git-tools.asc.
Командата git revert по същество е обратна на git cherry-pick.
Тя създава нов къмит, който прилага точно обратното на промените въведени в посочения къмит и реално ги отменя.
Използваме я във ch07-git-tools.asc за да отменим merge къмит.
Много Git проекти, включително и самия Git, се поддържат през мейлинг листи. Git разполага с вградени инструменти за улеснение на процеса — от такива за генериране на пачове, които можете да изпратите по пощата, до такива за прилагане на пачовете от имейл съобщение.
git apply прилага пач създаден с git diff или дори с GNU diff командите.
Тя е подобна на възможностите на patch командата с някои малки разлики.
Демонстрирахме я и показахме при какви обстоятелства е подходяща в ch05-distributed-git.asc.
Командата git am се използва за прилагане на пачове от email inbox с mbox формат.
Полезна е за получаване и лесно прилагане на пачове по имейл.
Видяхме използването ѝ и възможна работна последователност в ch05-distributed-git.asc включително с опциите ѝ --resolved, -i и -3.
Съществуват също няколко hooks, които може да използвате в помощ на работния процес с git am, разгледани са в ch08-customizing-git.asc.
Също така я използваме за прилагане на форматирани като пач GitHub Pull Request промени в ch06-github.asc.
git format-patch се използва за генериране на серии от пачове в mbox формат, които може да използвате за изпращане към мейлинг лист със съответното коректно форматиране.
Разгледахме пример за сътрудничество в проект с git format-patch инструмента в ch05-distributed-git.asc.
git imap-send командата качва информация генерирана с git format-patch в IMAP drafts папка.
Видяхме пример за сътрудничество в проект чрез изпращане на пачове с git imap-send в ch05-distributed-git.asc.
git send-email се използва за изпращане по имейл на пачове генерирани с git format-patch.
Отново, пример за сътрудничество по проект с нейна помощ разгледахме в ch05-distributed-git.asc.
Командата git request-pull просто генерира примерно тяло на имейл съобщение, което може да изпратите някому.
Ако имате клон на публичен сървър и искате да покажете на някого как да интегрира промените ви без изпращане на пачове по имейл, може да изпълните тази команда и да изпратите изхода ѝ до колегата.
Демонстрирахме това генерирайки pull message в ch05-distributed-git.asc.
Git има няколко команди подпомагащи интеграцията с други version control системи.
git svn се използва за комуникация със Subversion като клиент.
Това значи, че може да използвате Git за да извличате съдържание и да изпращате къмити към Subversion сървър.
Командата е подробно разгледана в ch09-git-and-other-systems.asc.
За други видове системи или за импорт от почти всякакъв формат, може да използвате git fast-import, която бързо преработва чуждия формат до нещо, което Git може лесно да запише.
Разглеждаме я в ch09-git-and-other-systems.asc.
Ако администрирате Git хранилище или трябва да поправите нещо по драстичен начин, ето какви команди са налични.
git gc изпълнява “garbage collection” процедури върху вашето хранилище премахвайки ненужни файлове от базата данни и пакетирайки останалите файлове в по-ефективен формат.
Тя нормално работи незабележимо на заден план, въпреки че може да се пуска и ръчно, ако желаете. Видяхме някои примери в 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-systems.asc я използваме за коригиране на импортирани външни хранилища.
В книгата използвахме и доста на брой команди от по-ниско ниво, plumbing командите.
Първата такава беше ls-remote в ch06-github.asc, за разглеждане на raw референциите на сървъра.
Използвахме ls-files в ch07-git-tools.asc, ch07-git-tools.asc и ch07-git-tools.asc за да видим как изглежда индексната област в по-суров вид.
Споменахме rev-parse в ch07-git-tools.asc. С нея видяхме как да превърнем всеки стринг в SHA-1 хеш на Git обект.
Повечето low level plumbing команди са в ch10-git-internals.asc, цялата глава е малко или много посветена на тях. В останалите части на книгата умишлено се старахме да не ги използваме.