За какво се използва Git и какви са ползите му?

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

🔗 Какво е Git? | Help

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

Ако не пишете код и нямате намерение да го правите, но създавате и работите с текст, тогава ще Ви е интересно да знаете, че Git работи и следи промените в съдържанието именно на текстови файлове.

Git следи за промени по редовете в текстовия файл, независимо какво е съдържанието му – код, текст, числа, символи, всичко, което може да се запише в текстов формат

Кодът и текстът се съдържат в обикновени текстови файлове.
Кодът и текстът се съдържат в обикновени текстови файлове.

Поради това в тази статия ще говорим за ползите от Git и където е възможно ще правим аналогия на „работата с код“ и „работата с обикновен текст“, например при редактиране на статия. 

Ползите от Git

Отзивите за Git от разработчиците са само положителни. Харесва им скоростта, с която работи, и начина му за следене на промените по кода. Чувстват се спокойни от сигурността му, от гледна точка на целостта на данните, и естествения бекъп на кода, който може да „върнат“ при нужда.

Поради всичките си ползи Git се използва от стотици хиляди разработчици. А Stack Overflow е един от най-известните портали за разработчици, в който споделят опит и намират помощ за казусите, с които се сблъскват всеки ден. Всяка година Stack Overflow прави проучване сред потребителите на портала, за да види кои инструменти и технологии използват.

В проучване на Stack Overflow от 2018 г. са участвали над 74 хиляди потребители на портала. Почти 90% от тях са отговорили, че инструментът за контрол на версиите на кода, който използват, е Git.

Някои от ползите са резултат от сравняването на Git с други системи за контрол на версиите, които са централизирани като Subversion и CVS. Например по-бързата му работа и по-ефективният и лек подход за разклоняване и сливане (branching, merging).

Съвместна работа и сътрудничество (collaboration)

Първата и основна полза от Git е присъща за всички системи за контрол на версиите. Това е възможността за промяна на едни и същи файлове от повече от един човек, без да се създават несъответствия и конфликти в съдържанието им. Например няколко човека извършват промяна в текста на една статия, като го подобряват и допълват. Но когато публикуват своите промени, те се добавят или сливат в статията, без да се създава конфликт в съдържанието ѝ.

Ако го сравним със статиите, съвместната работа може да е – множество автори допринасят за подобряването на една и съща статия, но не като променят цялото ѝ съдържание наведнъж, а като всеки автор променя един определен абзац от нея. Може да го подобрява като изказ, да го разширява и допълва, да го видоизменя.

Съвместната работа и споделеното допринасяне за разработката и подобряването на кода е в основата на Open Source идеята. Поради това Git се използва предимно от проекти с отворен код, към които безвъзмездно допринасят много хора. Ако сте голям фен например на WordPress като нас, не Ви ли е идвало наум нещо от сорта на „ех, ако можех да кодя, щях да направя нещо, да върна към WordPress обществото, което ми дава толкова много“? 🙂 Основното хранилище за кода на WordPress не използва Git, а Subversion, но това по никакъв начин не е попречило за огромния брой доброволци разработчици.

Групиране на промени преди публикуването им (staging)

Къмитът (commit) в Git е действието, с което в Git хранилището се публикуват промените по съдържанието на файловете. Ако промяната е в един файл, можем да го сравним с това да запишем промените, които сме направили в една статия. Къмитът е все едно кликване на бутона „Обновяване“ в WordPress редактора или „Запазване“ в MS Word.

Но преди да публикуваме промените, можем да ги подберем.

Git позволява публикуването на промените да е обособено по тема. Всеки къмит може да съдържа промени, които принадлежат на една тема, но се съдържат в отделни и различни файлове. За тази цел се използва staging пространството. Файловете с промените, които ще бъдат публикувани, се поставят в статус „staged“. Това е нещо като да запишем чернова на промените, които сме направили в няколко статии, преди да ги публикуваме. Например в няколко статии има препратка към друг сайт, чийто уеб адрес вече не е актуален. Променяме уеб адреса, като го актуализираме в тези отделни статии, и записваме „чернова“ на тези промени (черновата на промените в Git се нарича „добавяне в индекса“). Тази чернова с промени след това ще публикуваме с едно действие – къмит (публикуване, запазване). Така съдържанието на статиите ще бъде обновено наведнъж.

В представите на Git това публикуване е едно действие, на което можем да поставим и бележка с описание „Линкът към Х е актуализиран“. Тоест причината за промените е една и това е „темата“ на къмита. Това прави процесът по разработка на съдържанието/кода кристално ясен. Можем след това да проследим къмитите и да видим какво, как, от кого, кога и защо е променено.

Да се върнем към коденето. Ето пример за същото, но при разработката на приложение. Например, ако правим поправка на „bug#123“, което изисква множество промени по кода сред различни файлове, всички тези промени може да са в един къмит. Това ще позволи лесно проследяване на промените само за тази задача. Можем да опишем къмита като „fixed bug#123“. Ако срещнем в бъдеще подобен бъг, можем да разгледаме в детайли как е оправен стария. Друга съществена полза от публикуване на обособени промени е, че при нужда може да се върне предишното състояние на кода само за дадената разработка. Ако къмитът съдържа миксирани промени от различни теми, например за „компонент А“ и за „компонент Б“, при проблем в единия компонент, ще трябва се върнат промените и в двата компонента. 

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

Без хаос и страх от експериментиране (branching)

Дори в най-малките проекти разработчиците често се налага да работят върху множество компоненти и задачи паралелно например „feature X“, „feature Y“, „bug#123“ и други. Ако всички започнат да правят промени директно в основния код на проекта, това ще доведе до хаос, трудно проследяване и връщане на отделните разработки.

Вместо това, всеки компонент и задача се разработва в отделен клон – branch (разклонение) на основния код. Разклонението в Git се базира на последната активна версия на основния код и позволява разработката да продължи в различна посока.

Всеки от разработчиците е клонирал Git хранилището на проекта локално на неговото устройство. По този начин всеки един разполага с основния master клон и с пълната история на промените по целия код (и реално бекъп на целия код). От този основен клон се прави разклонение, по което се извършват промените в кода. 

Новият клон например „feature-x“ е един вид прототип. Докато един разработчик работи по „feature-x“, нищо и никой не е засегнат от неговия незавършен код. Ако се окаже, че този компонент всъщност не е нужен или пък след 10-тия къмит се установи, че пътят е грешен, разработчикът може да създаде лесно ново разклонение и да тръгне по друг път.

Ако пренесем тази концепция за разработка в сферата на текстовото съдържание на статиите, това означава, че всеки автор ще има локално копие на основния клон и историята на съдържанието на всички статии в сайта. Съдържанието може да се намира в текстови файлове, като всяка статия е в отделен текстов файл. Според целите, всеки автор може да създава обособен клон, по който да работи, без това да засегне актуалното съдържание в публикуваната статия. Например създава разклонение „update-post-x”, в което започва да прави корекции по съдържанието на статията X. Стига донякъде, но вижда, че посоката в редакцията не е правилна, но създаденото дотук не е за изхвърляне. Затова създава ново разклонение и започва начисто, докато старото си стои запазено от Git, и ако пожелае, може да се върне към него.

Тук ще добавим и процеса на Git за предотвратяване на конфликти в съдържанието. 

Говорим за статии. Например авторът, който си е създал разклонението „update-post-x”, нанася корекции по съдържанието на статията X. През това време друг автор прави промени по същата статия и ги публикува в сайта. След като вторият автор е готов, пуска заявка за сливане (merge) на неговия клон (update-post-x) в основния клон (master). При опит за сливане на промените Git проверява за конфликт във версиите, като следи за припокриване на промени по отделните редове. Ако открие застъпване във версиите ще индикира към автора и ще му покаже кой точно ред и как се различава в неговата версия и във вече записаната от другия автор. Тъй като първият автор е направил промяна само по ред 128, а вторият автор е правил промяна само по първия ред в статията, Git слива промените без проблем. В реална обстановка и с правилен подход към тематични промени, възможността двама автори да изпълняват една и съща задача върху едно и също съдържание е минимална. Ако това се случи, най-малкото ще означава, че работният процес за управление на съдържанието не е ефективен. Например не е практика двама автори да имат една и съща задача – да ревизират съдържанието на една и съща статия, поне не докато се знае, че единият от тях е отговорник за задачата.

Git насърчава креативността и експериментирането в разработката, като премахва страха от това, че основната версия на проекта ще бъде засегната, докато опитваш нови неща. Предоставя среда, в която можеш уверено да пробваш и развиваш бъдещ компонент към проекта.

Връщаш промени, отменяш грешки

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

Възможността за отмяна (подобно на „undo“) дава на екипа куража да опитва нови идеи и концепции, без риск да счупят нещо, което в замяна отглежда култура на иновациите.

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

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

Ако го сравним със статиите, връщането на промени е все едно да върнете предишната ревизия на съдържанието.

Още ползи

Спестява време

Git е светкавично бърз. Това се усеща най-добре от разработчиците, които сменят централизирана система за контрол на версиите с Git. Бързината на Git радва особено ако преди това сте използвали друга система за контрол на версиите и се е налагало да изчаквате по няколко секунди или минути за „качването“ на поредния Ви запис в централното хранилище, което е на отдалечен сървър. Това ни довежда до следващата полза.

Работите офлайн

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

Има ползи от това разработчиците да могат да работят офлайн. Възможността да „кодят“ на лаптопа си, без да са свързани със сървърите на компанията, не е само за да могат да работят от вкъщи. По-важното е, че възможността да работят „изключени“ от работата, прави екипът по надежден и безотказен. Докато например със CVS разработчикът не може да продължи неговата работа, ако централното хранилище не е достъпно.

Широко използван

Git се използва все повече и повече от големи и малки компании и Open Source проекти. Голямата общност към инструмента за контрол на версиите има много предимства. Част от тях са – огромно количество ръководства, помощни статии, инструменти, интеграции и услуги.

Популярността на Git се измерва предимно от използването му за проектите с отворен код. Git платформите като GitHub, GitLab и Bitbucket предоставят свободен начин за всеки да си направи Git хранилище.

Git е интегриран в различни инструменти, които се използват от разработчиците:

Поддръжка на Git във Visual Studio Code.
Поддръжка на Git във Visual Studio Code.

Git хранилище в хостинг акаунта

Git е интегриран и в хостинг услугите. Можете да използвате Git за управление на версиите на Вашите текстови файлове или файлове с код в Git хранилище в хостинг акаунта Ви. С опцията Git Version Control в cPanel можете да създадете хранилище, в което да издърпвате (pull) или подавате (push) промени.

На всички хостинг услуги в СуперХостинг.БГ, при които се предлага SSH достъп, можете да създадете и използвате Git хранилище. cPanel Git хранилището може да се свърже с локалното хранилище на Вашето устройство или пък с отдалечено такова в GitHub, GitLab, Bitbucket.

Ето няколко примера за използване на Git хранилището в хостинг акаунта.

Публикуване на приложение

Разработката на приложението може да използва уеб хранилище като GitHub или друго, а публикуването на промените в проекта да се случва в хостинг акаунта. Например създали сте проект, който искате да видите как работи в реална уеб среда – издърпвате промените в cPanel от отдалеченото хранилище и ги качвате (deploy) автоматично или ръчно в публичната директория на сайта.

Статичен сайт за документация или портфолио

Разработчиците работят с код, но и често те може да са хората, които създават помощната документация за проекта или приложението си. Какво ще предпочете един човек, който е свикнал да борави с код и да не използва мишката – високата ефективност и бързина от този начин на работа или кликането на бутони? Прекрасният интерфейс на готовите CMS платформи не могат да го изкушат, защото ще трябва да жертва бързината и ефективността на работата си.

Това е причината много помощни документации към разработките да се създават и намират в статични сайтове. Разработчикът пише текста за помощната статия така, сякаш е код, в текстов файл. А Git е идеалният инструмент за версиите на това съдържание, защото работи с текстови файлове.

Съдържанието в текстовите файлове често е написано в някакъв лек маркиращ език като Markdown или reStructuredText

Системата на статичния сайт, която може да се намира в хостинг акаунта, преобразува съдържанието от текстовите файлове в HTML страници. Само един пример за такъв сайт: https://www.gatsbyjs.com/docs/.

Има ли друго полезно приложение на Git хранилището в хостинг акаунта, което сте открили?
0
За какво друго използвате Git хранилището в cPanel?x

Как да използвате Git?

Ако сега започвате с Git, първо разгледайте и се запознайте с основните му команди и понятия. Създайте Git хранилище на Вашето устройство и след това създайте Git хранилище в хостинг акаунта, в което да публикувате промените по разработките си.

Ето от къде можете да започнете:

  1. 🔗 Първи стъпки в Git | Blog
  2. 🔗 Основни Git понятия и команди | Help
  3. 🔗 Създаване на локално Git хранилище на Вашето устройство (Windows) | Help
  4. 🔗 Създаване на Git хранилище в cPanel | Help

Още помощни ресурси за Git в хостинг акаунта ще намерите в помощната ни страница:

🔗 Категория Git | Help

Заключение

Използването на Git има много ползи като възможността за съвместна и безпроблемна работа по един проект, извършване на тематични промени, свобода за експериментиране и детайлна история на процеса – кой, кога, какво и защо.

На практика всичко, което може да се представи в текстова форма, би могло да използва Git за контрол на версиите. Например можем да управляваме документацията като код, а в DevOps (разработка и операции) средите се говори вече и за инфраструктура като код и всичко като код. Тази тема определено си заслужава да се следи за развитие! Надяваме се, че скоро няма да чуем за емоции като код, защото от това ни побиват роботски тръпки. 🙂

Абонирайте се за СуперБлога, за да научавате първи най-важното и полезното от света на уеб, касаещо Вашия сайт и дигитално развитие.

Мадлена Методиева
Мадлена Методиева
Меган е част от СуперМаркетинг екипа. Мисията ѝ е старателно да попълва е-библиотеката на СуперХостинг.БГ с полезни и помощни статии.
5 1 vote
.
Абониране
Уведоми ме при
guest

0 Коментара
Inline Feedbacks
View all comments
3 стъпки за органично бизнес онлайн присъствие

3 стъпки за органично бизнес онлайн присъствие [Аудио]

2
Под „органично присъствие“ имаме предвид всички начини, чрез които потребителите могат да разберат за Вашия бизнес, без да плащате за позициониране (реклама).
6 причини за съобщение Internal Server Error 500

6 причини за съобщение Internal Server Error 500 [Аудио]

11
Причините за генерирането на това съобщение може да са най-различни - некоректно изпълняващ се скрипт в сайта, некоректни права на файлове и директории и други

Бизнес планиране в 3 стъпки – какво, как и защо?

4
Време е да се фокусирате върху бизнес планирането през предстоящата 2023 г. Предлагаме няколко основни стъпки, с които ще ускорите и улесните този процес.