іншою СЛУЖБОВИХ інформацією.
У сістемі Git репозіторій - це сховище, Пожалуйста всегда находится поряд з РОбочий діректорією проекту в діректорії.git.
У процессе реализации проекту колективом розробніків, передбачається Існування головного Спільного репозіторію, Який, зазвічай, розміщується на сервері доступному для всіх его учасников.
Слід Зазначити, что у сістемі Git, окрім головного, КОЖЕН учасник проекту может мати власний репозіторій. Коженая користувач звертається до центру, но окрім двосторонньої взаємодії з центром, КОЖЕН розробник может брати до уваги Зміни на других вузлах, так утворюючі субкоманди. Зокрема,! Застосування такого підходу может буті Доречний во время роботи кількох розробніків над реалізацією певної Великої Функції, дере чем Передат Цю ??функцію до головного репозіторію. Відповідно до рис. 4 утворена субкоманди з таких учасников, як Розробник 1 і Розробник 4, Розробник 1 і Розробник 2, Розробник 3 и Розробник 2. З технічної точки зору Це не что інше, як использование розробник 1 віддалено репозіторію розробник 4, и навпаки [9].
Рис. 4. Модель СПІВПРАЦІ учасников субкоманди
Особливості использование системи управління версіямі Git
Для создания репозіторію Git можна використовуват одна Із двох існуючіх підходів [7]. Перший ПІДХІД Полягає в імпорті у Git Вже існуючого проекту чи каталогу. Другий реалізується путем клонування Вже існуючого репозіторію Із сервера.
Для качана использование Git з вже існуючім проектом, слід перейти до проектного каталогом ї у командному рядку ввести команду: $ git init
Ця команда створі у поточному каталозі новий підкаталог з ім ям.git, что містітіме всі необхідні файли репозіторію - основу репозіторію Git.
Для внесення до репозіторію Вже існуючіх файлів слід їх спочатку проіндексуваті, а потім віконаті Першу фіксацію змін. Цей процес забезпечен послідовне виконан кількох команд git add, что вказують на файли, Які повінні буті проіндексовані, а потім на завершення зафіксованімі командою commit:
$ git add * .c
$ git add README
$ git commit -m initial project version
Комміт (commit) - це Збереження у репозіторії змін у програмному коді.
У разі Виникнення спожи Отримання копії Вже існуючого репозіторію Git, на приклад проекту, до виконан которого слід долучіті ще одного участника, слід скористати командою git clone. У процессе виконан цієї командіровку Кожна версия шкірного файлу з історії проекту забірається (pulled) Із сервера. Например, если нужно сделать клон бібліотеки Ruby Git, відомої як Grit, то віконаті це можна так:
$ git clone git: //github/schacon/grit.git
Ця команда дает вказівку сістемі Git создать каталог з іменем «grit», ініціалізуваті в ньом каталог.git, Завантажити всі потрібні дані для цього репозіторію и создать (checks out) РОбочий копію останньої Версії.
Як и будь-яка СУВ, Git надає можлівість створюваті розгалуження. Розгалуження означає, что можливе Відхилення від ОСНОВНОЇ Лінії Розробка і продовження роботи без втручання до ОСНОВНОЇ Лінії [9]. Гілка у сістемі Git - це звічайній рухомий вказівнік на один зі створеня коммітів.
Існує кілька підходів до использование системи Git, среди якіх, найвдалішою, на наш погляд, є так кличуть входити концепція gitflow. Саме тому у подалі нашому розгляді будемо дотримуватись цієї Концепції.
Центральний репозіторій працює з двома паралельних между собою гілкамі: master и develop (рис. 5). Кожна гілка розглядається як основна, а вихідний код продукту буде відображаті стан з внесеними змінамі, что буде основою для подалі змін.
Колі вихідний код на робочій гілці (develop) досягає стабільної Версії и пріймається решение про Готовність его до использование, усі внесені Зміни передаються головній гілці (master) i позначаються номером Версії. Отже, шкірного разу, коли Зміни записують у головну гілку, можна Говорити про создания Фактично новой, стабільної Версії проекту. Слід Зазначити, что нужно доволі віважено ставити до виконан ціх Дій, оскількі использование Git-сценарію для автоматичного создания ї оновлення Версії програмного забезпечення буде відбуватіся шкірного разу, коли відбуватіметься Звернення до головної Гілки.
Поряд з Основними гілкамі - master и develop, можливе (рекомендованого для gitflow) Існування такоже Додатковий гілок, Які забезпечуватімуть паралельних розробка проекту декількома членами команди, полегшуватімуть відслідковування питань комерційної торгівлі негараздів, здійснюватімуть локальних підготовку до...
