Git
Chapters ▾ 2nd Edition

9.1 Приложение A: Git в други среди - Графични интерфейси

Ако сте прочели цялата книга сте научили много за използването на Git от командния ред. Можете да работите с локалните си файлове, да свързвате хранилището си с отдалечени такива през мрежа, да работите ефективно с колегите си. Но историята не свършва тук. Git често се използва като част от по-големи екосистеми и терминалът не винаги е най-добрия начин за работа. Сега ще разгледаме няколко работни среди, в които Git може да е полезна и също как други приложения (вкл. вашите) работят в синхрон с Git.

Графични интерфейси

Нативната среда на Git е терминала. Новите функционалности се появяват първо там и само командния ред е мястото, където Git ви предоставя пълната си сила. Но чистият текст не винаги е подходящия избор за всички задачи, понякога визуалното представяне е необходимо и отделно от това има много потребители, които се чувстват по-комфортно с мишката.

Важно е да посочим, че различните интерфейси са проектирани за различни работни процеси. Някои клиенти дават достъп само до внимателно подбрано подмножество от функционалностите на Git с цел да подпомогнат специфичен начин на работа, който авторът на интерфейса намира за ефективен. Погледнато от този аспект, никой от тези инструменти не може да се нарече “по-добър” от кой да е друг, те просто са фокусирани за конкретна цел. Също така подчертаваме, че няма дейност извършвана от графичните клиенти, която да не може да се реализира в команден ред.

gitk и git-gui

Когато инсталирате Git, получавате неговите визуални инструменти gitk и git-gui.

gitk е графичен инструмент за разглеждане на историята. Мислете за него като за мощен GUI заместител на git log и git grep. Това е инструментът, който ви трябва, ако се опитвате да намерите нещо случило се в миналото или искате да визуализирате историята на проекта.

Gitk най-лесно се стартира от командния ред. Просто влезте в Git хранилище и изпълнете:

$ gitk [git log options]

Gitk приема много аргументи от командния ред, повечето от които се изпращат към съответните git log операции. Един от най-полезните е флагът --all, който инструктира gitk да показва къмитите достъпни от всяка референция, не само от HEAD. Интерфейсът изглежда така:

`gitk` history viewer
Фигура 151. gitk history viewer

Най-отгоре виждаме нещо наподобяващо изхода на git log --graph, всяка точка представлява къмит, линиите показват родителските връзки и референциите се показват като оцветени кутии. Жълтата точка представя HEAD, а червената точка са промените, които все още не са къмитнати. В долния край имате преглед на избрания къмит, коментарите и пача отляво и обобщение вдясно. Между тези две секции има колекция от контроли за търсене в историята.

git-gui, от друга страна, е предимно инструмент за работа с къмити. И той се стартира най-лесно от конзолата:

$ git gui

И изглежда така:

git-gui commit tool image::images/git-gui.png[git-gui commit tool]

Отляво на екрана виждаме неиндексираните промени отгоре, под тях са индексираните. Можете да местите цели файлове между двете области щраквайки върху иконите им или можете да изберете файл за преглед като щракнете върху името му.

Горе вдясно е diff изгледът, който показва промените по текущо селектирания файл. Можете да индексирате индивидуални hunks (или отделни редове) с дясно щракване в тази област.

Долу вдясно е областта за дейности и съобщения. Напишете съобщението си в кутията и натиснете “Commit” за да направите нещо подобно на git commit. Можете също да изберете да откажете последния къмит с радио бутона “Amend”, което ще опресни областта “Staged Changes” със съдържанието му. След това можете просто да индексирате и деиндексирате някои промени, да промените къмит съобщението и да натиснете бутона “Commit” повторно, за да замените стария къмит с нов.

gitk и git-gui са примери за task-oriented инструменти. Всеки от тях е насочен към специфична задача (съответно за преглед на история и промяна на къмити) и не предлагат функционалности, които не я засягат.

GitHub за macOS и Windows

GitHub предоставя два workflow-ориентирани Git клиента, по един за Windows и macOS. Тези клиенти са добър пример за workflow-ориентирани инструменти — вместо да предоставят цялата Git функционалност, те са фокусирани върху подбрани части от нея, които работят добре заедно и които потребителите често използват. Те изглеждат така:

GitHub for macOS
Фигура 152. GitHub за macOS
GitHub for Windows
Фигура 153. GitHub за Windows.

Проектирани са да изглеждат и работят почти еднакво, така че ще ги разгледаме като един продукт. Няма да навлизаме в детайли (имат подробна документация), а ще разгледаме набързо изгледа “changes” (в който ще прекарвате повечето си време).

  • Вляво са хранилищата, които клиентът следи; можете да добавяте хранилища (с клониране или локално прикачване) с иконата “+” в горния край.

  • В центъра е commit-input областта, която позволява да въведете къмит съобщение и да изберете кои файлове да се включат. Под Windows, историята на къмитите се показва директно отдолу, под macOS е в отделен таб.

  • В дясно е diff изгледа, който показва промените в работната директория или кои промени са включени в избрания къмит.

  • Последно имаме бутон “Sync” в горната дясна част, който е основния начин за комуникация през мрежата.

Забележка

Не се нуждаете от GitHub акаунт за да ползвате тези програми. Въпреки, че са проектирани да се възползват максимално добре от услугите на GitHub и препоръчвания от него тип работен процес, те ще си работят добре с всяко хранилище и ще контактуват по мрежата с всеки Git хост.

Инсталация

GitHub for Windows може да се изтегли от https://windows.github.com, а GitHub for macOS от https://mac.github.com. При първото им стартиране приложенията ви водят през първоначална настройка на Git, вкл. конфигуриране на вашето име и имейл адрес, след което задават много настройки по подразбиране като credential кеширането и CRLF обработката.

И двете са винаги актуални - обновяванията им се издърпват и инсталират на заден план докато приложението работи. Тъй като включват и вградена версия на Git, тя също автоматично се обновява и няма нужда да го правите на ръка. Под Windows, клиентът включва shortcut за стартиране на PowerShell с Posh-git, за който ще говорим малко по-късно.

Следващата стъпка е да дадете на приложенията хранилища, с които да работят. Те ви показват списък с хранилищата ви в GitHub и ви позволяват да ги клонирате в една стъпка. Ако имате локално хранилище, просто издърпайте с мишката директорията му от Finder или Windows Explorer в клиентския прозорец на програмата и то ще бъде добавено към списъка с хранилища вляво.

Препоръчителен работен процес

Веднъж инсталиран и конфигуриран, GitHub клиентът може да се използва за много ежедневни Git задачи. Заложеният работен процес понякога се нарича “GitHub Flow.” Вече разгледахме това в Работния процес в GitHub, като цяло идеята е (a) да къмитвате в клон, и (b) да синхронизирате с отдалечено хранилище сравнително редовно.

Управлението на клоновете е една от областите, в които двете версии се различават. В Mac, имате бутон за създаване на нов клон в горната част:

“Create Branch” бутон под macOS
Фигура 154. “Create Branch” бутон под macOS

Под Windows, това се прави като напишете името на новия клон в branch-switching уиджета:

Създаване на клон под Windows
Фигура 155. Създаване на клон под Windows

След като клонът е създаден, правенето на нови къмити е сравнително лесно. Направете някакви промени в работната директория и когато се върнете в прозореца на GitHub клиента, той ще ви покаже кои файлове са били променени. Въвеждате къмит съобщение, избирате файловете, които искате да бъдат включени и натискате бутона “Commit” (ctrl-enter или ⌘-enter).

Основният начин, по който контакувате с други хранилища през мрежата е чрез функцията “Sync”. Git вътрешно си има отделни операции за публикуване, издърпване, сливане и пребазиране, но GitHub клиентите ги обединяват в единична функция с няколко стъпки. Ето какво се случва, когато натиснете бутона Sync:

  1. git pull --rebase. Ако това не успее поради merge конфликт, тогава алтернативата е git pull --no-rebase.

  2. git push.

Това е най-често срещаната последователност от действия при работа в такъв стил, така че обединяването на командите в една спестява много време.

Обобщение

Тези инструменти са много добре окомплектовани за работния процес, за който са проектирани. Те позволяват бързо изграждане на механизъм за съвместна работа между разработчици и странични лица при съблюдаване на добрите практики. Обаче, ако вашият работен процес е различен или пък искате повече контрол върху мрежовите операции, бихме препоръчали друг клиент или директно командния ред.

Други графични инструменти

Съществуват множество други графични Git клиенти, при това с широк диапазон от функционалности — от тясно специализирани върху конкретни дейности до такива, които се опитват да въплатят всичко, което Git поддържа. Официалният сайт на Git съдържа списък с най-популярните клиенти на адрес https://git-scm.com/downloads/guis. Още по-пълен списък е наличен от Git wiki сайта на адрес https://git.wiki.kernel.org/index.php/Interfaces,_frontends,_and_tools#Graphical_Interfaces.

scroll-to-top