Zespół tworzy aplikację równolegle: każda osoba bierze zadanie, robi dla niego osobną gałąź w Git, wysyła zmiany jako pull request, ktoś je sprawdza (code review), a po akceptacji kod trafia do głównej gałęzi i na produkcję. Konflikty biorą się stąd, że kilka osób zmienia ten sam kod, zanim wszystkie zmiany się spotkają. Ogranicza je dzielenie pracy na małe zadania, krótkie gałęzie, częste pobieranie zmian z main i wspólne zasady formatowania.Kiedy uczysz się sam, masz jedno repozytorium, jedną gałąź i pełną kontrolę nad każdą linijką. W zespole wszystko się zmienia: kilka osób dotyka tej samej aplikacji jednocześnie, a kod musi z tego wyjść spójny. Poniżej pokazujemy, jak taka praca wygląda od środka, dlaczego akurat w niej pojawiają się konflikty w Git i które nawyki sprawiają, że jest ich mniej.
Jak wygląda tworzenie aplikacji w zespole krok po kroku?
Szczegóły różnią się między firmami, ale schemat jest podobny prawie wszędzie:
| Etap | Co się dzieje | Efekt |
|---|---|---|
| 1. Zadanie | Zespół (z osobą odpowiedzialną za produkt) dzieli pracę na zadania w narzędziu typu Jira, Trello albo GitHub Issues | lista zadań (backlog), każde z krótkim opisem |
| 2. Gałąź | Programista pobiera najnowszy kod i tworzy dla zadania osobną gałąź | izolowana kopia, w której nie przeszkadza innym |
| 3. Kod | Pisze funkcję, testy i robi commity | zmiany na własnej gałęzi |
| 4. Pull request | Wysyła gałąź na GitHub i otwiera pull request (PR) z opisem | miejsce do rozmowy o zmianie |
| 5. Review i testy | Inna osoba czyta kod (code review), a automatyczne testy (CI) sprawdzają, czy nic się nie zepsuło | uwagi, poprawki, zielone testy |
| 6. Scalenie | Po akceptacji gałąź trafia do main | funkcja jest częścią aplikacji |
| 7. Wdrożenie | Aplikacja z nowym kodem trafia do użytkowników | zmiana działa na produkcji |
W tym schemacie nikt nie pracuje bezpośrednio na main. To gałąź „prawdy”: ma zawsze działać i na niej opiera się wdrożenie. Dlatego firmy często włączają w GitHubie ochronę gałęzi, która wymaga pull requesta i zaakceptowanego review, zanim cokolwiek do niej trafi.
Jeśli jesteś na początku drogi i dopiero wchodzisz do takiego procesu, podobnie wygląda pierwszy tydzień w nowej pracy. Pomocny jest wtedy buddy dla nowego członka zespołu, czyli osoba, która tłumaczy zasady, których nie ma w dokumentacji.
Dlaczego w zespole pracuje się na osobnych gałęziach?
Bo bez nich każdy zapisywałby swoje zmiany w tym samym miejscu i przeszkadzał innym w trakcie pracy. Gałąź (ang. branch) daje trzy rzeczy:
- Izolację. Niedokończona funkcja Anny nie psuje aplikacji, nad którą pracuje Piotr.
- Miejsce na review. Zmiany można przeczytać i skomentować, zanim trafią do wspólnego kodu.
- Łatwe wycofanie. Jeśli pomysł się nie sprawdzi, gałąź można porzucić bez śladu w
main.
Cena jest taka, że każda gałąź z czasem się „oddala” od main, bo w tym czasie ktoś inny scala własne zmiany. Im dłużej gałąź żyje, tym więcej różnic trzeba w końcu pogodzić. I tu zaczyna się temat konfliktów.
Jak utworzyć branch (gałąź) w Git i przełączać się między gałęziami?
Branch to po prostu nazwana linia zmian w repozytorium. Domyślnie masz jedną, zwykle main. Resztę tworzysz sam, najczęściej po jednej na zadanie.
Utwórz nowy branch i od razu na niego przejdź:
git switch -c feature/koszyk
Git odpowie: Switched to a new branch 'feature/koszyk'. Starsze poradniki używają git checkout -b feature/koszyk i też działa, ale git switch jest nowszy i jaśniejszy.
Sprawdź, na jakim branchu jesteś i jakie są inne:
git branch
Gwiazdka przy nazwie oznacza branch, na którym pracujesz. Samą bieżącą nazwę wypisze git branch --show-current. Żeby zobaczyć też branche ze zdalnego repozytorium (np. z GitHuba), użyj git branch -a.
Przełącz się na inny branch:
git switch main
Wyślij swój branch na GitHub:
git push -u origin feature/koszyk
Parametr -u zapamiętuje powiązanie z wersją zdalną, więc kolejne git push i git pull na tym branchu nie wymagają już podawania nazwy.
Usuń branch po scaleniu:
git branch -d feature/koszyk
-d usunie branch tylko wtedy, gdy jego zmiany są już scalone, więc to bezpieczna wersja. Wersję zdalną usuwasz osobno: git push origin --delete feature/koszyk.
| Chcę… | Polecenie |
|---|---|
| utworzyć branch i przejść na niego | git switch -c nazwa |
| zobaczyć lokalne branche | git branch |
| zobaczyć też branche zdalne | git branch -a |
| przełączyć się na istniejący branch | git switch nazwa |
| wysłać nowy branch na GitHub | git push -u origin nazwa |
| usunąć scalony branch lokalnie | git branch -d nazwa |
Dlaczego Git nie pozwala przełączyć się na inny branch?
Jeśli masz niezapisane zmiany w pliku, który różni się między branchami, Git odmówi przełączenia, żeby ich nie nadpisać:
error: Your local changes to the following files would be overwritten by checkout:
f.txt
Please commit your changes or stash them before you switch branches.
Masz dwie drogi: zatwierdzić zmiany (git commit) albo schować je tymczasowo (git stash). To nie konflikt, tylko zabezpieczenie.
Jak nazywać branche w zespole?
Nazwa ma mówić, czego dotyczy zadanie. Zespoły często stosują prefiksy, np. feature/koszyk dla nowej funkcji i fix/blad-platnosci dla poprawki. Konkretną konwencję ustala zespół, ważne, żeby wszyscy używali tej samej i żeby nazwa odpowiadała zadaniu w Jirze lub GitHub Issues.
Skąd w pracy zespołowej biorą się konflikty?
Konflikt nie jest dowodem, że ktoś popełnił błąd. To naturalny skutek pracy równoległej: dwie osoby, każda na własnej gałęzi, zmieniły to samo miejsce, a Git przy łączeniu nie wie, którą wersję wybrać. Najczęściej dzieje się to w plikach, które dotyka wielu ludzi:
- plik z listą tras lub menu, do którego każda nowa funkcja dopisuje jedną linię,
package.json, bo każdy dodaje własną bibliotekę,- wspólne style lub konfiguracja,
- duży, „wielofunkcyjny” plik, w którym mieszka połowa logiki aplikacji,
- pliki generowane (np. blokada zależności), jeśli ktoś je zmieni ręcznie.
Samo rozwiązywanie konfliktu (jak go przeczytać, wybrać wersję, dokończyć scalanie i wycofać się) opisujemy osobno w artykule o konfliktach w Git krok po kroku. Tutaj skupiamy się na tym, jak organizacja pracy sprawia, że konfliktów jest mniej.
Jak ograniczyć liczbę konfliktów w zespole?
| Nawyk | Dlaczego to działa |
|---|---|
| Małe zadania i krótkie gałęzie | im mniej czasu gałąź żyje, tym mniej zmian zdąży się nazbierać na main |
Często pobieraj main do swojej gałęzi | konflikt wykryjesz po jednym dniu pracy, a nie po trzech tygodniach, kiedy jest ich dziesięć |
| Jedna gałąź, jeden cel | pull request o jednej sprawie łatwiej przeczytać i łatwiej scalić |
| Rozmowa przed ruszeniem wspólnego pliku | jedno zdanie na czacie („zmieniam teraz routing”) potrafi uniknąć godziny rozwiązywania konfliktu |
| Podział odpowiedzialności za obszary kodu | gdy dwie osoby nie zmieniają tego samego modułu naraz, rzadziej wchodzą sobie w drogę |
Wspólne formatowanie (Prettier, .editorconfig) | znikają konflikty o spacje, wcięcia i średniki |
| Nie mieszaj refaktoryzacji z nową funkcją | zmiana nazwy w 40 plikach „przy okazji” zamienia każdą cudzą gałąź w pole minowe |
Dwa z tych punktów wymagają krótkiego omówienia.
Jak często aktualizować swoją gałąź względem main?
Najlepiej na początku każdego dnia pracy nad zadaniem, które trwa dłużej niż jeden dzień, oraz zawsze tuż przed otwarciem pull requesta. Robisz to jednym z dwóch poleceń:
git switch moja-funkcja
git merge main
albo, jeśli zespół woli liniową historię:
git switch moja-funkcja
git rebase main
Jedno i drugie przenosi do Twojej gałęzi nowości z main. Który wariant wybrać, ustala zespół, nie pojedyncza osoba, bo od tego zależy wygląd historii i sposób rozwiązywania ewentualnych konfliktów. Jak różnią się rodzaje łączenia (fast-forward, merge commit, squash, rebase) i kiedy każde z nich może dać konflikt, pokazujemy w artykule o konfliktach w Git.
Dlaczego formatowanie kodu ma związek z konfliktami?
Bo narzędzie do formatowania zmienia wiele linii naraz. Jeśli Anna ma w edytorze cztery spacje, a Piotr dwie, każde zapisanie pliku „zmienia” cały plik, a Git widzi to jako zmiany tych samych linii. Wspólna konfiguracja Prettiera lub pliku .editorconfig w repozytorium ustawia jedną regułę dla wszystkich i usuwa ten rodzaj konfliktów u źródła. Dobrze, gdy formatowanie uruchamia się też automatycznie, np. przy commicie.
Jaki model pracy z gałęziami wybrać?
Zespoły rzadko wymyślają własny schemat, najczęściej wybierają jeden ze znanych:
| Model | Jak działa | Kiedy ma sens |
|---|---|---|
| GitHub flow | main + krótkie gałęzie funkcji + pull request | większość zespołów, szczególnie przy częstych wdrożeniach |
| Git flow | dodatkowe gałęzie develop, release, hotfix | projekty z wydaniami w ustalonych terminach |
| Trunk-based | wszyscy scalają do main bardzo często, w małych porcjach | zespoły z dobrymi testami automatycznymi |
Dla początkującego najważniejsza jest wspólna zasada, nie nazwa modelu: każdy wie, z jakiej gałęzi zaczyna, dokąd ją scala i kto ją akceptuje. Projekt, w którym trzy osoby używają trzech różnych schematów, produkuje więcej konfliktów niż jakikolwiek model teoretycznie „lepszy”.
Czy samo scalenie bez konfliktu oznacza, że kod działa?
Nie. Git ostrzega tylko wtedy, gdy zmieniono te same linie. Jeśli Anna zmieni nazwę funkcji, a Piotr w nowym pliku użyje starej, scalenie przejdzie bez słowa, a aplikacja przestanie działać. Dlatego w zespołach istnieją automatyczne testy (CI) uruchamiane na każdym pull requeście oraz review, a nie tylko polecenia Gita. Przykład takiego przypadku, sprawdzony w praktyce, opisujemy w artykule o konfliktach.
Dlaczego nie warto czekać z pull requestem, aż kod będzie „idealny”?
Początkujący często boją się otworzyć pull request, dopóki wszystko nie jest dopracowane. Skutek jest odwrotny od zamierzonego: im dłużej gałąź żyje, tym większy robi się pull request i tym więcej konfliktów trzeba rozwiązać. Lepiej wysłać mniejszą zmianę wcześniej i poprawić ją po uwagach z review.
Jak ćwiczyć pracę zespołową, gdy uczysz się sam?
Nawyki z tego tekstu można zbudować jeszcze przed pierwszą pracą:
- Pracuj na gałęziach nawet we własnym projekcie. Jedna gałąź na jedno zadanie i pull request do samego siebie to trening bez ryzyka. Podstawy znajdziesz w artykule o clone, fork i pull request.
- Poproś kogoś o review. Opis zmian i komentarze pod kodem uczą więcej niż samodzielne poprawki. Jak je robić i czego oczekiwać, wyjaśniamy w tekście o code review.
- Pracuj w parze lub małym projekcie z drugą osobą. Pierwszy prawdziwy konflikt dużo uczy, a lepiej, żeby wydarzył się w projekcie treningowym niż w pracy. Pomysły na wspólne ćwiczenia znajdziesz w artykule o tym, co przyszli programiści mogą robić w parze.
- Ćwicz komunikację. Sam Git nie nauczy Cię, jak zapytać kolegę, dlaczego wybrał takie rozwiązanie. O tym piszemy w artykule o umiejętnościach miękkich programisty.
W kursie JavaScript zadania zgłaszasz jako pull requesty, a mentor robi code review Twojego kodu, więc ten element pracy zespołowej ćwiczysz na własnych zadaniach i projektach.
