3.4 Гранење во Git - Работни процеси

Бидејќи Git користи едноставна комбинација од три начини, спојувањето од една гранка во друго повеќе пати во текот на еден долг период обично е лесно да се направи. Ова значи дека можете да имате неколку гранки кои се секогаш отворени и што ги користите за различни фази од вашиот циклус на развој; можете редовно да се спојувате од некои од нив во други.

Многу програмери на Git имаат работен тек кој го прифаќа овој пристап, како што има само код кој е целосно стабилен во нивната "мастер" гранка - можеби само код кој е или ќе биде пуштен на слобода. Тие имаат друга паралелна гранка наречена develop или` next` дека работат или користат за тестирање на стабилноста - не секогаш мора да биде стабилна, но секогаш кога станува стабилна, таа може да се спои со господар. Се користи за да се повлече во гранките на теми (кратки живи гранки, како што е претходната гранка на iss53), кога тие се подготвени, за да се осигураат дека ги поминат сите тестови и не воведуваат бубачки.

Во реалноста, зборуваме за совети кои се движат по линијата на обврските што ги правиш. Стабилните гранки се подалеку од линијата во вашата историја на извршување, а гранките на крварење се подалеку од историјата.

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

Можете да продолжите да го направите ова за неколку нивоа на стабилност. Некои поголеми проекти, исто така, имаат "предложен" или "pu` (предложена надградба) гранка која има интегрирани гранки кои можеби не се подготвени да влезат во` следната` или майстер филијалата. Идејата е дека твоите гранки се на различни нивоа на стабилност; кога ќе стигнат до постабилно ниво, тие се спојуваат во гранката над нив. Повторно, не постојат повеќе долготрајни гранки, но често е корисно, особено кога работите со многу големи или комплексни проекти.

Филијалата на теми, сепак, се корисни во проекти од било која големина. Филијалата на теми е краткотрајна гранка што ја креирате и користите за една посебна карактеристика или поврзана работа. Ова е нешто што веројатно никогаш не сте го направиле со VCS, бидејќи обично е премногу скапо за создавање и спојување на гранките. Но, во Git, заеднички е да создавате, да работите, спојтете и да бришете гранки неколку пати на ден.

Ова го видете во последниот дел со гранките iss53 и` hotfix` што ги креиравте. Сте направиле неколку обврски на нив и ги избришавте директно откако ги споивте во вашата главна гранка. Оваа техника ви овозможува брзо и целосно да се префрлите на контекстот - бидејќи вашата работа е одделена во силоси каде што сите промени во таа гранка имаат врска со таа тема, полесно е да се види што се случило за време на прегледот на кодот и слично. Тука може да ги задржите промените со минути, денови или месеци и да ги споите кога ќе бидат подготвени, без оглед на редоследот на кој тие биле создадени или работеле.

Размислете за пример да направите некоја работа (на master), разградувајќи се за некое прашање (` iss91`), работејќи на него за малку, разгранувајќи од втората гранка за да пробате друг начин за ракување со истото (iss91v2 ), се враќате во вашата "господарска гранка" и работите таму некое време, а потоа разградувате таму за да направите некоја работа што не сте сигурни е добра идеја (dumbidea branch). Вашата историја на извршување ќе изгледа вака:

Сега, да речеме да одлучите дека ви се допаѓа второто решение за вашето прашање најдобро (iss91v2); и ја покажавте dumbidea гранката на твоите соработници, и излегува дека е гениј. Можете да го исфрлите оригиналниот грант iss91 (губење на обврски` C5` и C6) и да се спојат во другите две. Вашата историја изгледа вака:

Ќе разгледаме повеќе можни работни процеси за вашиот Git проект во << ch05-distributed-git >>, па пред да одлучите која шема за разгранување ќе го користи вашиот следен проект, не заборавајте да го прочитате тоа поглавје.

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