В последните няколко години използването на Git се увеличи значително, популяризирайки разпределените version control системи (от английски version control systems или още VCS). Според проучване, направено в Eclipse обществото, за първи път през 2014 Git е бил най-разпространеният избор за VCS при Java разработчиците.
Хостинг платформи като GitHub и Bitbucket направиха разпределените VCS възможни, като предоставиха удобно хостинг пространство и различни инструменти на разработчиците. Microsoft зададе Git като доставчика на version control по подразбиране за нови проекти в TFS платформата си и така силно насърчи разработчиците да използват Git, освен ако нямат специална нужда от централизиран VCS. Но как по-популярните VCS са съпоставими с имплементацията на feature branch модела и удобството за работа, което предоставят?
Избор на VCS, подходяща за нуждите ви
Когато екип започва работа по нов проект или достигне до повратна точка в съществуващ такъв, изникват няколко въпроса: Дали текущата VCS работи добре? Какви са разликите между Git и SVN?
В този пост са разгледани три от най-популярните version control системи – Git, SVN и Mercurial. От идеологична гледна точка, Mercurial и Git попадат в една и съща категория – на разпределените системи. Кои са големите разлики обаче и защо ние избрахме Git?
Разпределени срещу централизирани VCS
Исторически първи се появяват централизираните version control системи, с RCS през 1982 и нейният наследник CVS през 1987 година. В момента едни от най-известните централизирани version control системи са Subversion, TFVC, Perforce and Clearcase. Използвайки тези системи, разработчиците достъпват едно централно repository. Ако бъдат направени промени, те ще достигнат до всеки разработчик преди той/ тя да може да commit-не собствените си промени и, за съжаление, това включва и неработещ код. При наличието на единствено “истинско” repository, работата офлайн може да бъде предизвикателство. За да могат да бъдат изпълнени базови операции, като преглед на историята или commit-ване на кода, е необходим достъп до това repository.
Една от първите разпределени VCS е Bitkeeper (1997). В момента най-популярните такива системи са Git, GNU Arch и Mercurial. В разпределения модел всеки разработчик има собствено копие на repository-то. Използвайки този модел, разработчиците могат да работят офлайн – могат да commit-ват, създават нови или обединяват branch-ове, да виждат история и всичко друго, от което се нуждаят, след като имат имат цялото repository под ръка. Достъп до интернет е нужен само когато е необходима синхронизация с другите членове на екипа.
Разлики между Mercurial и Git
Основните разлики между Mercurial и Git са две:
Монолитност: Mercurial e монолитно приложение, докато Git, следвайки Linux идеологията, идва под формата на няколко малки бинарни файла, които често остават скрити за разработчика. Притежавайки фини инструменти, с които да бъде модифициран, Git става изключително гъвкав, което може да бъде решаващо за имплементацията на нестандартни решения.
Преглед на историята: Другата разлика между Mercurial и Git e как боравят с историята. Git позволява (някой дори биха казали насърчава) потребителите да пренапишат историята на своето repository, когато пожелаят. Това им позволява да запазят опростени и логически структурирани commit логовe, вместо да обхващат цялата история в последователността, в която се е случила. С голямата мощ идва и голяма отговорност, така че такива пренаписвания трябва да стават само в локални commit-и.
В крайна сметка, двете системи много си приличат. Много от стандартните функционалности на Git са предоставени под формата на плъгини за Mercurial. Feature Branch моделът може да бъде реализиран лесно както в Git, така и в Mercurial.
Предимства и недостатъци на имплементацията на Feature Branch Development процес с Git
Създаването на branch-ове в VCS като цяло ни позволява да създадем виртуално копие на кода, позволяващо ни да направим промени по него, без да засягаме оригиналния код. Във feature branch модела е необходимо да направим отделен branch за всяка нова функционалност, което има няколко важни предимства:
Предимство: Лесни Code Review-та преди сливането на кода
Code review-тата са страхотни – те правят кода стандартизиран, като запазват същия стил на писане и намаляват нуждата от refactoring. Понякога в code review-тата могат да бъдат открити бъгове още преди проблемът да достигне до фазата на тестване (QA), спестявайки ценно време от процеса по разработка.
Предимство: По-добър контрол върху източника
Това, което прави feature request подхода толкова популярен, е изолацията, която той предоставя. Кодът за създаването на нови функционалности е отделен от общия код и се слива с него едва когато те са напълно готови и тествани. Въпрекi че SVN предлага branching, временните branch-ве се използват само за по-големи функционалности заради имплементанционния детайл, че всеки branch в SVN създава копие на кода. При големи проекти това е неефективно и бавно.
Предимство: Лесна смяна на задачи
Често разработчиците имат нужда да преустановят работата по определени проблеми или временно да започнат работа по друга задача. Нека предположим, че разработчик работи по даден проблем от седмица, когато се налага да бъде направена важна доработка на кода на production. Разбира се, той може да направи SVN patch или да изтегли наново кода в нова локация, но тези заобиколни начини за решаване ще струват време и ако се ползват често могат да бъдат дразнещи. Използвайки branch-per-feature workflow, цялата работа може да бъде свършена с временен commit и смяна на branch-a.
Предимство: По-добър release процес
Feature branch-овете работят добре с популярния Git Flow, който взима предвид всички възможни сценарии като hotfix-ове, code freezing и други.
Недостатък: Сложен History Log
Минусите произлизат от допълнителните стъпки, които разработчиците трябва да изпълнят, като например това, че трябва да се убедят, че branch-ват от правилния commit. Разчитайки на обединяването на завършените issues, history log-ът може да стане по-голям и по-труден за разбиране.
Разлики между Git и SVN
Една от най-видимите разлики при преминаването към Git е неговата скорост. След като цялото repository се съхранява локално на машината на разработчика, той/ тя може да работи дни с много слаба интернет връзка. Създаването на branch-ове е изключително бързо заради избраната branch имплементация от Git. В Git branch-ът е просто референция към commit, където следващите commit-ти да бъдат прикачени, и не съдържа обща информация като дата на създаване, потребителят, който я е създал, или каквото и да е друго съобщение.
След като Git насърчава използването на branch-oве, няма как да пропуснем да споменем и merge функционалностите му. Преди 1.5 версията на SVN бяха възможни само двустранни (two-way) merges, които включваха промени, приложени към текущата база, защото не съществуваше възможност да бъде съхранявана merge информация. Git използва repository историята, за да идентифицира common базата между слетите branch-oве и има нужда да merge-не само различните, изпълнявайки тристранен (three-way) merge. SVN също подобрява възможностите си и поддържа тристранен merging още от 1.5 версията си, а в новата версия 1.9 се поддържа и по-добро преименуване и местене на файловете – нещо, което Git притежава отдавна.
Интеграция с друг софтуер
SVN съществува от повече от 15 години и благодарение на популярността си има интеграция на повечето от съвременните integration сървъри, issue tracking системи, IDE и други. Разглеждайки разликите между Git и SVN, въпреки че Git e пуснат 5 години по-късно, в никакъв случай не може да се каже, че изостава от SVN. Git e лесен за интеграция с друг софтуер. Той предоставя единствено command line инструменти, но съществуват и много допълнителни UI инструменти, създадени от компании като Atlassian’s SourceTree, Github, Git Extensions и други.
Преминавайки към Git
Претегляйки разликите между Git и SVN, Git има няколко минуса, измежду които и по-дългият процес по навлизане за работа със системата. Ако разработчиците са работили само с централизиран VCS до момента, може да им отнеме малко повече време да разберат как да се справят с различията, като процеса по синхронизиране или допълнителната стъпка, когато става дума за създаване на commit. Както вече споменахме, има множество GUI приложения, които могат да улеснят работата на разработчиците и, ако е нужно, да предоставят command line интерфейс за случайте, в които са необходими по-сложни команди.
Все още не сте готови да се прехвърлите на Git, но искате да използвате feature branch методологията?
Git предоставя инструмент, наречен git-svn, който позволява проследяване (tracking) на стандартен subversion repository и осигурява двупосочен поток от промени между тях. С него вие имате възможност да работите с feature branches и да синхронизирате с branch от SVN хранилището, когато е необходимо. Всичко това не влияе на екипа, тъй като само разработчика знае кога използва локалното Git хранилище. Microsoft приеха подобен подход с TFS, като предоставиха git-tf инструмент, който позволява да се следи TFS repository. Въпреки това улеснение, feature branch модела не се използва в пълния си потенциал, тъй като едната от основните му сили е интеграцията му с GitFlow процеса.
Feature branch-овете предоставят изолация и удобство. Благодарение на вътрешната имплементация на Git създаването на branch-oве, една от скъпите операции в SVN, е на практика “безплатна”. Това позволява незабавно създаване и изчистване на временните branch-ове, за да се създават нови функционалности.
