Feature Branch w Git: co to jest, jak utworzyć i pracować z gałęziami

Co to jest Feature Branch w Git

Feature Branch (gałąź funkcji) „ to tymczasowa gałąź w Git, tworzona z develop do tworzenia oddzielnej funkcjonalności. W przeciwieństwie do długożyciowych gałęzi main i develop, gałęzie feature istnieją ograniczony czas „ od kilku godzin do kilku tygodni.

Głównym celem feature branch jest izolowanie zmian związanych z jednym zadaniem od reszty kodu. Programista może eksperymentować, robić wiele commitów, a nawet psuć kod w swojej gałęzi, nie wpływając na pracę innych członków zespołu.

Po zakończeniu tworzenia gałąź feature jest scalana z powrotem do develop przez Pull Request z obowiązkowym przeglądem kodu. Po scaleniu gałąź jest zwykle usuwana, aby repozytorium pozostawało czyste.

Według Vincent Driessen, 2010, model Git Flow z gałęziami feature stał się standardem branży dzięki wyraźnemu podziałowi odpowiedzialności między różnymi typami gałęzi.

Workflow pracy z Feature Branch

Workflow z feature branch składa się z sekwencji kroków, które programista wykonuje dla każdej nowej funkcji. Ten proces minimalizuje konflikty scalania i zapewnia kontrolę jakości kodu.

1. Tworzenie gałęzi od ostatniego commita develop. Programista przełącza się na develop, aktualizuje go i tworzy nową gałąź feature.
2. Tworzenie i commity w gałęzi feature. Programista wprowadza zmiany, robi commity zrozumiałymi opisami i okresowo wypycha gałąź do zdalnego repozytorium.
3. Synchronizacja z develop „ podczas tworzenia główna gałąź może pójść do przodu. Programista wykonuje rebase lub merge develop do swojej gałęzi feature.
4. Tworzenie Pull Request „ gdy funkcja jest gotowa, programista otwiera PR do przeglądu kodu. Zespół sprawdza kod i zostawia komentarze.
5. Scalenie i usunięcie „ po zatwierdzeniu PR gałąź jest scalana z develop i usuwana zarówno lokalnie, jak i zdalnie.

Okresowa synchronizacja z develop jest krytycznie ważna. Im dłużej żyje gałąź feature bez scalania zmian z develop, tym większe prawdopodobieństwo konfliktów przy końcowym scaleniu.

Częstotliwość synchronizacji gałęzi feature

Zasady nazewnictwa gałęzi feature

Nazewnictwo gałęzi „ ważna część dyscypliny zespołowej. Jednolity standard nazw pozwala szybko określić, nad jakim zadaniem trwa praca i kto je wykonuje.

• feature/nazwa „ prefiks feature/ jest używany w klasycznym Git Flow. Przykład: feature/added-auth-module.
• feature/JIRA-123-opis „ powiązanie z numerem zadania w systemie śledzenia. Przykład: feature/PROJ-42-add-login.
• feature/typ/nazwa „ rozszerzony format z określeniem typu zadania. Przykład: feature/feat/analytics-dashboard.

Używanie ID zadania z JIRA, Trello lub innego systemu to najlepsza praktyka. Automatycznie łączy kod z zadaniem i upraszcza wyszukiwanie gałęzi przez git log.

Proces Pull Request

Pull Request (lub Merge Request w GitLab) „ to żądanie scalenia gałęzi feature z develop. PR to nie tylko operacja techniczna, ale proces zespołowego przeglądu kodu, który podnosi jakość kodu i rozpowszechnia wiedzę w zespole.

Dobry PR zawiera tytuł z krótkim opisem zadania, link do ticketa i opis zmian. Programista powinien wskazać, co dokładnie zostało zrobione, jakie pliki zostały zmienione i czy istnieją potencjalne ryzyka dla innych części projektu.

Zespół przegląda kod w PR, zostawia komentarze, żąda zmian (change requests) i zatwierdza scalenie (approve). Po zatwierdzeniu PR wykonywany jest merge lub squash merge.

Średni czas sprawdzania PR w rozwoju mobilnym wynosi od 4 do 24 godzin. Biblioteka Danger automatyzuje część sprawdzeń, uruchamiając lintery i testy bezpośrednio w PR.

Zalecenia dotyczące tworzenia dobrego PR

• Rozmiar „ nie więcej niż 300-400 linii zmian. Duże PR są trudne do przejrzenia, jakość sprawdzania spada.
• Jeden PR „ jedno zadanie „ unikaj mieszania niezwiązanych zmian w jednym żądaniu.
• Zrzuty ekranu „ dla zmian UI dołączaj zrzuty ekranu przed i po.
• Testy „ dla nowej funkcjonalności pisz testy jednostkowe i dołączaj je do PR.

Strategie scalania gałęzi feature

Po zatwierdzeniu PR gałąź feature może być scalona z develop na różne sposoby. Wybór strategii scalania wpływa na historię commitów i możliwość wycofania zmian.

• Merge commit „ tworzy commit scalania, zachowując całą historię commitów gałęzi feature. Historia pozostaje pełna, ale graf rozgałęzień staje się bardziej złożony.
• Squash merge „ łączy wszystkie commity gałęzi feature w jeden i dodaje go na wierzch develop. Historia staje się czystsza, ale informacje o pośrednich commitach są tracone.
• Rebase and merge „ przepisuje commity gałęzi feature na wierzch ostatniego commita develop i scala bez dodatkowego commita. Historia pozostaje liniowa.

Dla projektów mobilnych z częstymi wydaniami najczęściej używa się squash merge: daje czystą historię w develop, a szczegóły tworzenia pozostają w opisie PR i w zadaniu trackera.

Typowe błędy przy pracy z Feature Branch

Nawet doświadczeni programiści popełniają błędy przy pracy z gałęziami feature. Znajomość typowych problemów pomaga uniknąć straty czasu i danych.

• Zbyt długie życie gałęzi „ gałąź feature żyje dłużej niż 2-3 tygodnie bez synchronizacji z develop, co prowadzi do masywnych konfliktów scalania.
• Commity z niejasnymi opisami „ komunikaty typu „fix” lub „update” nie pozwalają zrozumieć, co zostało zmienione i dlaczego.
• Mieszanie zadań „ w jednej gałęzi feature tworzone są dwie niezwiązane funkcje, co uniemożliwia selektywne wycofanie.
• Brak synchronizacji „ programista nie robi git fetch i nie aktualizuje develop, przez co przy końcowym merge powstają konflikty.

Najlepszym sposobem uniknięcia tych problemów jest ustalenie zasad pracy na starcie projektu i używanie automatycznych sprawdzeń w pipeline CI/CD.

Przykłady poleceń do pracy z Feature Branch

Rozważmy praktyczny scenariusz: programista zaczyna nową funkcję autoryzacji w aplikacji mobilnej. Tworzy gałąź feature, pracuje nad kodem i kończy zadanie Pull Requestem.

# Aktualizacja develop i utworzenie gałęzi feature
git checkout develop
git pull origin develop
git checkout -b feature/add-login-screen

# Praca nad funkcją: commity
git add src/ui/login/
git commit -m "Add login screen layout"

# Wysłanie gałęzi feature na serwer
git push origin feature/add-login-screen

# Synchronizacja z develop (rebase)
git fetch origin develop
git rebase origin/develop

# Po zatwierdzeniu PR: aktualizacja lokalnego develop i usunięcie gałęzi
git checkout develop
git pull origin develop
git branch -d feature/add-login-screen

Polecenie git branch -d usuwa gałąź tylko po tym, jak jej zmiany zostaną w pełni scalone. Jeśli gałąź nie jest scalona, Git zaproponuje użycie git branch -D do wymuszonego usunięcia „ używaj tego flagi ostrożnie.

Automatyzacja sprawdzeń w gałęzi feature

Pipeline CI/CD powinien uruchamiać się dla każdej gałęzi feature przed utworzeniem PR. Pozwala to wykryć problemy na wczesnym etapie, zanim kod trafi do przeglądu innym programistom.

# GitHub Actions do sprawdzania gałęzi 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

Pipeline sprawdza, czy kod się kompiluje, testy przechodzą i styl kodu jest zgodny z przyjętymi w zespole standardami. Dopiero po przejściu wszystkich sprawdzeń można utworzyć Pull Request.