Упродовж книги ми використовували десятки команд Git і посилено намагалися представляти їх з примітками, поступово знайомити вас з новими командами. Втім, це призвело до того, що приклади використання команд дещо розкидані по всій книзі.
У цьому додатку, ми переглянемо всі команди Git, до яких зверталися протягом книги, грубо згруповані за призначенням. Ми поговоримо про те, що кожна команда робить дуже загально та вкажемо де в книзі ви можете знайти її використання.
Існує дві команди, які були дуже вживані, від перших викликів 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 ми використали її, щоб налаштувати типове збереження ваших паролів HTTP.
У ch08-customizing-git.asc ми показали, як налаштувати фільтри smudge (забруднити) та clean (очистити) для вмісту, що приходить з Git та йде від нього.
Нарешті, фактично весь ch08-customizing-git.asc присвячено цій команді.
Команда git help призначена для відображення документації, що постачається разом з Git для кожної команди.
Хоча ми даємо деякий огляд більшості з більш поширених команд у цьому додатку, для повного списку всіх можливих опцій кожної команди, ви завжди можете виконати git help <команда>.
Ми представили команду 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 насправді є чимось на кшталт обгортки над декількома іншими командами.
Вона створює нову директорію, переходить до неї та виконує git init, щоб зробити порожнє сховище Git, додає віддалене сховище (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 ми використовуємо її для розпакування запакованого (bundled) сховища Git.
Нарешті, у ch07-git-tools.asc ми дізнаємося про опцію --recurse-submodules, щоб зробити клонування сховища з підмодулями трохи простішим.
Хоча її використано в багатьох інших місцях книги, це ті з них, в яких є щось особливе або де вона використовується в трохи інший спосіб.
Для базового процесу роботи індексування вмісту та збереження його в комітах вашої історії, є лише декілька базових команд.
Команда git add додає вміст з робочої директорії до індексу (чи області додавання) для наступного коміту.
Коли виконується команда git commit, типово вона дивиться лише на індекс, отже git add використовується для підготовки того, яким саме ви бажаєте зробити наступний відбиток коміту.
Ця команда неймовірно важлива в 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 status розглянуто там.
Команда git diff використовується, коли ви бажаєте побачити різницю між якимись двома деревами.
Це може бути різниця між вашим робочим середовищем та індексом (просто git diff), між вашим індексом та останнім комітом (git diff --staged), або між двома комітами (git diff master branchB).
Ми вперше бачимо базове використання git diff у ch02-git-basics-chapter.asc, де ми показуємо, як дізнатись, які зміни індексовані, а які ще ні.
Ми використовуємо її, щоб побачити можливі проблеми з пробільними символами перед створенням коміту за допомогою опції --check у ch05-distributed-git.asc.
Ми бачимо як перевірити різницю між гілками ефективніше за допомогою синтаксису git diff A…B у ch05-distributed-git.asc.
Ми дізнаємось, як ігнорувати різницю в пробільних символах за допомогою -b та як порівняти стани конфліктних файлів за допомогою --theirs, --ours та --base у ch07-git-tools.asc.
Нарешті, ми використовуємо її для ефективного порівняння змін у підмодулях за допомогою --submodule у ch07-git-tools.asc.
Команда git difftool просто запускає зовнішній інструмент, щоб показати вам різницю між двома гілками у випадку, якщо ви бажаєте використати щось інше, ніж вбудовану команду git diff.
Ми лише коротко згадуємо про це в ch02-git-basics-chapter.asc.
Команда git commit бере вміст всіх файлів, які ви індексували командою git add, та записує новий сталий відбиток до бази даних, а потім пересуває вказівник поточної гілки до нього.
Спочатку ми розглядаємо базове створення комітів у 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 переважно використовується для скасування речей, як ви напевно можете здогадатись через дієслово 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, яка в деякій мірі є обгорткою для команди git reset.
Команда git rm використовується для вилучення файлів з індексу та робочої директорії Git.
Вона схожа на git add в тому, що індексує вилучення файлу для наступного коміту.
Ми розглядаємо команду git rm дещо детальніше в 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 використовується для вилучення небажаних файлів з вашої робочої директорії.
Це може включати вилучення тимчасових результатів збірки, чи файлів конфлікту злиття.
Ми розглядаємо багато опцій та випадків, в яких ви можете використати команду 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.
Ми бачимо як її використати для початку слідкування за гілками за допомогою опції --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.
Хоча ми її використовували в різних місцях книги, є лише декілька варіацій команди merge — зазвичай просто git merge <гілка> з назвою єдиної гілки, яку ви бажаєте злити.
Ми розглянули як робити зварене злиття (коли Git зливає роботу, проте вдає ніби це просто новий коміт без запису історії гілки, яку ви зливаєте) наприкінці ch05-distributed-git.asc.
Ми розповіли чимало про процес зливання та цю команду, включно з командою -Xignore-space-change та опцією --abort, щоб припинити проблемне зливання в ch07-git-tools.asc.
Ми дізнались як перевірити підписи перед зливанням, якщо ваш проект використовує підписи GPG у ch07-git-tools.asc.
Нарешті, ми дізнались про зливання піддерев у ch07-git-tools.asc.
Команда git mergetool просто запускає зовнішній помічник зливання у випадку, якщо у вас проблеми зі зливанням у Git.
Ми нашвидку згадуємо її в ch03-git-branching.asc та детально розглядаємо як написати свій власний інструмент для зовнішнього злиття в ch08-customizing-git.asc.
Команда git log використовується, щоб показати досяжну записану історію проекту, починаючи з останнього відбитку коміту у зворотному порядку.
Типово вона покаже лише історію поточної гілки, проте ви можете надати їй інше чи навіть декілька посилань чи гілок, які треба обійти.
Вона також часто використовується, щоб показати різницю між двома чи більше гілками на рівні комітів.
Ця команда використовується майже в кожному розділі цієї книги, щоб продемонструвати історію проекту.
Ми представляємо команду та доволі глибоко розглядаємо її в 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, щоб допомогти з дослідженням конфліктів злиття, а також опцію --cc, щоб бачити конфлікти комітів злиття у вашій історії.
У ch07-git-tools.asc ми використовуємо опцію -g, щоб переглянути журнал посилань Git за допомогою цього інструменту замість обходу гілки.
У ch07-git-tools.asc ми бачимо використання опцій -S та -L для доволі витончених пошуків чогось, що сталось колись у коді, наприклад, щоб побачити історію функції.
У ch07-git-tools.asc ми бачимо, як використати --show-signature, щоб додати перевірочний рядок до кожного коміту у виводі git log, в залежності від того, правильно його підписано чи ні.
Команда git stash використовується для тимчасового збереження роботи поза комітом, щоб очистити робочу директорії без необхідності створювати коміт з незавершеною роботою в гілці.
Вона повністю розглянута в ch07-git-tools.asc.
Команда git tag використовується, щоб створити сталу закладку на окремий момент в історії коду.
Зазвичай, це використовується для речей, на кшталт видань (release).
Ця команда представлена та детально розглянута в ch02-git-basics-chapter.asc, та ми використовуємо її на практиці в ch05-distributed-git.asc.
Ми також розглядаємо, як створити підписаний GPG теґ за допомогою опції -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 та бачимо як отримувати зміни з пакунка в ch07-git-tools.asc.
Ми налаштовуємо дуже нетипові специфікації посилань, щоб змусити git fetch робити щось трохи інше, ніж типова поведінка, у ch10-git-internals.asc.
Команда git pull є загалом комбінацією git fetch та git merge, тобто Git отримає зміни зі заданого віддаленого сховища, а потім одразу спробує злити їх до поточної гілки.
Ми швидко представляємо її в ch02-git-basics-chapter.asc та показуємо, як побачити що буде злито при виконанні в ch02-git-basics-chapter.asc.
Ми також бачимо як використати її, щоб допомогти зі складнощами перебазування в ch03-git-branching.asc.
Ми показуємо як використати її з URL, щоб отримати зміни одноразово в 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 ми бачимо, як налаштувати відслідковувані гілки для автоматичного надсилання до них змін.
У ch03-git-branching.asc ми використовуємо опцію --delete, щоб вилучити гілку на сервері за допомогою git push.
Упродовж ch05-distributed-git.asc ми бачимо декілька прикладів використання git push для розподілення роботи над гілками з декількома віддаленими сховищами.
Ми бачимо, як використати її для надсилання теґів, які ми створили, за допомогою опції --tags у ch02-git-basics-chapter.asc.
У ch07-git-tools.asc ми використовуємо опцію --recurse-submodules, щоб переконатись, що вся праця в наших підмодулях була опублікована перед надсиланням надпроекту, що може бути дуже корисним, коли ви використовуєте підмодулі.
У ch08-customizing-git.asc ми коротко згадуємо про гак pre-push, який є скриптом, який виконується перед тим, як завершується push, щоб перевірити, чи варто дозволяти це надсилання.
Нарешті, у ch10-git-internals.asc ми дивимось на надсилання з повною специфікацією посилань замість загальних скорочень, які, зазвичай, використовуються. Це може допомогти вам дуже чітко надіслати саме ту роботу, яку ви бажаєте.
Команда git remote є командою для керування записів про ваші віддалені сховища.
Вона дозволяє вам зберігати довгі URL як короткі назви, на кшталт `origin'', щоб ви не мусили постійно набирати їх повністю.
Ви можете мати декілька таких, та команда `git remote використовується для їх додавання, зміни та вилучення.
Ця команда докладно розглянута в ch02-git-basics-chapter.asc, включно з наданням списку, доданням, вилученням та перейменуванням їх.
Вона використовується майже в кожному подальшому розділі книги, проте завжди у звичайному форматі git remote add <назва> <url>.
Команда git archive використовується для створення файлу архіву з окремим відбитком проекту.
Ми використовуємо git archive, щоб створити архів tar проекту для того, щоб ним поділитися, у 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.
Команда git shortlog використовується для підсумування виводу git log.
Вона приймає багато з опцій, які розуміє команда git log, проте, замість наведення списку всіх комітів, вона видає підсумок комітів, згрупованих за автором.
Ми показували, як використати її для створення гарного журналу змін (changelog) у ch05-distributed-git.asc.
Команда git describe використовується, щоб взяти будь-що, що призводить до коміту, та виготовляє рядок, який певною мірою читабельний та не зміниться.
Це спосіб отримати опис коміту, який не менш однозначний, ніж 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 використовується, щоб взяти впроваджені в одному коміті Git зміни, та спробувати застосувати їх як новий коміт на поточній гілці.
Це може бути корисним лише щоб взяти один чи два коміти з гілки окремо замість зливання гілки, що призведе до надбання всіх змін з неї.
Висмикування (cherry picking) описано та продемонстровано в ch05-distributed-git.asc.
Команда git rebase загалом є автоматизованим cherry-pick.
Вона визначає послідовність комітів, а потім висмикує їх один за одним у тому ж порядку звідкілясь.
Перебазування докладно розглянуто в ch03-git-branching.asc, включно з проблемами співпраці, повʼязаними з перебазуванням гілок, які вже стали публічними.
Ми використовуємо її на практиці під час прикладу розбиття нашої історії на два окремих репозиторії в ch07-git-tools.asc, також використовуючи опцію --onto.
Ми зустрілись з конфліктом злиття під час перебазування в ch07-git-tools.asc.
Ми також використовували її в інтерактивному скриптованому режимі за допомогою опції -i у ch07-git-tools.asc.
Команда git revert по суті є git cherry-pick навиворіт.
Вона створює новий коміт, який застосовує точну протилежність впроваджених цільовим комітом змін, по суті скасовуючи чи вивертаючи їх.
Ми використовуємо це в ch07-git-tools.asc, щоб скасувати коміт злиття.
Багато проектів Git, включно зі самим Git, супроводжуються цілковито через поштові розсилання. Git має чимало вбудованих інструментів, щоб зробити цей процес легшим, від створення латок, які легко можна передати поштою до застосування цих латок прямо з поштової скриньки.
Команда git apply застосовує латку, створену за допомогою git diff чи навіть командою GNU diff.
Вона схожа на те, що може зробити команда patch, з декількома маленькими відмінностями.
Ми демонструємо її використання та обставини, в яких ви можете забажати це робити в ch05-distributed-git.asc.
Команда git am використовується для застосування латок з поштової скриньки, лише тих, що у форматі mbox.
Це корисно для легкого отримання латок через пошту та застосування їх до проекту.
Ми розглянули використання та процес роботи навколо git am у ch05-distributed-git.asc, включно з використанням опцій --resolved, -i та -3.
Існує також декілька гаків, які ви можете використати, щоб допомогти з процесом роботи навколо git am, усі вони розглянуті в ch08-customizing-git.asc.
Ми також використовували її, щоб застосувати зміни з Pull Request сайту GitHub у форматі латки в ch06-github.asc.
Команда git format-patch використовується для генерації послідовності латок у форматі mbox, які ви можете використати для надсилання до поштової розсилки в правильному форматі.
Ми розглядаємо приклад внеску до проекту, що використовує інструмент git format-patch, у ch05-distributed-git.asc.
Команда git imap-send відвантажує згенерований за допомогою git format-patch mailbox до директорії чернеток (drafts) IMAP.
Ми розглядаємо приклад додання внеску до проекту, для чого надсилаємо латки інструментом git imap-send, у ch05-distributed-git.asc.
Команда git send-email використовується для надсилання латок, що були згенеровані за допомогою git format-patch, поштою.
Ми розглядаємо приклад внеску до проекту за допомогою надсилання латок командою git send-email у ch05-distributed-git.asc.
Команда git request-pull використовується просто щоб згенерувати приклад тіла поштового повідомлення до когось.
Якщо у вас є гілка на публічному сервері та ви бажаєте повідомити комусь, як інтегрувати ці зміни без надсилання латок поштою, то можете виконати цю команду та надіслати її вивід до людини, що ви бажаєте щоб вона втягнула (pull) ці зміни.
Ми демонструємо як використовувати git request-pull для генерації повідомлення про втягування в ch05-distributed-git.asc.
Git має декілька команд для інтеграції з іншими системами керування версіями.
Команда git svn використовується для взаємодії зі системою керування версіями Subversion у ролі клієнта.
Це означає, що ви можете використовувати Git для отримання з та надсилання до сервера Subversion.
Ця команда докладно розглянута в ch09-git-and-other-systems.asc.
Для інших систем керування версіями чи імпортування з майже будь-якого формату, ви можете використати git fast-import, щоб швидко перетворити інший формат на щось, що Git може легко записати.
Ця команда докладно розглянута в ch09-git-and-other-systems.asc.
Якщо ви є адміністратором сховища Git, чи вам вкрай необхідно виправити щось, Git надає чимало команд для адміністрування, які можуть вам допомогти.
Команда git gc виконує збирання сміття (garbage collection) у вашому сховищі: вилучає непотрібні файли з бази даних та спаковує решту файлів до ефектівнішого формату.
Ця команда зазвичай виконується у фоні, хоча ви можете виконати її вручну, якщо є бажання. Ми розглядаємо деякі приклади цього в ch10-git-internals.asc.
Команда git fsck використовується для перевірки внутрішньої бази даних: чи є там проблеми або суперечності.
Ми лише швидко використовуємо її один раз у ch10-git-internals.asc для пошуку висячих обʼєктів.
Команда 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 та ch09-git-and-other-systems.asc ми використовуємо її для виправлення імпортованих ззовні сховищ.
Існує доволі багато кухонних команд нижчого рівня, які ми зустрічаємо в книзі.
Спершу ми зустрічаємо ls-remote в ch06-github.asc, яку ми використовуємо, щоб подивитись на сирі посилання на сервері.
Ми використовуємо ls-files у ch07-git-tools.asc, ch07-git-tools.asc та ch07-git-tools.asc, щоб подивитись більш низькорівнево, як виглядає індекс.
Ми також згадуємо rev-parse у ch07-git-tools.asc, щоб взяти майже будь-який рядок та перетворити його на SHA-1 обʼєкту.
Втім, більшість низькорівневих кухонних команд ми розглядаємо в ch10-git-internals.asc, на чому цей розділ більш менш зосереджено. Ми намагались уникнути використання цих команд впродовж більшої частини решти книги.