A1.4 Приложение C: Git команди - Клонове и сливане

git branch по същество е инструмент за управление на клоновете в Git. Може да създава, изброява, изтрива и преименува клонове.

Повечето от написаното в Клонове в Git е посветено на branch командата и тя се използва в цялата глава. Първо я представихме в Създаване на ново разклонение и преминахме през повечето ѝ възможности (печатане и изтриване) в Управление на клонове.

В Проследяване на клонове използваме git branch -u за да укажем tracking клон.

Последно, погледнахме какво прави тя на заден план в Git референции.

Командата git checkout се използва за превключване на клонове и за извличане на съдържание в работната директория.

За пръв път я срещнахме в Превключване на разклонения заедно с командата git branch.

Видяхме как да я използваме за да започнем да следим клонове с флага --track в Проследяване на клонове.

Използваме я за повторно въвеждане на конфликти във файлове с опцията --conflict=diff3 в Извличане на конфликти.

Навлизаме в по-дълбоки подробности за връзката ѝ с git reset в Мистерията на командата Reset.

Детайли по имплементацията ѝ показахме в HEAD.

Инструментът git merge се използва за сливане на един или повече клонове в клона, който е текущо извлечен. След сливането, текущият клон се премества напред с резултата от сливането.

Командата git merge видяхме за пръв път в Основи на разклоняването. Въпреки, че се използва на различни места в книгата, тя има много малко на брой вариации — в общи линии само git merge <branch> с името на единичен клон, който искаме да слеем.

Видяхме как се прави squashed сливане (където Git слива работата, но го прави под формата на единичен обединяващ къмит, вместо да записва цялата история на сливащия се клон) в края на [_public_project].

Преминахме през доста детайли по merge процеса и самата команда, включително -Xignore-space-change командата и флага --abort за отказ на проблематично сливане в Сливане за напреднали.

Видяхме как да проверяваме сигнатури преди сливане, ако проектът ви използва GPG подписване в Подписване на къмити.

Накрая научихме за Subtree сливането в Subtree сливане.

Командата git mergetool служи за стартиране на външен merge helper в случай, че не харесвате вграденото сливане в Git.

Погледнахме го набързо в Конфликти при сливане и навлязохме в детайли за това как да имплементирате собствен външен merge tool във Външни Merge и Diff инструменти.

Командата git log се използва за показване на достъпна записана история на проект от най-късно записания къмит snapshot назад. Тя по подразбиране ще покаже само историята на текущия клон, но може да ѝ се подадат различни или дори повече heads или клонове, от които да трасира. Също често се използва за показване на разлики между два или повече клона на ниво къмит.

Тази команда се среща в почти всяка глава в книгата за демонстрация на различни аспекти от историята на проект.

Представихме я първо в Преглед на историята на действията. Там разгледахме аргументите ѝ -p и --stat за да получим представа какво е било въведено във всеки къмит, както и --pretty и --oneline опциите за да видим историята по-стегнато заедно с някои прости опции за филтриране по дата и автор.

В Създаване на ново разклонение я използваме с аргумента --decorate за лесно визуализиране на това къде сочат указателите на клоновете, а също и с опцията --graph за да видим как изглеждат разклонени истории.

В [_private_team] и Обхвати от къмити обяснихме синтаксиса branchA..branchB за да инструктираме git log да намери кои къмити са уникални за даден клон в сравнение с друг клон. В Обхвати от къмити разгледахме това сравнително обстойно.

В Дневник на сливанията и Три точки използваме формата branchA…​branchB и --left-right синтаксиса, за да видим какво е налично в един от двата клона, но не и в двата едновременно. В Дневник на сливанията също видяхме как да използваме --merge опцията за помощ при изследване на merge конфликти, както и --cc опцията за търсене на merge commit конфликти в историята.

В RefLog съкратени имена демонстрирахме флага -g за да видим Git reflog-а през този инструмент вместо да правим branch traversal.

В Търсене използвахме флаговете -S и -L за търсене на неща, които са се случили хронологично в кода във времето, например историята на дадена функция.

В Подписване на къмити виждаме как да използваме --show-signature за да добавим верификационен стринг към всеки къмит в изхода от git log в зависимост от това дали той е валидно подписан или не.

Командата git stash се използва за временно съхранение/скриване на некъмитната работа с цел да се изчисти работната директория без да е необходимо къмитване на недовършената работа в клона.

Това е обяснено изцяло в Stashing и Cleaning.

git tag командата предоставя възможност за създаване на перманентен маркер (bookmark) към специфична точка в историята на кода. В общи линии се използва за маркиране на неща от рода на releases.

Тази команда е представена и разгледана в подробности в Тагове в Git и я използваме в действие в Тагване на версии.

Погледнахме как да създадем GPG signed таг с флага -s и също така как да проверим такъв с -v в Подписване на вашата работа.