-
1. Начало
- 1.1 За Version Control системите
- 1.2 Кратка история на Git
- 1.3 Какво е Git
- 1.4 Конзолата на Git
- 1.5 Инсталиране на Git
- 1.6 Първоначална настройка на Git
- 1.7 Помощна информация в Git
- 1.8 Обобщение
-
2. Основи на Git
-
3. Клонове в Git
-
4. GitHub
-
5. Git инструменти
- 5.1 Избор на къмити
- 5.2 Интерактивно индексиране
- 5.3 Stashing и Cleaning
- 5.4 Подписване на вашата работа
- 5.5 Търсене
- 5.6 Манипулация на историята
- 5.7 Мистерията на командата Reset
- 5.8 Сливане за напреднали
- 5.9 Rerere
- 5.10 Дебъгване с Git
- 5.11 Подмодули
- 5.12 Пакети в Git (Bundling)
- 5.13 Заместване
- 5.14 Credential Storage система
- 5.15 Обобщение
-
6. Настройване на Git
- 6.1 Git конфигурации
- 6.2 Git атрибути
- 6.3 Git Hooks
- 6.4 Примерна Git-Enforced политика
- 6.5 Обобщение
-
7. Git и други системи
- 7.1 Git като клиент
- 7.2 Миграция към Git
- 7.3 Обобщение
-
8. Git на ниско ниво
- 8.1 Plumbing и Porcelain команди
- 8.2 Git обекти
- 8.3 Git референции
- 8.4 Packfiles
- 8.5 Refspec спецификации
- 8.6 Транспортни протоколи
- 8.7 Поддръжка и възстановяване на данни
- 8.8 Environment променливи
- 8.9 Обобщение
-
9. Приложение A: Git в други среди
-
10. Приложение B: Вграждане на Git в приложения
- 10.1 Git от команден ред
- 10.2 Libgit2
- 10.3 JGit
- 10.4 go-git
- 10.5 Dulwich
-
A1. Приложение C: Git команди
- A1.1 Настройки и конфигурация
- A1.2 Издърпване и създаване на проекти
- A1.3 Snapshotting
- A1.4 Клонове и сливане
- A1.5 Споделяне и обновяване на проекти
- A1.6 Инспекция и сравнение
- A1.7 Дебъгване
- A1.8 Patching
- A1.9 Email команди
- A1.10 Външни системи
- A1.11 Административни команди
- A1.12 Plumbing команди
3.4 Клонове в Git - Стратегии за работа с клонове код
Стратегии за работа с клонове код
След като вече имате основните познания за разклоняване и сливане на код, нека видим какво можете и следва да правите с тях. Тук ще разгледаме някои стандартни стратегии за работа с клонове код, които стават възможни благодарение на лекотата, с която Git управлява разклоненията. Може да решите да използвате някои от тях във вашия цикъл на разработки.
Дълго използвани клонове
Понеже Git използва просто трипосочно сливане, сливането на един клон с друг много пъти в продължение на дълъг период от време, е много лесно. Това означава, че можете да имате множество клонове, които са винаги отворени и които можете да ползвате за различни етапи на вашия цикъл от разработки и редовно да правите сливания на промените от един клон в друг.
Много разработчици, които ползват Git, следват подобна тактика - в master
клона държат само напълно стабилния код, който е вече публикуван или ще бъде публикуван.
Те имат отделен паралелен клон наречен develop
или next
, от който работят или тестват за стабилност — този код не е непременно стабилен, но щом стане такъв, може да се слее в master
клона.
Той се използва за създаването на допълнителни topic branches (клонове с кратък живот, подобни на вашия iss53
) когато са готови, за да е сигурно, че те преминават всички тестове и не предизвикват грешки.
В действителност, говорим за указатели, които се преместват по линията на къмитите, които правим. Стабилните клонове са в долния край на линията на историята на къмитите, а най-новите - в горния край.
![Линеен изглед на progressive-stability разклоняване](png/lr-branches-1.png)
За улеснение, можем да мислим за тях като за работни помещения, където множествата къмити преминават към "по-стабилно" помещение, когато се изтестват напълно.
![Дървовиден изглед на progressive-stability разклоняване](png/lr-branches-2.png)
Можете да правите това за различни нива на стабилност.
Някои по-големи проекти също така имат proposed
или pu
(proposed updates) клон интегриращ други такива, които може да не са готови да отидат в next
или master
клона.
Идеята е, че клоновете код са с различни нива на стабилност и когато достигнат по-стабилен статус - се сливат с клона над тях.
Да припомним отново - поддържането на long-running клонове не е необходимо, но често е полезно, особено когато си имате работа с много големи и сложни проекти.
Topic клонове
Topic клоновете обаче, са полезни за проекти от всякакъв мащаб. Topic клонът е клон с кратък живот, който създавате за въвеждането на единична функционалност или свързана с нея работа. Това е нещо, което най-вероятно никога не сте правили с други VCS преди Git, защото в общи линии е скъп процес с тях. Но в Git е много лесно да създавате, работите, сливате и изтривате клонове по няколко пъти на ден.
Видяхте това в последната секция с клоновете iss53
и hotfix
.
Направихте няколко къмита в тях и ги изтрихте директно след като ги сляхте с master
клона.
Тази техника позволява да превключвате към различни контексти в проекта ви бързо и изцяло — понеже работата ви е изолирана в собствени клонове фокусирани в специфични задачи е по-лесно да преглеждате какво е ставало по време на специфичната разработка по даден проблем на проекта.
Можете да си пазите промените там за минути, дни или месеци и да ги слеете, когато сте готови — без значение на последователността, в която са създавани или променяни.
Представете си пример - работите по проект в основния клон, създавате клон за решаване на възникнал проблем (iss91
), работите в него известно време, създавате още един клон за да изпробвате втори начин за решаване на възникналия проблем (iss91v2
), връщате се отново в master
клона и работите по него дълго време. В един момент ви хрумва идея, за която не сте сигурни, че е толкова добра, но за да я изпробвате, създавате клон за нея (да го наречем dumbidea
).
Историята на къмитите ви би могла да изглежда така:
![Множество topic клонове](png/topic-branches-1.png)
Сега нека кажем, че решавате да изберете второто решение на проблема като най-добро (iss91v2
) и същевременно сте показали dumbidea
клона на вашите колеги и той се е оказал гениално хрумване.
Можете да захвърлите клона iss91
(губейки къмитите C5
и C6
) и да слеете в master
останалите два.
Тогава историята ще изглежда така:
![Историята след сливането на `dumbidea` и `iss91v2`](png/topic-branches-2.png)
dumbidea
и iss91v2
Ще обърнем повече внимание на различните работни стратегии в главата [ch05-distributed-git], така че преди да се спрете на конкретна схема за разклоняване за следващия ви проект, уверете се че сте я прочели.
Важно е просто да помните, че когато правите всичко това - тези клонове са изцяло локални. Когато разклонявате и сливате, всичко се прави единствено във вашето Git хранилище - не се извършва никаква мрежова комуникация.