Файлдар нұсқаларын басқару қызметі

Файлдардың нұсқаларын басқару – бағдарламалық жасақтаманы дамытуда маңызды құрал. Кодты, құжаттарды өзгертулермен сақтауға көмектеседі. Версиялық басқару жүйелері туралы біліңіз.

18 мин оқу

100%

Дереккөз: Version control — Wikipedia

Ағылшыншамен салыстырыңыз: абзацты басыңыз — түпнұсқа терезеде ашылады. Абзац астындағы EN түймесі оны мәтін ішінде көрсетеді.

Мазмұны

Кіріспе

Файлдардың нұсқаларын басқару қызметі

Бағдарламалық жасақтауда нұсқаны басқару (сонымен қатар, түзетулерді басқару, бастапқы кодты басқару немесе кодты басқару деп те аталады) – компьютерлік файлдар мен файлдардың нұсқаларын басқару амалы. Файлдар көбінесе бастапқы кодтан құралған мәтіндік файлдар, бірақ кез келген файл түрі болуы мүмкін. Нұсқаны басқару – бағдарламалық жасақтама конфигурациясын басқарудың бір бөлігі. Нұсқаны басқару жүйесі – нұсқаны басқаруды автоматтандыратын бағдарламалық құрал. Сонымен қатар, нұсқаны басқару кейбір жүйелерде, мысалы, мәтін өңдегіштерде, электрондық кестелерде, бірлескен веб-документтерде және мазмұнды басқару жүйелерінде, мысалы, Wikipedia беттерінің тарихында мүмкіндік ретінде енгізілген. Нұсқаны басқару ескі нұсқаларды қарауға және файлды бұрынғы нұсқасына қайтаруға мүмкіндік береді.

Шолу

Командалар бағдарламалық жасақтаманы әзірлеген кезде, әртүрлі орындарда бір бағдарламалық жасақтаманың бірнеше нұсқасы орналастырылуы және әзірлеушілердің жаңартулар бойынша бір уақытта жұмыс істеуі жиі кездеседі. Бағдарламалық жасақтаманың қателер немесе мүмкіндіктері көбінесе тек белгілі бір нұсқаларда ғана болады (кейбір мәселелерді түзету және бағдарлама дамыған сайын басқаларын енгізу нәтижесінде). Сондықтан, қателерді табу және түзету үшін бағдарламалық жасақтаманың әртүрлі нұсқаларын қайтарып алу және іске қосу өте маңызды, соның арқылы проблема қай нұсқада пайда болғанын анықтауға болады. Бағдарламалық жасақтаманың екі нұсқасын бір уақытта әзірлеу қажет болуы мүмкін: мысалы, бір нұсқада қателер түзетілген, бірақ жаңа мүмкіндіктер жоқ (тарау), ал екінші нұсқада жаңа мүмкіндіктер жұмыс істеп жатыр (негізгі бағана). Ең қарапайым жағдайда, әзірлеушілер бағдарламаның әртүрлі нұсқаларының бірнеше көшірмесін сақтап, оларды тиісінше белгілей алады. Бұл қарапайым тәсіл көптеген ірі бағдарламалық жобаларда қолданылған. Бұл әдіс жұмыс істесе де, тиімді емес, себебі бағдарламаның көптеген дерлік бірдей көшірмелерін сақтау қажет. Бұл әзірлеушілерден жоғары деңгейде ұйымшылдық пен жауапкершілік талап етеді және көбінесе қателерге әкеледі. Код базасы бірдей болғандықтан, әзірлеушілерге оқу, жазу және орындау рұқсатын беру қажет, бұл код базасының бұзылуын болдырмау үшін рұқсаттарды басқаратын адамға қосымша жауапкершілік жүктеді, бұл күрделілікті арттырады. Осының салдарынан, қайта қарауды бақылау процесінің бір бөлігін немесе барлығын автоматтандыруға арналған жүйелер жасалды. Бұл нұсқаны басқару қадамдарының көпшілігін көзден жасырып, процесті жеңілдетеді. Сонымен қатар, бағдарламалық жасақтаманы әзірлеу, заңдық және бизнес тәжірибесі және басқа да салаларда, бір құжатты немесе кодтың бөлігін команда мүшелері өңдеуі жиі кездеседі, олардың мүшелері географиялық тұрғыдан шашырап, әртүрлі және тіпті қайшы мүдделерді көздеуі мүмкін. Мұндай жағдайларда, құжаттар мен кодтағы өзгерістердің меншік құқығын қадағалайтын және есепке алатын күрделі қайта қарау бақылауы өте пайдалы немесе тіпті қажет болуы мүмкін. Қайта қарауды басқару конфигурациялық файлдардағы өзгерістерді де қадағалай алады, мысалы, Unix жүйелерінде /etc немесе /usr/local/etc-те сақталатын файлдар. Бұл жүйе әкімшілеріне жасалған өзгерістерді оңай бақылауға және қажет болған жағдайда бұрынғы нұсқаларға оралуға мүмкіндік береді. Көптеген нұсқаны басқару жүйелері файлдың нұсқасын сан немесе әріп түрінде анықтайды, оны нұсқа нөмірі, нұсқа, қайта қарау нөмірі, қайта қарау немесе қайта қарау деңгейі деп атайды. Мысалы, файлдың алғашқы нұсқасы 1-ші нұсқа болуы мүмкін. Файл өзгертілгенде келесі нұсқасы 2 болады. Әр нұсқаға уақыт белгісі және өзгерісті жасаған адам қоса тіркеледі. Түзетулерді салыстыруға, қалпына келтіруге және кейбір файл түрлерін біріктіруге болады.

As teams develop software, it is common for multiple versions of the same software to be deployed in different sites and for the developers to work simultaneously on updates. Bugs or features of the software are often only present in certain versions (because of the fixing of some problems and the introduction of others as the program develops). Therefore, for the purposes of locating and fixing bugs, it is vitally important to be able to retrieve and run different versions of the software to determine in which version(s) the problem occurs. It may also be necessary to develop two versions of the software concurrently: for instance, where one version has bugs fixed, but no new features (branch), while the other version is where new features are worked on (trunk). At the simplest level, developers could simply retain multiple copies of the different versions of the program, and label them appropriately. This simple approach has been used in many large software projects. While this method can work, it is inefficient as many near identical copies of the program have to be maintained. This requires a lot of self discipline on the part of developers and often leads to mistakes. Since the code base is the same, it also requires granting read write execute permission to a set of developers, and this adds the pressure of someone managing permissions so that the code base is not compromised, which adds more complexity. Consequently, systems to automate some or all of the revision control process have been developed. This ensures that the majority of management of version control steps is hidden behind the scenes. Moreover, in software development, legal and business practice, and other environments, it has become increasingly common for a single document or snippet of code to be edited by a team, the members of which may be geographically dispersed and may pursue different and even contrary interests. Sophisticated revision control that tracks and accounts for ownership of changes to documents and code may be extremely helpful or even indispensable in such situations. Revision control may also track changes to configuration files, such as those typically stored in /etc or /usr/local/etc on Unix systems. This gives system administrators another way to easily track changes made and a way to roll back to earlier versions should the need arise. Many version control systems identify the version of a file as a number or letter, called the version number, version, revision number, revision, or revision level. For example, the first version of a file might be version 1. When the file is changed the next version is 2. Each version is associated with a timestamp and the person making the change. Revisions can be compared, restored, and, with some types of files, merged.

Тарих

IBM-нің OS/360 IEBUPDTE бағдарламалық жасақтаманы жаңарту құралы 1962 жылға дейін жетеді, және оны нұсқаны басқару жүйесі құралдарының алға құралы деп санауға болады. IBM 360/370 орналымдарында кеңінен қолданылған екі бастапқы кодты басқару және нұсқаны басқару жиынтығы The Librarian және Panvalet болды. 1972 жылы бастапқы кодты бақылауға арналған толық жүйе құрылды, осы жүйе үшін (OS/360) Бастапқы кодты бақылау жүйесі. 1975 жылдың 4 желтоқсанында жарияланған Бастапқы кодты бақылау жүйесінің пайда болуы, тарихи тұрғыдан алғанда, ол алғашқы мақсатты нұсқаны қайта қарауды басқару жүйесі екенін көрсетеді. RCS одан кейін желілік нұсқасы Concurrent Versions System арқылы пайда болды. Concurrent Versions System-нен кейінгі буын Subversion-мен басым болды, одан кейін Git сияқты таратылған нұсқаны қайта қарауды басқару құралдары пайда болды.

Құрылымы

Тексеруді басқару деректер жиынтығына уақыт өте келе енгізілген өзгерістерді басқарады. Бұл өзгерістер әртүрлі құрылымдарда болуы мүмкін. Көбінесе деректер көптеген жеке элементтер жиынтығы ретінде қарастырылады, мысалы файлдар немесе құжаттар, және жеке файлдарға енгізілген өзгерістер қадағаланады. Бұл жеке файлдар туралы түсінікке сәйкес келсе де, файлдарды қайта атау, бөлу немесе біріктіру сияқты жағдайда сәйкестік өзгергенде қиындықтар тудырады. Сондықтан, Git сияқты кейбір жүйелер деректерді тұтас ретінде өзгертуді қарастырады, бұл қарапайым өзгерістер үшін интуитивті болмаса да, күрделі өзгерістерді жеңілдетеді. Тексеруді басқару жүйесіндегі деректер тексерілгеннен кейін өзгертілгенде, бұл өзгеріс әдетте дереу репозиторийде көрінбейді, оның орнына тексеріліп немесе міндеттелген болуы керек. Тексеруді басқарудан тыс көшірме "жұмыс көшірмесі" деп аталады. Мысалы, компьютерлік файлды өңдеу кезінде өңдеу бағдарламасының жадында сақталған деректер жұмыс көшірмесі болып табылады, ол сақтау арқылы міндеттеледі. Конкретті мысал келтесек, құжатты басып шығарып, қолмен өңдеп, кейін өзгерістерді компьютерге қолмен енгізіп сақтауға болады. Бастапқы кодты басқару үшін жұмыс көшірмесі – әзірлеушінің компьютерінде жергілікті сақталатын белгілі бір нұсқадағы барлық файлдардың көшірмесі болып табылады. Бұл жағдайда файлды сақтау тек жұмыс көшірмесін өзгертеді, ал репозиторийге тексеру – жеке қадам. Егер бірнеше адам бір дерек жиынтығы немесе құжат бойынша жұмыс істесе, олар өз жұмыс көшірмелерінде деректердің тармақтарын жасап, біріктіру мәселелерін тудырады, бұл туралы төменде талқыланады. Қарапайым бірлескен құжат өңдеу үшін файлды құлыптау немесе басқа біреу жұмыс істеп жатқан құжатты өңдеуден аулақ болу арқылы бұған жол бермеуге болады. Тексеруді басқару жүйелері көбінесе орталықтандырылған болады, яғни деректерді сақтаудың жалғыз сенімді орны – репозиторий, және тексерулер мен міндеттемелер осы орталық репозиторийге сүйене отырып жасалады. Балама ретінде, таратылған тексеруді басқаруда ешқандай репозиторий сенімді болып табылмайды, және деректерді кез келген репозиторийге тексеруге және міндеттеуге болады. Басқа репозиторийге міндеттелгенде, бұл біріктіру немесе түзету ретінде қарастырылады.

Revision control manages changes to a set of data over time. These changes can be structured in various ways. Often the data is thought of as a collection of many individual items, such as files or documents, and changes to individual files are tracked. This accords with intuitions about separate files but causes problems when identity changes, such as during renaming, splitting or merging of files. Accordingly, some systems such as Git, instead consider changes to the data as a whole, which is less intuitive for simple changes but simplifies more complex changes. When data that is under revision control is modified, after being retrieved by checking out, this is not in general immediately reflected in the revision control system (in the repository), but must instead be checked in or committed. A copy outside revision control is known as a "working copy". As a simple example, when editing a computer file, the data stored in memory by the editing program is the working copy, which is committed by saving. Concretely, one may print out a document, edit it by hand, and only later manually input the changes into a computer and save it. For source code control, the working copy is instead a copy of all files in a particular revision, generally stored locally on the developer's computer; in this case saving the file only changes the working copy, and checking into the repository is a separate step. If multiple people are working on a single data set or document, they are implicitly creating branches of the data (in their working copies), and thus issues of merging arise, as discussed below. For simple collaborative document editing, this can be prevented by using file locking or simply avoiding working on the same document that someone else is working on. Revision control systems are often centralized, with a single authoritative data store, the repository, and check outs and check ins done with reference to this central repository. Alternatively, in distributed revision control, no single repository is authoritative, and data can be checked out and checked into any repository. When checking into a different repository, this is interpreted as a merge or patch.

Графиктің құрылымы

Граф теориясы тұрғысынан, түзетулер әдетте даму сызығы (ағаш діңі) ретінде қарастырылады, одан тармақтар бөлінеді, бағытталған ағаш құрайды, бір немесе бірнеше параллель даму сызықтары ("тармақтардың негізгі сызықтары") түрінде бейнеленеді. Шындығында құрылым күрделірек, бағытталған ациклді граф құрайды, бірақ көптеген жағдайларда "біріктірулері бар ағаш" жеткілікті жақындық береді. Түзетулер уақыт бойынша ретпен келеді, сондықтан оларды түзету нөмірімен немесе уақыт белгісімен ретке келтіруге болады. Түзетулер бұрынғы түзетулерге негізделген, бірақ бұрынғы түзетуді толығымен немесе жартылай ауыстыруға болады, мысалы, "барлық мәтінді өшіру, жаңа мәтін енгізу". Ең қарапайым жағдайда, тармақтану немесе кері қайтару болмаса, әр түзету тек тікелей алдыңғы нұсқасына негізделген, және олар бір ғана соңғы нұсқасы бар "HEAD" түзетуімен немесе ұшымен қарапайым сызық құрайды. Граф теориясы тұрғысынан, әр түзетуті нүкте ретінде, ал әр "туынды түзету" қатынасын жебе ретінде (әдетте ескіден жаңаға, уақыт бағытында) көрсетсек, бұл сызықтық граф болады. Егер тармақтану болса, яғни болашақтағы бірнеше түзетулер өткен түзетулерге негізделсе, немесе кері қайтару болса, яғни түзету тікелей алдыңғысынан ескірек түзетуге тәуелді болса, нәтижедегі граф бағытталған ағаш (әр түйінде бірнеше ұл болуы мүмкін) болады, және балалары жоқ түзетулерге сәйкес келетін бірнеше ұштары болады ("әр тармақтағы соңғы түзету"). Принцип бойынша, алынған ағашта ерекше ұш болуы міндетті емес ("негізгі" соңғы түзету), тек әртүрлі түзетулер ғана болады, бірақ практикада бір ұш әдетте HEAD ретінде анықталады. Жаңа түзету HEAD-ке негізделген кезде, ол жаңа HEAD ретінде анықталады немесе жаңа тармақ ретінде қарастырылады. Бастапқыдан HEAD-қа дейінгі түзетулер тізімі (граф теориясы тұрғысынан, ағаштағы бірегей жол, ол бұрынғыдай сызықтық граф құрайды) – түп немесе негізгі сызық. Керісінше, түзету бірнеше бұрынғы түзетулерге негізделген кезде (бір түйінде бірнеше ата-ана болуы мүмкін), нәтижедегі процесс біріктіру деп аталады, және түзетуді басқарудың ең күрделі аспектілерінің бірі болып табылады. Бұл көбінесе өзгерістер бірнеше тармақта (көбінесе екі, бірақ одан да көп болуы мүмкін) пайда болған кезде болады, содан кейін олар екі өзгерісті қамтитын бір тармаққа біріктіріледі. Егер бұл өзгерістер қабаттасса, біріктіру қиын немесе мүмкін емес болуы мүмкін, және қолмен түзетуді немесе қайта жазуды қажет етеді. Біріктірулер болған кезде, нәтижедегі граф енді ағаш емес, өйткені түйіндердің бірнеше ата-анасы болуы мүмкін, бірақ оның орнына тамырланған бағытталған ациклді граф (DAG) болады. Граф ациклді, өйткені ата-аналар әрқашан уақыт бойынша артқа қарай болады, және тамырланған, өйткені ең көне нұсқасы бар. Егер түп болса, тармақтардан біріктірулерді ағаштың "сыртқы" бөлігі деп қарастыруға болады – тармақтағы өзгерістер жапсырма ретінде жинақталады, ол HEAD-ке (түпкілікке) қолданылады, бұтаққа тікелей сілтемесіз жаңа түзету жасайды және ағаш құрылымын сақтайды. Осылайша, нұсқалар арасындағы нақты қатынастар DAG құраса да, оны ағаш плюс біріктірулер деп қарастыруға болады, ал түпкілік өзі – сызық. Бөлінген түзетуді басқаруда бірнеше репозиторийлер болған кезде, олар бір түпнұсқа нұсқаға (ағаш түбіріне) негізделген болуы мүмкін, бірақ түпнұсқа түбір міндетті емес, оның орнына әр репозиторий үшін жеке түбір (ең көне түзету) болуы мүмкін. Бұл, мысалы, екі адам бір жобада бөлек жұмыс істей бастаса, болуы мүмкін. Сол сияқты, деректерді алмасатын немесе біріктіретін бірнеше деректер жиынтығы (бірнеше жоба) болған кезде, бір түбір болмайды, бірақ қарапайымдық үшін бір жобаны негізгі, ал екіншісін екінші ретті деп қарастыруға болады, оны біріншісіне өз түзету тарихымен немесе онсыз біріктіруге болады.

In terms of graph theory, revisions are generally thought of as a line of development (the trunk) with branches off of this, forming a directed tree, visualized as one or more parallel lines of development (the "mainlines" of the branches) branching off a trunk. In reality the structure is more complicated, forming a directed acyclic graph, but for many purposes "tree with merges" is an adequate approximation. Revisions occur in sequence over time, and thus can be arranged in order, either by revision number or timestamp. Revisions are based on past revisions, though it is possible to largely or completely replace an earlier revision, such as "delete all existing text, insert new text". In the simplest case, with no branching or undoing, each revision is based on its immediate predecessor alone, and they form a simple line, with a single latest version, the "HEAD" revision or tip. In graph theory terms, drawing each revision as a point and each "derived revision" relationship as an arrow (conventionally pointing from older to newer, in the same direction as time), this is a linear graph. If there is branching, so multiple future revisions are based on a past revision, or undoing, so a revision can depend on a revision older than its immediate predecessor, then the resulting graph is instead a directed tree (each node can have more than one child), and has multiple tips, corresponding to the revisions without children ("latest revision on each branch"). In principle the resulting tree need not have a preferred tip ("main" latest revision) – just various different revisions – but in practice one tip is generally identified as HEAD. When a new revision is based on HEAD, it is either identified as the new HEAD, or considered a new branch. The list of revisions from the start to HEAD (in graph theory terms, the unique path in the tree, which forms a linear graph as before) is the trunk or mainline. Conversely, when a revision can be based on more than one previous revision (when a node can have more than one parent), the resulting process is called a merge, and is one of the most complex aspects of revision control. This most often occurs when changes occur in multiple branches (most often two, but more are possible), which are then merged into a single branch incorporating both changes. If these changes overlap, it may be difficult or impossible to merge, and require manual intervention or rewriting. In the presence of merges, the resulting graph is no longer a tree, as nodes can have multiple parents, but is instead a rooted directed acyclic graph (DAG). The graph is acyclic since parents are always backwards in time, and rooted because there is an oldest version. Assuming there is a trunk, merges from branches can be considered as "external" to the tree – the changes in the branch are packaged up as a patch, which is applied to HEAD (of the trunk), creating a new revision without any explicit reference to the branch, and preserving the tree structure. Thus, while the actual relations between versions form a DAG, this can be considered a tree plus merges, and the trunk itself is a line. In distributed revision control, in the presence of multiple repositories these may be based on a single original version (a root of the tree), but there need not be an original root instead there can be a separate root (oldest revision) for each repository. This can happen, for example, if two people start working on a project separately. Similarly, in the presence of multiple data sets (multiple projects) that exchange data or merge, there is no single root, though for simplicity one may think of one project as primary and the other as secondary, merged into the first with or without its own revision history.

Мамандандырылған стратегиялар

Инженерлік өзгертулерді басқару ертедегі жобалардың немесе көк сызықтардың өзгертулерін қадағалауға негізделген ресми процестерден пайда болды. Бұл басқару жүйесі жобаны әзірлеу барысында инженерлік тұйыққа тіреліп қалған жағдайларда, жобаның алдыңғы нұсқасына қайта оралуға мүмкіндік берді. Егер жасалған өзгерістерді тіркеу үшін қайта қарау кестесі пайдаланылса, суреттегі өзгертілген бөліктер қайта қарау бұлттарымен белгіленді.

Бизнес пен заң саласында

Версияны бақылау бизнес және құқық салаларында кеңінен таралған. Шындығында, "шарттың қызыл жолы" және "құқықтық қара жол" – бұл нұсқаларды бақылаудың ең ерте нысандарының бірі, және олар әлі де кәсіби және құқық салаларында әртүрлі деңгейде қолданылады. Ең жетілдірілген техникалар CAD файлдарындағы өзгерістерді электрондық түрде қадағалау үшін қолданыла бастады (өнім деректерін басқаруға қараңыз), дәстүрлі нұсқаларды бақылаудың "қолмен" электрондық орындалуын ығыстырып шығарып жатыр.

Ресурстарды басқару үлгілері

Дәстүрлі нұсқаны бақылау жүйелері орталықтандырылған модельді пайдаланады, онда барлық нұсқаны бақылау функциялары ортақ серверде орындалады. Егер екі бағдарламашы бір файлды бір уақытта өзгертуге тырысса, ал қолжетімділікті басқару әдісі болмаса, бағдарламашылар бір-бірінің жұмысын жойып жіберуі мүмкін. Орталықтандырылған нұсқаны бақылау жүйелері бұл мәселені екі түрлі "көзді басқару моделінің" бірі арқылы шешеді: файлды құлыптау және нұсқаларды біріктіру.

Атомдық операциялар

Егер операция үзілген жағдайда да жүйе тұрақты күйде қалса, онда ол операция атомдық деп есептеледі. Бұл жағынан алғанда, commit операциясы ең маңызды болып табылады. Commit өзгерістердің жиынтығын ревизияны басқару жүйесіне түпкілікті етіп бекітуді және оларды барлық пайдаланушыларға қолжетімді етуді жүктетеді. Барлық ревизияны басқару жүйелерінде атомдық commit мүмкіндігі болмайды; Concurrent Versions System жүйесінде мұндай мүмкіндік жоқ.

Файлдарды бұғаттау

"Бір мезгілде қол жеткізу" мәселелерін болдырмаудың ең қарапайым тәсілі – файлдарды құлыптау, осылайша бір уақытта тек бір ғана әзірлеуші сол файлдардың орталық "репозиторий" көшірмелеріне жазуға рұқсат алады. Әзірлеуші бір файлды "алған" кезде, басқалар оны оқи алады, бірақ ол әзірлеуші жаңартылған нұсқаны "қайтарғанға" (немесе алуды тоқтатқанға) дейін ешкім сол файлды өзгерте алмайды. Файлдарды құлыптаудың пайдасы мен зияны бар. Бұл, пайдаланушы үлкен файлдың (немесе файлдар тобының) көп бөлігіне күрт өзгерістер енгізгенде, қиын біріктіру қақтығыстарының алдын алуға көмектеседі. Егер файлдар ұзақ уақытқа құлыпталған болса, басқа әзірлеушілер нұсқаулықты басқару жүйесін айналып өтіп, файлдарды жергілікті түрде өзгертуге тырысуы мүмкін, соның салдарынан басқа өзгерістер тексерілгенде қиын қолмен біріктіру қажет болады. Ірі ұйымдарда әзірлеушілер жобалар арасында ауысқанда файлдар "алып қойылған" және құлыпталған күйде қалып, ұмытылуы мүмкін. Мұндай құралдар файлды кімнің алғанын анықтауды жеңілдетуі де, қиындыруы да мүмкін.

Версияларды біріктіру

Көптеген нұсқауды басқару жүйелері бірнеше дамытушыларға бір файлды бір уақытта өңдеуге мүмкіндік береді. Орталық репозиторийге өзгерістерді бірінші болып "тексерген" дамытушы әрқашан сәтті болады. Жүйе орталық репозиторийге одан әрі өзгерістерді біріктіру мүмкіндігін ұсынуы мүмкін, сондай-ақ басқа дамытушылар тексерген кезде бірінші дамытушының өзгерістерін сақтайды. Екі файлды біріктіру өте нәзік операция болуы мүмкін, және әдетте дерек құрылымы қарапайым болса ғана мүмкін болады, мысалы, мәтіндік файлдарда. Екі кескін файлды біріктірудің нәтижесі кескін файлына айналмауы да мүмкін. Кодты тексеріп жатқан екінші дамытушы өзгерістер үйлесімді екеніне және біріктіру операциясы файлдардағы логикалық қателерді тудырмауына көз жеткізу үшін біріктіруге қатысты сақтық танытуы керек. Бұл мәселелер автоматты немесе жартылай автоматты біріктіру операцияларының қолжетімділігін негізінен қарапайым мәтіндік құжаттармен шектейді, егер файл түрлері үшін арнайы біріктіру плагині болмаса. Біріктіру мүмкіндігі болған жағдайда да, файлды эксклюзивті жазу үшін нақты түрде құлыптаудың қосымша құралын ұсынатын "резервтелген өңдеу" тұжырымдамасы бар.

Базалық көрсеткіштер, таңбалар мен белгілер

Көптеген нұсқаларды бақылау құралдары осы ұқсас терминдердің біреуін ғана қолданады (базалық сызық, белгі, тег) – суретті анықтау ("жобаны белгілеу") немесе суреттің жазбасын ("базалық X-пен сынап көріңіз") үшін. Әдетте, құжаттамада немесе талқылауда базалық сызық, белгі немесе тег терминдерінің біреуі ғана қолданылады; оларды синонимдер деп санауға болады. Көптеген жобаларда кейбір суреттер басқаларына қарағанда маңыздырақ болады, мысалы, жарияланған шығарылымдарды, тармақтарды немесе кезеңдерді көрсету үшін қолданылады. Егер базалық сызық және белгі немесе тег терминдері бір контекстте қолданылса, белгі мен тег әдетте құралдың суретті анықтау немесе жазу механизміне сілтеме жасайды, ал базалық сызық – кез келген белгінің немесе тегтің маңыздылығын арттырады. Конфигурациялық басқару туралы ресми талқылауда көбінесе базалық сызық термині қолданылады.

Бөлінген қайта қарауды бақылау

Бөлінген нұсқаны бақылау жүйелері (DRCS) орталықтандырылған жүйелердің клиент-сервер тәсілінен өзгеше, өзара тең құрбылық тәсілін қолданады. Клиенттер синхрондалатын жалғыз орталық репозиторийдің орнына, код базасының әр құрбысының жұмыс көшірмесі толыққанды репозиторий болып табылады. Бөлінген нұсқаны бақылау синхрондауды құрбылар арасында түзетулерді (өзгерістер жиынтығын) алмасу арқылы жүзеге асырады. Бұл орталықтандырылған жүйеден кейбір маңызды айырмашылықтарға алып келеді: код базасының канондық, анықтамалық көшірмесі әдепкі бойынша болмайды; тек жұмыс көшірмелері ғана бар. Көбінесе қолданылатын операциялар (мысалы, коммит, тарихты көру және өзгерістерді кері қайтару) жылдам болады, себебі орталық сервермен байланысу қажеттілігі жоқ. Бағдарламалық жасақтаманы әзірлеудің басқа да жақсы тәжірибелері, мысалы, кодты қарау және автоматтандырылған регрессиялық тестілеу нұсқаны бақылаудың жақсы тәжірибелерін сақтауға көмектеседі.

Шығындар мен пайда

Шығындар мен пайда таңдалған нұсқаны бақылау құралына және қолданылатын салаға байланысты өзгереді. Осы бөлім бағдарламалық жасақтаманы әзірлеу саласына арналған, онда нұсқаны бақылау кеңінен қолданылады.

Шығындар

Версияны басқару бағдарламалық құралының лицензиялық төлемдерінен өзге, нұсқаларды басқару уақыт пен еңбек талап етеді. Нұсқаларды басқарудың негізгі принциптерін түсіну қажет, сондай-ақ таңдалған бағдарламалық құралды қолдану үшін қажетті техникалық мәліметтерді меңгеру керек. Нұсқаларды басқарудың ең тиімді тәсілдерін үйреніп, ұйымның қазіргі бағдарламалық жасақтаманы әзірлеу процесіне енгізу қажет. Осы тәсілдерді дұрыс қолданып, пайдалы нәтиже алу үшін басқарушылық күш-жігер қажет болуы мүмкін.

Өзгерістерді кері қайтаруға мүмкіндік береді

Негізгі пайдасы – тарихты сақтап, өзгерістерді кері қайтару мүмкіндігі, бұл әзірлеушіге жасалған өзгерістерді оңай жоюға көмектеседі. Бұл әзірлеушіге тәжірибе жасауға кең мүмкіндік береді және қолданыстағы кодты бұзып алу қаупін жояды.

Бранчтау іске қосуды, техникалық қызмет көрсетуді және әзірлеуді жеңілдетеді

Тармақтау енгізуге көмектеседі. Тармақтау және біріктіру, бастапқы кодқа жамаларды жасау, қаптау және белгілеу, сондай-ақ код базаларына жамаларды оңай қолдану, енгізу процесінің әртүрлі кезеңдерімен байланысты бірнеше код базаларын күтуді және параллель әзірлеуді жеңілдетеді; әзірлеу, сынақтан өткізу, дайындық, өндіріс және т.б.

Залалдарды азайту, жауапкершілік және процестерді және жобалауды жақсарту

Нұсқаны бақылау арқылы қамтамасыз етілген жазбалардың нәтижесінде зиянды азайту, жауапкершілік, процестер мен дизайнды жақсарту және басқа да пайдалар болуы мүмкін, олар кімнің не істегенін, қашан, не үшін және қалай екенін тіркеуге мүмкіндік береді. Бұл болашақта туындаған проблемалар мен шешімдерді қарастыру үшін өзгерістердің себептерін қайта бағалауға көмектеседі. Қателер пайда болғанда, не істелгенін білу зиянды азайтуға және қалпына келтіруге көмектеседі, себебі бұл қандай проблемалар бар екенін, олар қанша уақыттан бері бар екенін анықтауға, сондай-ақ проблеманың көлемін және шешімдерін анықтауға көмектеседі. Кодты және коммит хабарламаларын қарастыру арқылы алынған қорытындыларды тексеру үшін бұрынғы нұсқаларды орнатып, сынап көруге болады.

Қателерді жөндеуді жеңілдету

Версияны басқару қателерді жоюды қатты жеңілдетеді. Бірнеше нұсқаға сынақ жағдайын қолдану, қатеге себеп болған өзгерісті жылдам анықтауға көмектеседі. Бағдарламашы барлық код базасын білуі міндетті емес, және ол мәселені тудырған кодқа назар аудара алады.

Ынтымақтастық пен қарым-қатынасты жақсартады

Версияны басқару ынтымақтастықты бірнеше жолмен күшейтеді. Версияны бақылау қақтығыс тудыратын өзгерістерді, яғни бір кодтың бірдей жолдарына енгізілген үйлесімсіз өзгерістерді анықтай алатындықтан, әзірлеушілер арасындағы координация қажеттілігі азаяды. Коммиттердің, тармақтардың және олармен байланысты коммит хабарламаларының мен нұсқа таңбаларының жиынтығы әзірлеушілер арасындағы байланысты жақсартады, тікелей де, уақыт өте келе де. Жақсы байланыс, дереу немесе кейінге шегерілген жағдайда да, кодты тексеру процесін, сынақтан өткізу процесін және бағдарламалық құралды әзірлеу процесінің басқа да маңызды аспектілерін жақсартуға мүмкіндік береді.

Интеграциялау

Кейбір жетілдірілген нұсқаларды басқару құралдары басқа құралдармен және бағдарламалық жасақтаманы әзірлеу процестерімен тығыз байланысуға мүмкіндік беретін көптеген қосымша мүмкіндіктерді ұсынады.

Интегралды даму ортасы

Плагиндер көбінесе Oracle JDeveloper, IntelliJ IDEA, Eclipse, Visual Studio, Delphi, NetBeans IDE, Xcode және GNU Emacs (vc.el арқылы) сияқты IDE-лер үшін қолжетімді. Күрделі зерттеу прототиптері тиісті коммит хабарламаларын жасап шығарады.

Бастапқы көрсеткіш

Құжаттың немесе бастапқы файлдың кейіннен өзгерістер енгізілетін бекітілген жаңа нұсқасы. Базалық сызықтар, белгілер және таңбалар туралы қараңыз.

Қателік

Белгілі бір жолды соңғы рет өзгерткен автор мен түзетуді іздеу.

Филиал

Версияны бақылауға алынған файлдар жиынтығы белгілі бір сәтте тармақталып немесе бөлініп шығуы мүмкін, соның салдарынан сол сәттен бастап осы файлдардың екі нұсқасы бір-біріне тәуелсіз түрде әртүрлі жылдамдықпен немесе әртүрлі бағыттарда дамуы мүмкін.

Өзгерістер

Өзгеріс (немесе айырмашылық немесе дельта) – нұсқаулы бақылаудағы құжатқа енгізілген нақты өзгертуді білдіреді. Өзгеріс деп есептелетін өзгертулердің дәлдігі нұсқаулы бақылау жүйелеріне қарай өзгеше болуы мүмкін.

Өзгерістер тізімі

Көптеген нұсқаны басқару жүйелерінде атомдық көп өзгерісті міндеттемелерде, өзгерістер тізімі (немесе CL), өзгерістер жиынтығы, жаңарту немесе түзету бір міндеттемеде жасалған өзгерістер жиынтығын көрсетеді. Бұл сонымен қатар бастапқы кодтың реттік көрінісін ұсынуы мүмкін, осы арқылы кез келген нақты өзгерістер тізімі идентификаторы бойынша кодты қарауға болады.

Есепке алу

Репозиторийден жергілікті жұмыс көшірмесін жасау – бұл "тексеріп алу" (немесе бірге тексеру) операциясы. Пайдаланушы белгілі бір нұсқаны немесе ең соңғы нұсқаны таңдай алады. "Checkout" термині жұмыс көшірмесін атау үшін зат есім ретінде де қолданылуы мүмкін. Егер файл ортақ файл серверінен тексеріліп алынса, басқа пайдаланушылар оны өңдей алмайды. Бұл қонақ үйге ұқсас: шығып кеткен соң, сіз оның мүмкіндіктерін пайдалана алмайсыз.

Клоны

Клондау – бұл басқа репозиторийден жасалған өзгерістерді қамтитын репозиторийді құру. Бұл бос (жаңадан құрылған) репозиторийге жіберуге немесе алуға тең. Атау ретінде, егер екі репозиторий синхронды түрде сақталса және бірдей өзгерістерді қамтитын болса, оларды клондар деп айтуға болады.

Санаты (әрекет)

Жауап беру (check in, ci немесе сирек кездесетін, install, submit немесе record) — жұмыс көшірмесінде жасалған өзгерістерді репозиторийге жазу немесе біріктіру. Коммит метадеректерді, әдетте автор туралы ақпаратты және жасалған өзгерісті сипаттайтын хабарламаны қамтиды.

Хабарламаны жіберу

Коммитпен бірге сақталып, оны сипаттайтын дамытушы жазған қысқаша хабарлама. Ең жақсысы, бұл өзгерістің не үшін енгізілгенін, оның нәтижесін немесе мақсатын, сондай-ақ өзгерістің жұмыс істеу принципінің түсініксіз тұстарын түсіндіруі керек.

Қақтығыстар

Конфликт әр түрлі тараптар бір құжатты өзгертетін кезде туындайды, және жүйе осы өзгерістерді үйлестіре алмайды. Пайдаланушы конфликті өзгерістерді біріктіріп немесе бірін таңдап, екіншісінен бас тарту арқылы оны шешуі керек.

Дельталық қысылу

Көптеген нұсқаулықты басқару бағдарламалық құралдары дельталық сығылуды қолданады, ол файлдардың тізбектелген нұсқалары арасындағы өзгерістерді ғана сақтайды. Бұл файлдардың көптеген әртүрлі нұсқаларын тиімді сақтауға мүмкіндік береді.

Динамикалық ағын

Ағын, онда файл нұсқаларының бір бөлігі немесе барлығы аталық ағын нұсқаларының көшірмесі болып табылады.

Экспорт

Экспорттау – файлдарды репозиторийден алу әрекеті. Бұл, нұсқаны басқару метадеректері жоқ таза каталог ағашын құратындықтан, тексеруге ұқсас, бірақ жұмыс көшірмесінен өзгеше. Мысалы, мазмұнды жариялау алдында осы әдіс жиі қолданылады.

Алып келу

Тартыңыз көру үшін.

Алға қарай интеграциялау

Негізгі түпнұсқада жасалған өзгерістерді даму (фича немесе командалық) тармағымен біріктіру процесі.

Бас

Сонымен қатар, "ұш" деп те аталатын бұл термин, негізгі тармаққа немесе тармаққа жасалған ең соңғы өзгертуді білдіреді. Негізгі тармақ пен әрбір тармақтың өзіндік басы болады, алайда "HEAD" кейде негізгі тармақты білдіру үшін қолданылады.

Импорт

Импорттау – бұрын репозиторийде болмаған жергілікті каталогтар ағашын репозиторийге алғаш рет көшіру.

Бастапқы жазу

Жаңа, бос репозиторийді құру.

Жапырақты дельталар

Кейбір нұсқаларды басқару жүйелері Interleaved дельталарын қолданады, бұл әдіс мәтіндік файлдар тарихын Дельта сығылымына қарағанда тиімдірек сақтауға мүмкіндік береді.

Таңба

Тегті қараңыз.

Қалқалау

Егер бағдарламашы файлды құлыптаса, оны ашып бергенше ешкім өзгерте алмайды. Құлыптау нұсқаны басқару жүйесімен немесе бағдарламашылар арасындағы бейресми келісім арқылы қолдауға болады (әлеуметтік құлыптау деп те аталады).

Негізгі желі

Тармаққа ұқсас, бірақ әрбір тармақ үшін жеке басты желі болуы мүмкін.

Біріктіру

Біріктіру немесе интеграция – бұл файлға немесе файлдар жиынтығына екі түрлі өзгеріс жиынтығы қолданылатын операция. Мысалдардың кейбірі: Пайдаланушы файлдар жиынтығымен жұмыс істеп, өзге пайдаланушылар енгізген өзгерістермен жұмыс көшірмесін жаңартады немесе синхрондандырады және оларды репозиторийге сақтайды. Пайдаланушы файлдарды тексергеннен кейін басқалар жаңартқан файлдарды сақтауға тырысады, ал нұсқауды басқару бағдарламалық құралы файлдарды автоматты түрде біріктіреді (әдетте, автоматты біріктіруді жалғастыру керек пе, жоқ па, деп пайдаланушыдан сұрағаннан кейін, ал кейбір жағдайларда біріктіруді нақты және логикалық түрде шешуге болады). Тармақ құрылады, файлдардағы код тәуелсіз түрде өңделеді, ал жаңартылған тармақ кейіннен бірыңғай түпнұсқаға қосылады. Файлдар жиынтығы тармақталады, тармақталудан бұрын болған мәселе бір тармақта түзетіледі, содан кейін түзету екінші тармаққа біріктіріледі. (Бұл таңдамалы біріктіру түрі кейде бұрынғы жағдайдағы толық біріктіруден ерекшелену үшін «cherry-pick» деп аталады.)

Бастауыш

Файл мазмұнын қауіпсіздігі төмен жерден қауіпсіздігі жоғары жерге көшіру. Мысалы, пайдаланушының жұмыс кеңістігінен репозиторийге немесе ағыннан оның негізгі орнына.

Тарт, түрт

Түзетулерді бір репозиторийден екіншісіне көшіру. Тарту қабылдаушы репозиториймен басталады, ал түрту көз репозиториймен басталады. Fetch кейде pull сөзінің синонимі ретінде қолданылады, немесе тартудан кейін жаңарту жасауды білдіреді.

Қаулыны шешу

Бір құжатқа енгізілген әртүрлі өзгерістердің қақтығысын жою мақсатымен пайдаланушының араласуы.

Кері интеграция

Версиялық жүйенің негізгі бағытына команданың әртүрлі тармақтарын қосу процесі.

Қайта қарау және нұсқа

Версия – форманың кез келген өзгерісі. SVK жүйесінде Revision – репозиторийдегі бүкіл ағаштың белгілі бір уақыттағы күйі.

Ортақ үлесі

Бір файлды немесе қалтаны бірнеше тармақта бір уақытта қолжетімді ету. Ортақ файл бір тармақта өзгертілсе, ол басқа тармақтарда да өзгереді.

Ағын

Тармақталған файлдарды сақтауға арналған контейнер, басқа осындай контейнерлермен анықталған байланысы бар. Ағындар иерархия құрайды; әрбір ағын ата-ана ағынынан әртүрлі қасиеттерді (нұсқалар, атау кеңістігі, жұмыс процесі ережелері, жазылушылар және т.б.) мұраға алады.

Таңба

Тег немесе белгі – көптеген файлдарда бірдей болатын, уақыт бойынша маңызды бір сәт. Сол кездегі файлдардың барлығы қолданушыға қолайлы, мағыналы атаумен немесе нұсқа нөмірімен белгіленуі мүмкін. Базалық деңгейлер, белгілер және тегтерді қараңыз.

Жаңарту

Жаңарту (немесе синхрондау, бірақ синхрондау біріктірілген жіберу және алуды да білдіруі мүмкін) репозиторийде жасалған өзгерістерді (мысалы, басқа адамдар жасаған) жергілікті жұмыс көшірмесімен біріктіреді. Жаңарту кейбір конфигурациялық басқару құралдарында (CM+, PLS, SMS) өзгеріс жинағы түсінігін білдіру үшін қолданылатын термин (өзгерістер тізіміне қараңыз). Бұл, әр репозиторийде дәл бір жұмыс көшірмесі болуын талап ететін нұсқаларды бақылау жүйелеріндегі тексерумен синонимді (таратылған жүйелерде кең таралған).

Қалқаны ашу

Құлыпты босату.

Жұмыс көшірмесі

Жұмыс көшірмесі – белгілі бір уақытта немесе нұсқадағы файлдардың жергілікті көшірмесі. Қоймадағы файлдарға жасалатын барлық өзгерістер бастапқыда жұмыс көшірмесінде жасалады, сондықтан осылай аталады. Шартты түрде, ол сынақ ортасы.