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

Освен това работата в разпределени екипи е възможна главно благодарение на тези инструменти. Те дават възможност на няколко души да работят по различни части на проект едновременно и по-късно обединяват резултатите си в един продукт. Нека разгледаме по-отблизо системите за контрол на версиите и да обясним как са възникнали базираните на багажника разработки и Git flow.

Как системите за контрол на версиите промениха света

Преди да бъдат създадени системите за контрол на версиите, хората разчитаха на ръчно архивиране на предишни версии на проекти. Те копираха модифицирани файлове на ръка, за да включат работата на множество разработчици по един и същ проект.

Това струва много време, място на твърдия диск и пари.

Когато ние погледнете историята , можем широко да разграничим три поколения софтуер за контрол на версиите.

Нека ги разгледаме:

Поколение	Операции	Съвпадение	Работа в мрежа	Примери
Първо	Само за един файл	Брави	Централизирано	RCS
Второ	На множество файлове	Обединяване преди фиксиране	Централизирано	Подриване, CVS
Трето	На множество файлове	Ангажиране преди сливане	Разпределени	Git, Mercurial

Забелязваме, че когато системите за контрол на версиите узреят, има тенденция да се увеличава способността за паралелна работа по проекти.

Една от най-новаторските промени беше преминаването от заключване на файлове към обединяване на промените вместо това. Това даде възможност на програмистите да работят по-ефективно.

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

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

Стилове на развитие

В днешно време най-популярната система за контрол на версиите определено е Git, с пазарен дял от около 70 процента през 2016 г.

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

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

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

Git е просто инструмент. Можете да го използвате по много различни начини. В момента два най-популярни стила на разработка, които можете да срещнете, са Git поток и разработка, базирана на багажника . Доста често хората са запознати с един от тези стилове и може да пренебрегнат другия.

Нека разгледаме по-отблизо и двамата и научете как и кога трябва да ги използваме.

Git Flow

В модела за развитие на Git flow имате един основен клон за развитие със строг достъп до него. Често се нарича develop клон.

Разработчиците създават функционални клонове от този основен клон и работят върху тях. След като приключат, те създават заявки за изтегляне. В заявките за изтегляне други разработчици коментират промени и може да водят дискусии, често доста продължителни.

Отнема известно време, за да се договори окончателна версия на промените. След като бъде договорено, заявката за изтегляне се приема и се обединява с основния клон. След като се реши, че основният клон е достигнал достатъчно зрялост, за да бъде освободен, се създава отделен клон, за да се подготви окончателната версия. Приложението от този клон е тествано и са приложени корекции на грешки до момента, в който е готово да бъде публикувано на крайните потребители. След като приключим, обединяваме крайния продукт в master клон и го маркирайте с версията за освобождаване. Междувременно на develop могат да се разработват нови функции клон.

По-долу можете да видите диаграма на потока на Git, изобразяваща общ работен процес:

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

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

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

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

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

Плюсове и минуси на Git Flow

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

Кога Git Flow работи най-добре?

• Когато стартирате проект с отворен код.
  Този стил идва от света с отворен код и там работи най-добре. Тъй като всеки може да допринесе, вие искате да имате много строг достъп до всички промени. Искате да можете да проверите всеки отделен ред код, защото честно казано не можете да се доверите на хората, които допринасят. Обикновено това не са търговски проекти, така че скоростта на развитие не е проблем.

• Когато имате много млади разработчици.
  Ако работите предимно с млади разработчици, тогава искате да имате начин да проверите работата им отблизо. Можете да им дадете няколко съвета как да правят нещата по-ефективно и да им помогнете да подобрят уменията си по-бързо. Хората, които приемат заявки за изтегляне, имат строг контрол върху повтарящите се промени, за да могат да предотвратят влошаване на качеството на кода.

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

Кога Git Flow може да причини проблеми?

• Когато тепърва стартирате.
  Ако тепърва стартирате, тогава Git flow не е за вас. Шансовете са, че искате бързо да създадете минимално жизнеспособен продукт. Извършването на заявки за изтегляне създава огромно затруднение, което забавя драстично целия екип. Просто не можете да си го позволите. Проблемът с Git flow е фактът, че заявките за изтегляне могат да отнемат много време. Просто не е възможно да се осигури бързо развитие по този начин.

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

• Когато работите предимно със старши разработчици.
  Ако вашият екип се състои главно от старши разработчици, които са работили помежду си за по-дълъг период от време, тогава всъщност нямате нужда от гореспоменатото микроуправление на заявки за изтегляне. Доверявате се на своите разработчици и знаете, че те са професионалисти. Оставете ги да си вършат работата и не ги забавяйте с цялата бюрокрация на Git flow.

Работен поток за разработка, базиран на транк

В базирания на ствол модел на разработка всички разработчици работят върху един клон с отворен достъп до него. Често това е просто master клон. Те ангажират код и го изпълняват. Това е супер просто.

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

Нека да разгледаме работния процес, базиран на магистрала.

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

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

Ако, от друга страна, нямате опитен екип или не им вярвате по някаква причина, не бива да използвате този метод - вместо това трябва да изберете Git flow. Ще ви спести излишни притеснения.

Плюсове и минуси на базираното на багажника развитие

Нека разгледаме по-отблизо и двете страни на разходите - най-добрите и най-лошите сценарии.

Кога разработката, базирана на транк, работи най-добре?

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

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

• Когато работите предимно със старши разработчици.
  Ако вашият екип се състои предимно от старши разработчици, тогава трябва да им се доверите и да ги оставите да си вършат работата. Този работен процес им дава автономията, от която се нуждаят, и им позволява да владеят своето майсторство в професията си. Просто им дайте цел (задачи за изпълнение) и наблюдавайте как расте вашият продукт.

Кога развитието, базирано на транк, може да причини проблеми?

• Когато стартирате проект с отворен код.
  Ако изпълнявате проект с отворен код, тогава Git flow е по-добрият вариант. Нуждаете се от много строг контрол върху промените и не можете да се доверите на сътрудници. В крайна сметка всеки може да допринесе. Включително онлайн тролове.

• Когато имате много млади разработчици.
  Ако наемате предимно млади разработчици, тогава е по-добра идея да контролирате плътно какво правят. Строгите заявки за изтегляне ще им помогнат да подобрят своите умения и ще открият потенциални грешки по-бързо.

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

Използвайте правилния инструмент за правилната работа

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

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

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

И все пак, ако работите с младши програмисти или хора, на които нямате пълно доверие, Git flow е много по-добра алтернатива.

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

Свързани: Обяснен подобрен Git Flow

Разбиране на основите

Какво представлява багажникът в софтуера?

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

Какво е разклоняване и сливане на код?

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

Какво е клон в контрола на версиите?

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

Какво е клон на характеристиките?

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

Какво представлява системата за контрол на версиите?

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