Feature Branch v Git: co to je, jak vytvořit a pracovat s větvemi

Co je Feature Branch v Git

Feature Branch (větev funkce) „ je dočasná větev v Git, vytvořená z develop pro vývoj samostatné funkcionality. Na rozdíl od dlouhožijících větví main a develop existují feature větve omezenou dobu „ od několika hodin do několika týdnů.

Hlavním cílem feature branch je izolovat změny související s jedním úkolem od zbytku kódu. Vývojář může experimentovat, dělat mnoho commitů a dokonce rozbít kód ve své větvi, aniž by ovlivnil práci ostatních členů týmu.

Po dokončení vývoje je feature větev sloučena zpět do develop prostřednictvím Pull Request s povinnou revizí kódu. Po sloučení je větev obvykle smazána, aby repozitář zůstal čistý.

Podle Vincent Driessen, 2010 se model Git Flow s feature větvemi stal průmyslovým standardem díky jasnému rozdělení odpovědnosti mezi různé typy větví.

Workflow práce s Feature Branch

Workflow s feature branch se skládá z posloupnosti kroků, které vývojář provádí pro každou novou funkci. Tento proces minimalizuje konflikty sloučení a zajišťuje kontrolu kvality kódu.

1. Vytvoření větve z posledního commitu develop. Vývojář přepne na develop, aktualizuje jej a vytvoří novou feature větev.
2. Vývoj a commity do feature větve. Vývojář provádí změny, dělá commity s jasnými popisy a pravidelně pushuje větev do vzdáleného repozitáře.
3. Synchronizace s develop „ během vývoje může hlavní větev pokročit. Vývojář provede rebase nebo merge develop do své feature větve.
4. Vytvoření Pull Request „ když je funkce hotová, vývojář otevře PR pro revizi kódu. Tým zkontroluje kód a zanechá komentáře.
5. Sloučení a smazání „ po schválení PR je větev sloučena do develop a smazána jak lokálně, tak vzdáleně.

Pravidelná synchronizace s develop je kriticky důležitá. Čím déle feature větev žije bez sloučení změn z develop, tím vyšší je pravděpodobnost konfliktů při konečném sloučení.

Frekvence synchronizace feature větve

Pravidla pojmenování feature větví

Pojmenování větví „ důležitá součást týmové disciplíny. Jednotný standard názvů umožňuje rychle určit, na jakém úkolu se pracuje a kdo jej provádí.

• feature/název „ prefix feature/ se používá v klasickém Git Flow. Příklad: feature/added-auth-module.
• feature/JIRA-123-popis „ vazba na číslo úkolu v systému sledování. Příklad: feature/PROJ-42-add-login.
• feature/typ/název „ rozšířený formát s uvedením typu úkolu. Příklad: feature/feat/analytics-dashboard.

Použití ID úkolu z JIRA, Trello nebo jiného systému je nejlepší praxí. Automaticky propojuje kód s úkolem a zjednodušuje vyhledávání větví pomocí git log.

Proces Pull Request

Pull Request (nebo Merge Request v GitLab) „ je žádost o sloučení feature větve do develop. PR není jen technická operace, ale proces týmové revize kódu, který zvyšuje kvalitu kódu a šíří znalosti v týmu.

Dobrý PR obsahuje nadpis s krátkým popisem úkolu, odkaz na ticket a popis změn. Vývojář by měl uvést, co přesně bylo provedeno, které soubory byly změněny a zda existují potenciální rizika pro jiné části projektu.

Tým prohlíží kód v PR, zanechává komentáře, požaduje změny (change requests) a schvaluje sloučení (approve). Po schválení se provede merge nebo squash merge.

Průměrná doba kontroly PR v mobilním vývoji je 4 až 24 hodin. Knihovna Danger automatizuje část kontrol, spouští lintery a testy přímo v PR.

Doporučení pro vytvoření dobrého PR

• Velikost „ ne více než 300-400 řádků změn. Velké PR se těžko revidují, kvalita kontroly klesá.
• Jeden PR „ jeden úkol „ vyhněte se míchání nesouvisejících změn v jedné žádosti.
• Screenshoty „ pro UI změny přiložte screenshoty před a po.
• Testy „ pro novou funkcionalitu pište unit testy a zahrňte je do PR.

Strategie sloučení feature větví

Po schválení PR může být feature větev sloučena do develop různými způsoby. Volba strategie sloučení ovlivňuje historii commitů a možnost vrácení změn.

• Merge commit „ vytváří commit sloučení, zachovává celou historii commitů feature větve. Historie zůstává úplná, ale graf větvení je složitější.
• Squash merge „ spojuje všechny commity feature větve do jednoho a přidává jej na vrchol develop. Historie se stává čistší, ale informace o mezilehlých commitech se ztrácejí.
• Rebase and merge „ přepisuje commity feature větve na vrchol posledního commitu develop a slučuje bez dalšího commitu. Historie zůstává lineární.

Pro mobilní projekty s častými vydáními se nejčastěji používá squash merge: poskytuje čistou historii v develop, zatímco detaily vývoje zůstávají v popisu PR a v úkolu trackeru.

Typické chyby při práci s Feature Branch

I zkušení vývojáři dělají chyby při práci s feature větvemi. Znalost typických problémů pomáhá vyhnout se ztrátě času a dat.

• Příliš dlouhá životnost větve „ feature větev žije déle než 2-3 týdny bez synchronizace s develop, což vede k masivním merge konfliktům.
• Commity s nejasnými popisy „ zprávy typu „fix” nebo „update” neumožňují pochopit, co bylo změněno a proč.
• Míchání úkolů „ v jedné feature větvi jsou vyvíjeny dvě nesouvisející funkce, což znemožňuje selektivní vrácení.
• Nedostatek synchronizace „ vývojář neprovádí git fetch a neaktualizuje develop, což způsobuje konflikty při konečném merge.

Nejlepším způsobem, jak se těmto problémům vyhnout, je dohodnout se na pravidlech práce na začátku projektu a používat automatické kontroly v CI/CD pipeline.

Příklady příkazů pro práci s Feature Branch

Podívejme se na praktický scénář: vývojář začíná novou funkci autentizace v mobilní aplikaci. Vytvoří feature větev, pracuje na kódu a dokončí úkol pomocí Pull Request.

# Aktualizace develop a vytvoření feature větve
git checkout develop
git pull origin develop
git checkout -b feature/add-login-screen

# Práce na funkci: commity
git add src/ui/login/
git commit -m "Add login screen layout"

# Odeslání feature větve na server
git push origin feature/add-login-screen

# Synchronizace s develop (rebase)
git fetch origin develop
git rebase origin/develop

# Po schválení PR: aktualizace lokálního develop a smazání větve
git checkout develop
git pull origin develop
git branch -d feature/add-login-screen

Příkaz git branch -d maže větev až poté, co jsou její změny plně sloučeny. Pokud větev není sloučena, Git navrhne použít git branch -D pro vynucené smazání „ používejte tento příznak opatrně.

Automatizace kontrol ve feature větvi

CI/CD pipeline by se měl spouštět pro každou feature větev před vytvořením PR. To umožňuje odhalit problémy v rané fázi, než se kód dostane k revizi ostatním vývojářům.

# GitHub Actions pro kontrolu feature větve
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

Pipeline kontroluje, zda se kód kompiluje, testy procházejí a styl kódu odpovídá standardům přijatým v týmu. Teprve po úspěšném absolvování všech kontrol lze vytvořit Pull Request.