Feature Branch у Git-у: шта је то, како креирати и радити са гранама

Шта је Feature Branch у Git-у

Feature Branch (грана функције) „ је привремена грана у Git-у, креирана од develop за развој посебне функционалности. За разлику од дуготрајних грана main и develop, feature гране постоје ограничено време „ од неколико сати до неколико недеља.

Основни циљ feature branch-а је да изолује промене везане за један задатак од остатка кода. Програмер може да експериментише, прави више комитова, па чак и да поквари код у својој грани, без утицаја на рад других чланова тима.

Након завршетка развоја, feature грана се спаја назад у develop путем Pull Request-а са обавезним прегледом кода. Након спајања, грана се обично брише како би репозиторијум остао чист.

Према Vincent Driessen, 2010, модел Git Flow са feature гранама постао је индустријски стандард захваљујући јасној подели одговорности између различитих типова грана.

Ток рада са Feature Branch

Ток рада са feature branch-ом се састоји од низа корака које програмер извршава за сваку нову функцију. Овај процес минимизира конфликте спајања и обезбеђује контролу квалитета кода.

1. Креирање гране од последњег comит-а develop-а. Програмер се пребацује на develop, ажурира га и креира нову feature грану.
2. Развој и комитови у feature грану. Програмер уноси измене, прави комитове са јасним описима и периодично гура грану у удаљени репозиторијум.
3. Синхронизација са develop „ током развоја главна грана може да напредује. Програмер ради rebase или merge develop-а у своју feature грану.
4. Креирање Pull Request-а „ када је функција готова, програмер отвара PR за преглед кода. Тим прегледа код и оставља коментаре.
5. Спајање и брисање „ након одобрења PR-а, грана се спаја у develop и брише се како локално, тако и удаљено.

Периодична синхронизација са develop је критично важна. Што дуже feature грана живи без спајања промена из develop-а, већа је вероватноћа конфликата при коначном спајању.

Учесталост синхронизације feature гране

Правила именовања feature грана

Именовање грана „ важан део тимске дисциплине. Јединствени стандард назива омогућава брзо одређивање на ком задатку се ради и ко га извршава.

• feature/назив „ префикс feature/ се користи у класичном Git Flow-у. Пример: feature/added-auth-module.
• feature/JIRA-123-опис „ повезивање са бројем задатка у систему за праћење. Пример: feature/PROJ-42-add-login.
• feature/тип/назив „ проширени формат са навођењем типа задатка. Пример: feature/feat/analytics-dashboard.

Коришћење ID-ја задатка из JIRA, Trello или другог система је најбоља пракса. Он аутоматски повезује код са задатком и поједностављује претрагу грана путем git log-а.

Процес Pull Request

Pull Request (или Merge Request у GitLab-у) „ је захтев за спајање feature гране у develop. PR није само техничка операција, већ процес тимског прегледа кода који подиже квалитет кода и шири знање унутар тима.

Добар PR садржи наслов са кратким описом задатка, линк до тикета и опис промена. Програмер треба да наведе шта је тачно урађено, које датотеке су измењене и да ли постоје потенцијални ризици за друге делове пројекта.

Тим прегледа код у PR-у, оставља коментаре, захтева измене (change requests) и одобрава спајање (approve). Након одобравања, извршава се merge или squash merge.

Просечно време прегледа PR-а у мобилном развоју је од 4 до 24 сата. Библиотека Danger аутоматизује део провера, покрећући lint-ере и тестове директно у PR-у.

Препоруке за креирање доброг PR-а

• Величина „ не више од 300-400 линија промена. Велики PR-ови су тешки за преглед, квалитет провере опада.
• Један PR „ један задатак „ избегавајте мешање неповезаних промена у једном захтеву.
• Снимци екрана „ за UI промене приложите снимке екрана пре и после.
• Тестови „ за нову функционалност пишите јединичне тестове и укључите их у PR.

Стратегије спајања feature грана

Након одобрења PR-а, feature грана може бити спојена у develop на различите начине. Избор стратегије спајања утиче на историју комитова и могућност враћања промена.

• Merge commit „ креира комит спајања, чувајући целу историју комитова feature гране. Историја остаје потпуна, али граф гранања постаје сложенији.
• Squash merge „ обједињује све комитове feature гране у један и додаје га изнад develop-а. Историја постаје чистија, али се информације о међукомитовима губе.
• Rebase and merge „ преписује комитове feature гране изнад последњег комита develop-а и спаја без додатног комита. Историја остаје линеарна.

За мобилне пројекте са честим издањима најчешће се користи squash merge: даје чисту историју у develop-у, а детаљи развоја остају у опису PR-а и задатку tracker-а.

Типичне грешке при раду са Feature Branch

Чак и искусни програмери праве грешке при раду са feature гранама. Познавање типичних проблема помаже да се избегне губитак времена и података.

• Сувише дуг живот гране „ feature грана живи дуже од 2-3 недеље без синхронизације са develop-ом, што доводи до масивних merge конфликата.
• Комитови са нејасним описима „ поруке типа „fix“ или „update“ не омогућавају разумевање шта је промењено и зашто.
• Мешање задатака „ у једној feature грани се развијају две неповезане функције, што онемогућава селективно враћање.
• Недостатак синхронизације „ програмер не ради git fetch и не ажурира develop, због чега при коначном merge-у настају конфликти.

Најбољи начин да се избегну ови проблеми је договор о правилима рада на почетку пројекта и коришћење аутоматских провера у CI/CD пајплајну.

Примери команди за рад са Feature Branch

Размотримо практични сценарио: програмер започиње нову функцију аутентификације у мобилној апликацији. Креира feature грану, ради на коду и завршава задатак Pull Request-ом.

# Ажурирање develop-а и креирање feature гране
git checkout develop
git pull origin develop
git checkout -b feature/add-login-screen

# Рад на функцији: комитови
git add src/ui/login/
git commit -m "Add login screen layout"

# Слање feature гране на сервер
git push origin feature/add-login-screen

# Синхронизација са develop (rebase)
git fetch origin develop
git rebase origin/develop

# Након одобрења PR-а: ажурирање локалног develop-а и брисање гране
git checkout develop
git pull origin develop
git branch -d feature/add-login-screen

Команда git branch -d брише грану тек након што су њене промене потпуно спојене. Ако грана није спојена, Git ће предложити коришћење git branch -D за принудно брисање „ користите овај флаг опрезно.

Аутоматизација провера у feature грани

CI/CD пајплајн треба да се покреће за сваку feature грану пре креирања PR-а. Ово омогућава откривање проблема у раној фази, пре него што код стигне на преглед другим програмерима.

# GitHub Actions за проверу feature гране
name: Feature Branch CI

on:
  push:
    branches:
      - 'feature/**'

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run tests
        run: ./gradlew test
      - name: Lint check
        run: ./gradlew lint

Пајплајн проверава да ли се код компајлира, тестови пролазе и стил кода одговара стандардима прихваћеним у тиму. Тек након проласка свих провера може се креирати Pull Request.