Develop Branch w Git — co to jest, przeznaczenie i zasada działania

Czym jest Develop Branch w Git

Develop Branch (gałąź deweloperska) — to długożyjąca gałąź w Git Flow, która służy jako centralny węzeł integracji kodu od wszystkich programistów. Trafiają do niej gałęzie feature po zakończeniu rozwoju i przejściu code review.

Kod w develop zawsze znajduje się w stanie gotowym do utworzenia wydania, choć jeszcze nie został opublikowany w produkcji. Oznacza to, że wszystkie funkcje w develop przeszły recenzję, testowanie i sprawdzenia integracyjne, ale wciąż oczekują na swój cykl wydania.

W przeciwieństwie do main, gdzie każda wersja kodu to wydanie, develop zawiera ciągły strumień zmian. Commity w develop pojawiają się w miarę scalania gałęzi feature, co może występować kilka razy dziennie.

Według danych Vincent Driessen, 2010, develop jest kluczowym elementem udanego modelu rozgałęzień, ponieważ oddziela roboczą pracę od wersji gotowych do wydania.

Różnice między develop a main branch

Zrozumienie różnic między develop a main jest krytycznie ważne dla prawidłowej pracy w Git Flow. Te gałęzie pełnią różne funkcje i mają różne wymagania dotyczące stabilności.

Podział na develop i main pozwala zespołowi na ciągłą integrację nowego kodu bez ryzyka dla stabilności wersji produkcyjnej. Programiści mogą widzieć swój kod w develop natychmiast po zatwierdzeniu PR, nawet przed oficjalnym wydaniem.

Rola develop w Git Flow

W modelu Git Flow develop zajmuje centralne miejsce między gałęziami feature (źródło zmian) a gałęziami release (przygotowanie do wydania). Zrozumienie tej hierarchii jest podstawą efektywnego rozgałęziania.

• Feature → Develop — każda ukończona funkcja trafia do develop przez Pull Request z code review.
• Develop → Release — gdy zgromadzi się wystarczająca ilość zmian do wydania, z develop tworzona jest gałąź release.
• Release → Main + Develop — po końcowym przygotowaniu gałąź release jest scalana z main (wydanie) i z powrotem do develop (poprawki błędów).
• Hotfix → Main + Develop — krytyczne poprawki są tworzone z main i scalane z obiema gałęziami.

Taka struktura gwarantuje, że develop zawsze zawiera najnowszą wersję kodu ze wszystkimi nowymi funkcjami, a main — tylko sprawdzony kod produkcyjny. Jest to szczególnie ważne dla projektów mobilnych z długim cyklem recenzji w App Store i Google Play.

Powiązanie develop z innymi gałęziami Git Flow

Develop pełni rolę centralnego ogniwa między gałęziami feature, release i hotfix. Zrozumienie kierunków scalania jest podstawą zapobiegania konfliktom i utracie commitów.

Wymagania dotyczące jakości kodu w develop

Jakość kodu w develop musi być wysoka, ale nie absolutna. W przeciwieństwie do main, gdzie każdy błąd oznacza pilny hotfix, develop dopuszcza drobne niedoróbki, które zostaną poprawione przed wydaniem.

Minimalne wymagania dla kodu przed scalaniem do develop:

• Kompilacja — kod musi się kompilować bez błędów. Złamana kompilacja w develop blokuje pracę całego zespołu.
• Testy jednostkowe — wszystkie istniejące testy muszą przechodzić. Nowy kod powinien być pokryty testami w minimum 70%.
• Code style — kod musi być zgodny z przyjętymi w zespole standardami formatowania i nazewnictwa.
• Brak przestarzałych API — używanie przestarzałych metod jest niedozwolone w nowym kodzie.

Automatyczne sprawdzenia w CI/CD pipeline powinny uruchamiać się na każdy push do develop. Jeśli kompilacja się psuje, odpowiedzialny programista musi naprawić problem w ciągu godziny lub wycofać swój commit.

Sprawdzenia CI/CD dla develop

Konfiguracja GitHub Actions dla develop gwarantuje, że każdy PR przed scalaniem przechodzi automatyczne sprawdzenie. Typowy pipeline obejmuje kompilację, testy i linting.

# GitHub Actions — sprawdzanie develop po scalaniu
name: Develop CI

on:
  pull_request:
    branches: [develop]

jobs:
  validate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Unit tests
        run: ./gradlew testDebug
      - name: Lint
        run: ./gradlew lint
      - name: Build
        run: ./gradlew assembleDebug

Zasady scalania do develop

Scalanie do develop musi podlegać ścisłym zasadom, aby utrzymać stabilność gałęzi integracyjnej. Naruszenie tych zasad prowadzi do konfliktów, złamanych kompilacji i straty czasu zespołu.

• Tylko przez Pull Request — bezpośredni push do develop jest zabroniony. Wszystkie zmiany przechodzą code review.
• Minimum jeden approve — PR musi uzyskać zatwierdzenie co najmniej od jednego programisty nieuczestniczącego w zadaniu.
• Squash merge — zaleca się łączenie wszystkich commitów gałęzi feature w jeden podczas scalania do develop dla czystej historii.
• Aktualność PR — przed scalaniem PR musi być zaktualizowany względem ostatniego commita develop (rebase lub merge).

Zasada aktualności PR jest szczególnie ważna. Jeśli gałąź feature została utworzona tydzień temu, a develop poszedł do przodu o 50 commitów, bezpośrednie scalanie może prowadzić do konfliktów, które lepiej rozwiązać w kontekście PR, a nie w develop.

Ochrona develop przed nieprawidłowym scalaniem

Branch protection rules (zasady ochrony gałęzi) — to ustawienia na poziomie GitHub, GitLab lub Bitbucket, które zapobiegają nieprawidłowym zmianom w develop. Gwarantują, że nawet przypadkowy push nie złamie gałęzi integracyjnej.

Zalecane zasady ochrony dla develop:

• Require pull request — zablokuj bezpośredni push do develop. Wszystkie zmiany tylko przez PR.
• Require approvals — minimum 1-2 zatwierdzenia przed scalaniem PR.
• Require status checks — blokuj scalanie, jeśli CI/CD pipeline nie przeszedł.
• Require up-to-date — gałąź PR musi być zaktualizowana względem develop przed scalaniem.
• Restrict push access — ogranicz prawa do pusha w develop tylko dla senior developerów.

Konfiguracja ochrony develop zajmuje 10 minut, ale zapobiega tygodniom przestojów związanych ze złamaną gałęzią integracyjną. Dla projektów mobilnych z wieloplatformowymi zespołami jest to szczególnie istotne.

Przykłady poleceń do pracy z develop

Rozpatrzmy typowy dzień programisty: rano aktualizuje develop, tworzy nową gałąź feature, a po zakończeniu zadania scala zmiany z powrotem do develop.

# Poranna synchronizacja develop
git checkout develop
git pull origin develop

# Tworzenie nowej gałęzi feature z develop
git checkout -b feature/add-push-notifications

# Praca nad funkcją...
git add . && git commit -m "Add FCM integration"

# Aktualizacja develop podczas rozwoju
git fetch origin develop
git rebase origin/develop

# Po zatwierdzeniu PR — aktualizacja lokalnego develop
git checkout develop
git pull origin develop
git branch -d feature/add-push-notifications

Polecenie git pull w develop wykonuje jednocześnie dwie operacje: git fetch (pobiera nowe commity z serwera) i git merge (scala je z lokalną gałęzią). Dla develop jest to standardowy sposób synchronizacji.

Przywracanie develop po złamanym scalaniu

Jeśli do develop trafił kod, który złamał kompilację, należy działać szybko. Każda godzina przestoju develop to zablokowana praca całego zespołu programistów.

Jeśli do develop trafił kod, który złamał kompilację, użyj git revert do utworzenia nowego commita cofającego problematyczne zmiany. Nie używaj git reset w develop — to przepisuje historię, która już istnieje u innych uczestników.

# Znajdowanie problematycznego commita
git log --oneline develop

# Cofnięcie commita przez revert (bezpieczne)
git revert a1b2c3d

# Wysłanie poprawki do zdalnego develop
git push origin develop

# Przeglądanie zmian w konkretnym commicie
git show a1b2c3d --stat