Въведение в системата за контрол на версиите на GIT

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

Какво е и защо версия Controller?

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

Сценарий №1

Представете си екип от петима членове, които работят върху основния изходен код, подобряващ различни функции към него. Помислете само как могат да работят върху един и същ изходен код, без да се объркват промените помежду си? Всеки трябва да знае какво правят другите четирима и не трябва да има небрежност към него. И до края на работния час те трябва да прекарат известно време, координирайки се взаимно, така че най-сетне да се поддържа един изходен код. Изглежда доста забързано и определено ръчната намеса при поддържането на изходния код е по-рискована. За да помогнем или да кажем, за да автоматизираме всички тези версии, върху които работят всичките петима програмисти, се нуждаем от правилно написан контролер на версиите и GIT е една от тях. Има термин за горните стъпки и се нарича Управление на изходния код или Управление на конфигурацията на софтуера (SCM).

Сценарий №2

Сега помислете за още един сценарий, при който автоматизацията на контролерите на версиите помага. Написахме първата версия на кода и клиентът е одобрил да го инсталира на производство, това е версия 1.0. Сега след няколко месеца клиентът предлага работа по усъвършенстване и вие работите върху по-рано написаното, за да разработите версия 1.1 и да я представите на клиента. Но клиентът предлага различен подход и тази версия 1.1 не е полезна за вас според новия подход на клиента. Така че изхвърляте това и работите върху версия 1.2, която се изпраща и одобрява. И така продължавате да работите в разработването на различни версии. Но не мислите ли, че ръчното запазване на всички версии някъде и поддържането на изходния код не е объркано? В даден момент може да се наложи да препратите версия 1.1, която сте изхвърлили и нямате удобна.

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

Различни видове контролер на версиите

Налични са различни видове инструменти, а по-долу са някои от тях

  1. Subversion - Тъй като е разработен от Apache, използван широко от доставчиците на Apache.
  2. Git
  3. базар
  4. находчив

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

Централизирана система за контрол на версиите (CVCS) Разпределена система за контрол на версиите (DVCS)

1. CVCS

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

2. DVCS

Тук също имаме изходния код на сървъра, но заедно с това го имаме и като локално копие на работещи машини. Така че дори ако има грешка на ниво сървър, можем да отгледаме обратно локалното работно копие на сървъра, когато то бъде възстановено. Това наличие на локално работно копие на всяка машина, отговорна за термина „Dsistriibuted“ в DVCS. Git, Mercurial използва разпределена система за контрол на версиите

Git използва концепцията за разклоняване или по-технически наричана TBD, базирана на trunk. Това, което всъщност означава, е, че можем да създадем няколко клона от главния и на тези клонове програмистите могат да работят и да извършват промените си в тези клонове и всеки от тях се проследява. И след като клиентите одобрят, можем да обединим всички клонове към основния код в производството. По този начин не влияят директно на основния изходен код. Работата директно върху основния изходен код ще бъде по-рискована и трябва да се избягва. Можем да работим по клонове и да изпълняваме различни сценарии за тестване и след като окончателната версия е стабилизирана и одобрена, можем да работим върху обединяването й, което намалява риска със значителна сума.

Git всъщност е безплатен и за потребители на Mac, той е достъпен по подразбиране. В Linux можем да инсталираме git, а за Windows имаме нещо, Git Bash. Има два най-популярни източника на хранилище, където можем да работим с Git, а те са Git Hub и Bit Bucket и организация, избрала да се основава на предпочитанията си.

Предимства на системата за управление на версиите GIT

  • Поддържа както наследствената форма на развитие, която е линейна, така и нелинейна форма на развитие
  • Тъй като се разпространява в природата, по-малко се притеснявайте при грешки в един точков сървър. Винаги можем да отгледаме обратно кода от локалното репо на сървъра.
  • Можем също така да внедрим защитен слой отгоре на git, който може да назначи ограничения на достъпа при издърпване и натискане.
  • Може да работи на множество платформи като Mac, Linux, Windows и т.н.
  • Абсолютно безплатно и с отворен код
  • Ефективен и бърз поради разпределения характер
  • Ясно проследяване на ангажименти, актуализации, ревертиране, версии, натискане и изтегляне
  • Предоставя GitBash за прозорци, които са лесни за използване.
  • Има и различни GUI, които могат да работят над GIT
  • Тя не изисква активна мрежова връзка винаги, тъй като наличието на локалното хранилище.

Работа с Git

  • Създайте работещия клон от главния източник или от друг клон в зависимост от изискването
  • Клонирайте клона на локално с помощта на GitBash за Windows
  • Работете върху клона и изпълнявайте модификации или добавяне на компоненти към него
  • Ангажирайте промените и направете проследяване на ангажиране
  • Ако смятате, че ангажиментът е ненужен, можете да го върнете към по-ранния
  • Ако няколко програмисти работят в един и същ клон, локалното репо трябва да бъде актуализирано, преди да натиснете промените. Затова изпълнете PULL
  • Сега ще можете да изпълнявате PUSH
  • След като прегледът и одобрението на кода направят на вашия клон, тогава можем да преместим кода на производство или чрез ansible или по какъвто и да е начин, по който организацията използва.
  • Обединете клона към Главния, така че да имаме актуализиран код в него.

Git е най-често използваната система за контрол на разпределените версии поради своя разпределен характер, няма нито една точка на повреда и е с отворен код. Можете да опитате да работите с него, като използвате примерен код в GitHub и GitBash в Windows PC, тъй като git командите са прости и лесно достъпни онлайн.

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

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

  1. GIT Команди
  2. Въведение в GIT
  3. Git Алтернативи
  4. Какво е Git?
  5. Версии на Tableau
  6. Git Origin Master
  7. Какво е Hub?
  8. Три етапа от жизнения цикъл на Git с работния процес
  9. Как да използвате GIT Cherry-pick с пример?

Категория:

Голяма информация