Привіт, шановні Новомосковсктелі блогу LifeExample. за останній місяць мій проект MOGUTA.CMS придбав більш-менш усталений склад команди, і ми разом почали дописувати продукт, розроблений в циклі статей про створення інтернет магазину.
Оскільки всі ми територіально віддалені один від одного, і щодня вносимо нові правки в код проекту, нам необхідно мати можливість оперативно обмінюватися своїми версіями продукту.
Це завдання легко вирішується при використанні однієї з поширених систем контролю версій (VCS - Version Control System), таких як SVN, GIT, Mercurial. Bazaar.
Одного разу на блозі я вже писав про систему контролю версій - SVN. в статті "Налаштування SVN", і спочатку при організації, спільних, процесів розробки MOGUTA.CMS, ми навіть стали використовувати саме SVN, але згодом остаточний вибір припав на Mercurial.
Цьому рішенню сприяло кілька фактів:
- Mercurial - більш продуктивний на відміну від SVN, за рахунок своєї концепції в основі якої лежить використання розподілених сховищ.
- Mercurial - дуже простий у розумінні використанні.
З огляду на те, що наша команда складається в основному з людей, які не працювали з системами контролю версій, ми прийняли рішення використовувати який підкупив своєю простотою Mercurial'a.
Як використовувати Tortoise hg
Наступна інструкція не описує, всі можливості програми Tortoise hg. але з її допомогою ви отримаєте наочне уявлення, про те, як працювати з системою контролю версій Mercurial.
- Після установки Tortoise hg, в контекстне меню провідника додадуться два пункти: "Hg WorkBench" і "TourtoiseHg".
Щоб записати зроблені зміни перейдемо в інтерфейс програми Tortoise Hg. клікнувши по пункту "Hg WorkBench" з контекстного меню папки з проектом.
Найважливіше в роботі з VCS, розуміти, як працює система гілок. Якщо поглянути на граф ревізій, то можна побачити безліч переплетених між собою версій проекту
Такі переплетення є результатом злиття, двох різних версій розробників. Наприклад, в команді працюють два програміста і один дизайнер, і кожен з них повинен внести свої правки в проект. Щоб максимально комфортно зробити це відразу всім учасникам команди, кожному з них необхідно створити свою гілку розробки і вести всі зміни в ній.
Це приблизно так само, як скопіювати в іншу папку на диску всі файли і працювати вже з ними, не заважаючи іншим. Тільки завдяки системі Mercurial. перенесенням даних в різні папки займатися не доводиться, все, що для цього потрібно зробити, це в кілька кліків миші створити Комміт в нову гілку.
Комміт - по-російськи кажучи це збереження поточного набору змін в нову ревізію (версію проекту).
Як створити гілку в Tortoise HG
Ми зупинилися на тому, що створили новий файл в проекті і відкрили інтерфейс управління Tortoise HG. Подивіться на наведену вище ілюстрацію.
Пронумеровані поля, виділені, червоним контуром призначені для наступних дій:
- 1: показує, в якій гілці ми зараз знаходимося, про це говорить, поміщене між двох зірок опис: "Робочий каталог".
- 2: також показує назву поточної гілки, а крім цього є кнопкою для створення нової. Натиснувши на неї, Tortoise HG запропонує створити іменовану гілку. Зробимо нове відгалуження проекту.
Як злити гілки в Tortoise HG
З внесенням правок і створенням нової гілки ніби розібралися.
Хочу звернути увагу: при наступному Ком, не треба створювати нову гілку, робіть все те саме, що описано в попередньому розділі, але минувши пункт зі створенням іменованої гілки.
Робити багато коммітов в одній гілці корисно, для того щоб в потрібний момент відкотитися до попередньої версії і подивитися як працювала система раніше. Але зловживати коммітов я не рекомендую, робіть їх тільки тоді коли вважаєте, що закінчили якусь частину роботи. Зазвичай вистачає, робити Комміт в кінці і / або початку робочого дня.
Як оновлюватися до попередньої ревізії
Після поновлення, зовнішній вигляд графа дещо зміниться, але на його структуру це ніяк не вплине, просто Tortoise HG відобразить його більш зручним для сприйняття способом. З оновленням до будь-якої ревізії поміняються дані в полях 1 і 2, наведених на ілюстрації з розміткою.
Ось так буде виглядати в нашому прикладі граф після поновлення:
Як злити гілки проекту
Вираз "Злити гілки" в Mercurial і інших системах контролю версій, означає об'єднати зміни двох різних версій. Зливати гілки можна як свої, так і чужі, і найголовніше зливати можна з дефолтной гілкою.
До речі, я упустив момент, і не сказав, що дефолтна гілка - це гілка, яка містить поточну стабільну версію проекту, тобто зливатися з нею можна тільки тоді, коли всі правки налагоджені і протестовані.
Нові розробники при клонуванні проекту, повинні мати можливість отримати відразу повний комплект стабільних змін, щоб приступити до внесення власних, як це зробили ми в прикладі.
Отже, давайте, сольем наші внесені правки з дефолтной гілкою проекту. Для цього вже знайомим шляхом, оновити до останньої стабільної версії в дефолтной гілки.
А потім кліком правою кнопкою миші, по вузлу графа, з нашим коммітов (ревізія 69), виберемо меню "Злити з локальної".
Після кліка по пункту, будуть з'являтися діалогові вікна, в усіх них, тиснемо "Далі".
В результаті отримаємо таку картину графа, і оновлену дефолтну гілка проекту.
Зливати гілки можна як справа наліво, так і зліва на право. Якщо ви розробляєте будь-якої власний модуль, що вимагає довгого часу, але в цей період дефолтна гілка оновлюється іншими розробниками, вам треба зливати зміни з дефолтной гілки в свою, але не навпаки. Причому робити це потрібно, настільки часто, настільки часто оновлюється дефолтна гілка.
Як дізнатися, що дефолтна гілка оновилася
Кожен раз, перед тим як сутра продовжувати розробку, необхідно затягувати всі зміни проекту, внесені іншими розробниками вночі. Це потрібно робити якомога частіше, щоб не виникла ситуація коли дві різні людини правлять один і той же файл, в корені переписуючи його.
В цьому випадку при спробі злити гілки, виникнуть конфлікти, з якими не легко розбиратися. якщо вчасно не синхронізувати власні напрацювання з чужими.
Щоб затягнути зміни, якщо такі є, в панелі управління Tortoise HG. є радна іконка, яка називається "Затягнути входять зміни з обраного URL".
Ось що я отримав, натиснувши на кнопку затягнути зміни з сервера:
Виявляється, поки я робив тестові зміни для демонстрації роботи, хтось із команди вніс свої правки і закоммітіл дані. Але не просто закоммітіл, а відправив їх на сервер, для загального обозреванія і використання.
Я ще не згадував про це, і ось час настав. Всі дії які ми робили, проводилися над нашої локальної робочої копією сховища. Ось вона, та сама зручність, яка є у Mercurial і немає у SVN, все коммітов які ми робили, зберігалися тільки на нашому комп'ютері, і не заважали іншим.
Як застосувати свої зміни на центральному сервері
Тепер, коли все налагоджено і немає конфліктів з тільки що тривалими гілками, ми можемо зробити зворотну операцію: відправити всі свої зміни на централізований сервер.
Робиться це натисканням на кнопку "Проштовхнути вихідні зміни на обраний URL"
Відіславши свої дані на сервер, ми даємо можливість іншим учасникам проекту, затягнути їх до себе на робочу копію, і використовувати в своїх цілях і цілях всього проекту.
Проблема з відправкою на сервер
На жаль, не все так гладко як описано вище, в реальності при відправці на сервер своїх правок, часто можна отримати схожу помилку:
searching for changes
abort: push creates new remote head 3a37da9642d5!
(You should pull and merge or use push -f to force)
Чи означає вона, то що, після того як ви затягнули зміни (а може і не затягнули, хоча зобов'язані) в графі ревізій з'явилося дві голови однієї і тієї ж гілки. Таке може статися коли два розробника працюють в одній гілці, і періодично роблять коммітов.
У цій ситуації другий розробник, поки ми робили правки, вніс свої зміни, і тепер нам треба з ними рахуватися.
Іншими словами, нам треба зробити з двох версій однієї і тієї ж гілки лише одну.
Більш простий спосіб вирішення конфліктів, це вказати програмі взяти цілком наш локальний файл. В цьому випадку в об'єднаній версії виявиться ваш файл, без чужих правок. Це допоможе завершити злиття і проштовхнути в загальне сховище, але може викликати проблеми в працездатності проекту, тому що змін, які робилися іншим розробником тепер не існує в поточній версії.
Щоб вирішити цю ситуацію, краще зв'язатися з другим чоловіком і постаратися разом знайти ті ділянки коду, в яких потрібно вставити його код.
У теорії це все, складно, але на практиці значно легше ніж здається. Тому не варто боятися конфліктів, всі вони вирішуються.
Tortoise HG весь час вимагає логін і пароль
Якщо ви випробували в дії Tortoise HG. то напевно помітили настирливу перевірку кожної дії, запитом логіна і пароля. Щоб не обтяжувати Tortoise HG, запитувати у нас ці дані, потрібно зробити одну настройку.
Зайдіть в папку .hg розташовану в корені вашої робочої копії сховища, вона прихована, тому, можливо, доведеться налаштувати параметри показу прихованих файлів в вашому файловому менеджері. У цій папці є файл hgrc. відкриємо його і внесемо таку правку:
Те що повинно бути:
Збережемо файл, і перезапустити Workbench HG.
Після цих дій, запит пароля перестане докучати нам.
Ех, Марк! Де ти був раніше з цією статтею ??))) Стільки часу дозволила б вона заощадити))
Здарвствуйте Марк, хотів запитати, виходить для кожного проекту потрібно робити окремий репозитарій.
Так, кожен проект це окреме сховище. Ну теоретично можна з першої ревізії починати нову гілку для нового проекту, хоча це не дуже зручно.