Как да изберем модел на разклонение в Git, библиотека на програмиста
И така, искате да използвате git, за да контролирате версии на текущия или бъдещия си проект, но нямате идея откъде да започнете? Започнете с нашата статия.
Има много начини да използвате git за проект, както и да си сътрудничите с други разработчици. В допълнение към използването на git за управление на версии на кода на вашия проект, той може да се използва за координиране на начина, по който другите работят по проект. Това може да бъде постигнато най-ефективно чрез използване на модел на разклоняване.
Работният поток, който е моделът за разклоняване в git, е практика, която опростява работата по проект. Неговата цел е да организира, добави и публикува промени в изходния код на хранилището. Най-ефективният начин за проекти е да има отдалечено хранилище. Моделът на разклоняване не е правило, което трябва да се следва, а по-скоро ръководство. Следователно можете просто да изберете определени аспекти и да ги комбинирате според нуждите си.
За тази статия, нека приемем, че вашият клон е главен и че сте запознати с основните git термини (клон, фиксиране, обединяване, изтегляне на заявка, кръпка, разклонение, хранилище) или можете да ги потърсите в Google.
Ето няколко модела за разклоняване, които може да помислите за използване във вашия проект. За всеки от тях са описани същността на работата и целта на приложението.
Хранилището съдържа само един главен клон. Всички промени са ангажирани с него. Хранилището може да бъде локално, без отдалечени копия или да се съхранява дистанционно, където може да бъде клонирано или изтласкано.
Кога да се използва
Идеален за самостоятелен проект. Във вашия проект можете да използвате този модел, за да видите какви промени са настъпили по време на процеса на разработка. След свършената работа ангажирате промените, за да можете по-късно да се върнете към някоя от предишните версии. Също така е чудесно за малки екипи, които са преминали от syn към git.
Кога да се използва
В най-простата си форма хранилището може да има главен клон със стабилен, лесно достъпен код и други клонове за различни функции (или грешки, или подобрения), които могат да бъдат интегрирани в главния клон. Тоест хранилището ще има вторичен основен клон (dev), който ще съхранява тествания стабилен код, за да бъде изпратен на потребителите при обединяване от master. В този случай клонът на характеристиките ще бъде обединен в dev, а не в master.