3.4 Клонове в Git - Стратегии за работа с клонове код

Понеже Git използва просто трипосочно сливане, сливането на един клон с друг много пъти в продължение на дълъг период от време, е много лесно. Това означава, че можете да имате множество клонове, които са винаги отворени и които можете да ползвате за различни етапи на вашия цикъл от разработки и редовно да правите сливания на промените от един клон в друг.

Много разработчици, които ползват Git, следват подобна тактика - в master клона държат само напълно стабилния код, който е вече публикуван или ще бъде публикуван. Те имат отделен паралелен клон наречен develop или next, от който работят или тестват за стабилност — този код не е непременно стабилен, но щом стане такъв, може да се слее в master клона. Той се използва за създаването на допълнителни topic branches (клонове с кратък живот, подобни на вашия iss53) когато са готови, за да е сигурно, че те преминават всички тестове и не предизвикват грешки.

В действителност, говорим за указатели, които се преместват по линията на къмитите, които правим. Стабилните клонове са в долния край на линията на историята на къмитите, а най-новите - в горния край.

За улеснение, можем да мислим за тях като за работни помещения, където множествата къмити преминават към "по-стабилно" помещение, когато се изтестват напълно.

Можете да правите това за различни нива на стабилност. Някои по-големи проекти също така имат proposed или pu (proposed updates) клон интегриращ други такива, които може да не са готови да отидат в next или master клона. Идеята е, че клоновете код са с различни нива на стабилност и когато достигнат по-стабилен статус - се сливат с клона над тях. Да припомним отново - поддържането на long-running клонове не е необходимо, но често е полезно, особено когато си имате работа с много големи и сложни проекти.

Topic клоновете обаче, са полезни за проекти от всякакъв мащаб. Topic клонът е клон с кратък живот, който създавате за въвеждането на единична функционалност или свързана с нея работа. Това е нещо, което най-вероятно никога не сте правили с други VCS преди Git, защото в общи линии е скъп процес с тях. Но в Git е много лесно да създавате, работите, сливате и изтривате клонове по няколко пъти на ден.

Видяхте това в последната секция с клоновете iss53 и hotfix. Направихте няколко къмита в тях и ги изтрихте директно след като ги сляхте с master клона. Тази техника позволява да превключвате към различни контексти в проекта ви бързо и изцяло — понеже работата ви е изолирана в собствени клонове фокусирани в специфични задачи е по-лесно да преглеждате какво е ставало по време на специфичната разработка по даден проблем на проекта. Можете да си пазите промените там за минути, дни или месеци и да ги слеете, когато сте готови — без значение на последователността, в която са създавани или променяни.

Представете си пример - работите по проект в основния клон, създавате клон за решаване на възникнал проблем (iss91), работите в него известно време, създавате още един клон за да изпробвате втори начин за решаване на възникналия проблем (iss91v2), връщате се отново в master клона и работите по него дълго време. В един момент ви хрумва идея, за която не сте сигурни, че е толкова добра, но за да я изпробвате, създавате клон за нея (да го наречем dumbidea). Историята на къмитите ви би могла да изглежда така:

Сега нека кажем, че решавате да изберете второто решение на проблема като най-добро (iss91v2) и същевременно сте показали dumbidea клона на вашите колеги и той се е оказал гениално хрумване. Можете да захвърлите клона iss91 (губейки къмитите C5 и C6) и да слеете в master останалите два. Тогава историята ще изглежда така:

Ще обърнем повече внимание на различните работни стратегии в главата [ch05-distributed-git], така че преди да се спрете на конкретна схема за разклоняване за следващия ви проект, уверете се че сте я прочели.

Важно е просто да помните, че когато правите всичко това - тези клонове са изцяло локални. Когато разклонявате и сливате, всичко се прави единствено във вашето Git хранилище - не се извършва никаква мрежова комуникация.