Блог - Разработка - Mercurial се ангажира,сливания
Когато човек работи сам с хранилище, по правило няма проблеми. Недоразуменията започват, когато 2 или повече души работят с хранилището. Добавя бъркотия "визуален" софтуер - TortoiseHg, например. Хората са свикнали да натискат един бутон и че „всичко е наред“. И тук има куп бутони, също с неясен превод (ако се използва българската версия).
Най-основната концепция за разбиране: HG е децентрализирана система за контрол на версиите. Във всеки един момент има поне две пълноценни хранилища: на отдалечен сървър и локално, в папката на проекта. Всички промени, на първо място, се случват в локалното хранилище. Необходими са допълнителни стъпки за актуализиране на хранилището на сървъра.
И така, работният процес Дойдохме на работа сутринта, започваме да работим и го изпълняваме в конзолата от директорията на проекта (имам предвид, че проектът вече съществува и всичко нормално беше поставено на сървъра вечерта на предишния ден):
hg тегли -u
С командата hg pull актуализираме нашето локално хранилище от сървъра (само хранилището! Файловете на проекта не се пипат). Флагът -u отговаря за актуализирането на файловете на проекта. Всичко това се прави в случай, че има промени в кода.
hg commit -m "Коригирана грешка #58"
С тази команда ние ангажирахме промените в кода в локалното хранилище. Вашите промени все още не са достъпни за друг разработчик! Те се пазят само от вас.
До края на деня имаме локално хранилище с няколко ангажимента в него. Сега трябва да изпратим цялата си доброта на отдалечен сървър - така че нашите редакции да са достъпни за други разработчици. Изпълнете командата:
hg push
С този екип изпращаме всичкопромени от локално хранилище към отдалечено. Ако няма промени в отдалеченото хранилище от сутринта, тогава всичко върви добре.
Но ще разгледаме случая на конфликт. Следователно в отговор получаваме:
натискане към .търсене на променипрекратяване: натискането създава нови отдалечени глави на клон 'по подразбиране'!(трябва да изтеглите и обедините или да използвате push -f за принудително)
Не се страхувайте от такова съобщение - това означава само, че са настъпили промени в отдалеченото хранилище и трябва да актуализираме нашето локално хранилище и да обединим нашите промени с други промени. За да направите това, изпълнете:
hg теглене
С тази команда актуализираме локалното хранилище от отдалеченото. Получаване на съобщение:
изтегляне от .търсене на променидобавяне на набори от променидобавяне на манифестидобавяне на файлови променидобавени 2 набора промени с 1 промени към 1 файл (+1 заглавия)(изпълнете 'hg heads', за да видите заглавия, 'hg merge' за обединяване)
Сега имаме интересна ситуация в локалното хранилище - имаме 2 клона. Един клон - промени от сървъра, вторият клон - нашите промени. Но трябва да направим един от тези два клона, в който ще бъдат всички промени. За целта изпълняваме командата:
hg сливане
И ако сливането е станало без конфликти, получаваме кода на проекта, към който се прилагат всички промени. Трябва да извършим тези промени:
hg commit -m "Обединяване"
И ги бутнете към сървъра:
hg push
Ако е имало конфликти по време на сливането, тогава програмата за сливане се отваря с три версии на конфликтния файл. Този прозорец шокира всички начинаещи :) Ако прозорецът не се отваря, значи може би вие не се отварятепомощната програма за сливане е конфигурирана или не е инсталирана. Препоръчвам да инсталирате и конфигурирате - в интернет има много статии по тази тема.
Има много помощни програми за сливане, няма да се спирам на никоя конкретна, ще ви кажа общите принципи. Всички те се различават леко по външен вид, контрол, някои се различават по кривина (вграденото сливане в NetBeans 6.9.1 ме ядосва с неудобството си, затова използвам meld).
Така се показват 3 версии на файла: локална, базова, отдалечена (някои имат и 4 версии - обединени). Това е BASE / MERGED, което вкарва всички в ступор.
Ще обясня какво е какво:LOCAL - файл с вашите редакцииREMOTE - файл от сървъраBASE - изходен файл, "некоригиран", към който е имало опит за прилагане на промени (локални и от сървъра).
Тук стигаме до един много деликатен момент. Както казах по-горе - имаме два филиала. В този случай клоновете са анонимни - тоест нямат име и са възникнали поради конфликт. След сливането разклонението ще изчезне и клоните ще се слеят в един "ствол". Следователно, ние правим всички промени в LOCAL файла - тоест в текущия ни проект.
Как точно да разрешите конфликта - тук самият разработчик си поставя главата как да модифицира кода, така че да има както тези, така и други промени в крайния файл.
Разглеждаме и коригираме всички конфликти, запазваме и излизаме от програмата.
След всички поправки, ние разглеждаме производителността на кода (уместно, ако промените не са били нетривиални). След това извършваме нашето сливане и го предаваме на сървъра с командите:
hg commit -m "Обединяване"hg push
Работният ден приключи, с чиста съвест се прибираме. Благодаря на всички!
PS: Можете да обсъждате, задавате въпроси за HG в специална тема на нашия форум.