--- title: "Zatwierdzanie i merge: co zawsze robi człowiek" description: "Co w pracy z agentami zawsze robi człowiek: zatwierdzenie zmiany związane z commitem, różnica między zgodą w rozmowie a zatwierdzeniem w GitLabie, merge i flaga AUTOMERGE." url: "https://monolynx.com/blog/zatwierdzanie-i-merge-w-monolynx" lang: "pl" author: "Zespół Monolynx" published: "2026-10-09T07:15:22.907179+00:00" modified: "2026-10-09T18:11:34.352469+00:00" last_verified: "2026-10-09" tags: ["monolynx", "plugin", "merge-request", "mr-queue"] translations: [] reading_time_minutes: 8 word_count: 1445 --- > [!TLDR] > - Agent może napisać kod, otworzyć merge request, naprawić CI i rozwiązać konflikt. Zatwierdzenie zmiany zawsze zostaje człowiekowi. > - Zgodę kolejce dajesz w rozmowie. Jest związana z konkretnym commitem, więc każda nowa zmiana na branchu wymaga jej ponownie. > - Formalnego zatwierdzenia w GitLabie albo GitHubie agent nie kliknie nigdy, żadna flaga tego nie zmienia. > - Merge wykonuje kolejka po Twojej zgodzie, a z flagą `MONOLYNX_AUTOMERGE` bez dodatkowego pytania. > - Merge brancha sprintu do gałęzi głównej robisz Ty. ## Kto co może zrobić z merge requestem? Granica jest prosta: agent przygotowuje zmianę do decyzji, a decyzję podejmuje człowiek. Poniższa tabela pokazuje ją czynność po czynności. **Porównanie** | Czynność | Agent | Człowiek | | --- | --- | --- | | Otwarcie merge requesta | tak, po zgodzie flagą `MONOLYNX_AUTOMR` | zawsze może | | Naprawa czerwonego CI | tak, najwyżej dwie rundy | po dwóch nieudanych rundach | | Rozwiązanie konfliktu | tak, przez wciągnięcie brancha docelowego | gdy konfliktu nie da się rozwiązać | | Zatwierdzenie zmiany | nie | zawsze | | Merge ticketu | tak, po Twojej zgodzie | zawsze może | | Merge brancha sprintu do gałęzi głównej | nie | zawsze | **Statystyki** - **1** - czynność, której agent nie wykona nigdy: zatwierdzenie - **2** - rundy naprawy CI, zanim kolejka odda sprawę człowiekowi - **1** - commit, z którym związana jest każda Twoja zgoda **Decyzje kolejki dla jednego merge requesta** Kolejka bierze pierwszy merge request i sprawdza go w stałej kolejności. Konflikt rozwiązuje sama. Czerwone CI naprawia sama, najwyżej dwa razy. Gdy brakuje zatwierdzenia, pyta człowieka. Po zgodzie merguje dokładnie ten commit, który człowiek zatwierdził. ```mermaid flowchart TD A["Merge request"] --> B{"Konflikt?"} B -- "tak" --> C["Kolejka: wciąga branch docelowy"] B -- "nie" --> D{"CI zielone?"} D -- "nie" --> E["Kolejka: naprawa, do 2 rund"] D -- "tak" --> F{"Zatwierdzone?"} F -- "nie" --> G["Pytanie do człowieka"] G -- "tak" --> H["Merge tego commita"] F -- "tak" --> H ``` ## Jak zatwierdzić zmianę w kolejce? Gdy merge request ma zielone CI i brakuje mu tylko zatwierdzenia, kolejka zatrzymuje się i pyta. **Pytanie kolejki o zatwierdzenie** ```console > /monolynx:mr-queue !42 SKL-12: eksport zamówień do CSV CI: zielone | konflikt: brak | zatwierdzenie: brak Approve !42 (SKL-12: eksport zamówień do CSV, SHA 4f2a9c1e)? tak / nie MR-QUEUE: remaining=3 current=!42 verdict=needs_approval done=1 ``` **Kroki** 1. **Otwórz merge request** Przeczytaj zmianę w GitLabie albo GitHubie, tak jak czytasz zmianę kolegi. 2. **Sprawdź komentarze ticketu** Plan, raporty agentów i ocena krytyka mówią, co i dlaczego zostało zrobione. 3. **Odpowiedz w rozmowie** "tak" zapisuje zgodę dla pokazanego commita. "nie" zostawia merge request w kolejce. 4. **Poczekaj na następny tick** Kolejka policzy stan ponownie i zmerguje dokładnie ten commit. ### Dlaczego zgoda jest związana z commitem? Zatwierdzasz konkretną treść, a nie numer merge requesta. Gdy po Twojej zgodzie na branchu pojawi się nowy commit, zgoda przestaje obowiązywać. Dotyczy to także poprawki, którą zrobiła sama kolejka. > [!IMPORTANT] > Merge idzie z blokadą na commit, który oceniłeś. Jeśli branch zmieni się między Twoją zgodą a merge, GitLab albo GitHub odrzuci operację, a kolejka zapyta ponownie przy następnym ticku. ### Zgoda w rozmowie a zatwierdzenie w GitLabie To dwie różne rzeczy i warto wiedzieć, która jest potrzebna w Twoim projekcie. **Porównanie** | Cecha | Zgoda w rozmowie | Zatwierdzenie w GitLabie albo GitHubie | | --- | --- | --- | | Gdzie ją dajesz | w sesji z kolejką | w interfejsie merge requesta | | Kto może ją dać | Ty | osoba z uprawnieniami w repozytorium | | Co zapisuje | kolejka, razem z identyfikatorem commita | platforma, w historii merge requesta | | Czy agent może ją dać | nie | nie | | Kiedy wystarcza | gdy repozytorium nie wymaga formalnych zatwierdzeń | zawsze | Gdy repozytorium ma regułę wymagającą formalnych zatwierdzeń, sama zgoda w rozmowie nie wystarczy. Platforma odrzuci merge, a kolejka pokaże jej komunikat. Zatwierdź wtedy zmianę w interfejsie i uruchom kolejkę ponownie. > [!NOTE] > Kolejka uznaje merge request za zatwierdzony, gdy zatwierdziła go w GitLabie konkretna osoba. Sam znacznik "zatwierdzone" w projekcie, który nie wymaga żadnych zatwierdzeń i nie ma na liście nikogo, nie liczy się jako zgoda. ## Jak działa merge i co zmienia flaga? Po zgodzie kolejka wykonuje merge sama. Sposób pilnują dwie rzeczy: strażnik komend i jedna flaga. **Porównanie** | Ustawienie | Co się dzieje przy merge | | --- | --- | | `MONOLYNX_AUTOMERGE` nieustawiona | strażnik komend pyta Cię o każde polecenie merge | | `MONOLYNX_AUTOMERGE` ustawiona na `true` | kolejka merguje gotowy merge request bez dodatkowego pytania | | sesja w tle | pytanie zamienia się w odmowę; bez flagi kolejka kończy turę linią z powodem | > [!CAUTION] > Flaga `MONOLYNX_AUTOMERGE` usuwa pytanie o merge, ale nie usuwa pytania o zatwierdzenie. Merge request bez Twojej zgody nie zostanie zmergowany przy żadnym ustawieniu. **Metoda merge i to, co dzieje się po nim** Metodę wybiera zmienna `MONOLYNX_MERGE_METHOD`: `merge` (domyślnie), `squash` albo `rebase`. Po merge do brancha sprintu kolejka od razu ustawia ticket jako Gotowy i bierze następny merge request. Po merge do domyślnego brancha repozytorium czeka najpierw na zielone CI tego brancha. Kolejka sama nigdy nie robi na branchu ticketu wymuszonego pusha, rebase'u ani resetu. Konflikt rozwiązuje przez wciągnięcie brancha docelowego do brancha ticketu. Metoda `rebase` to co innego: wykonuje ją GitLab albo GitHub w chwili merge, bo tak ustawiłeś zmienną. ## Co kolejka robi w tle, gdy nikt nie odpowiada? Kolejka uruchomiona w skrypcie albo w sesji bez człowieka nie może zadać pytania. Zamiast czekać, kończy turę jedną linią z powodem. **Kolejka w tle czeka na człowieka** ```console MR-QUEUE STOP: !42 czeka na approve MR-QUEUE: remaining=3 current=!42 verdict=needs_approval done=1 ``` Kolejka stoi wtedy na pierwszym merge requeście i nie przeskakuje do następnego. To celowe: merge requesty idą po kolei, bo każdy kolejny może zależeć od poprzedniego. > [!TIP] > W sprincie prowadzonym pętlami trzymaj kolejkę w sesji interaktywnej, czyli `/loop 10m /monolynx:mr-queue` w otwartym oknie. Wtedy pytanie o zatwierdzenie pojawia się w rozmowie i odpowiadasz jednym słowem. ## Merge sprintu do gałęzi głównej Kolejka prowadzi merge requesty ticketów do brancha sprintu. Ostatni krok, czyli merge całego brancha sprintu do gałęzi głównej, zostaje przy człowieku. W projekcie z branchem `develop` to dwa merge: sprint do `develop`, potem `develop` do `main`. **Kroki** 1. **Sprawdź tablicę** Wszystkie tickety sprintu mają status Gotowe. 2. **Otwórz merge request sprintu** Z brancha sprintu do gałęzi głównej, tak jak każdy inny. 3. **Poczekaj na pełne CI** To pierwszy moment, w którym wszystkie zmiany sprintu są testowane razem na docelowej gałęzi. 4. **Zatwierdź i zmerguj** Sam albo z zespołem, zgodnie z zasadami repozytorium. 5. **Zamknij sprint** Uruchom `/monolynx:sprint-end`. > [!WARNING] > Merge request sprintu otwórz dopiero po zmergowaniu ticketów albo trzymaj go do tego czasu jako draft. Kolejka sama dopisuje każdy otwarty merge request, a drafty pomija. Otwarty wcześniej, trafiłby do kolejki między tickety i zatrzymał ją pytaniem o zatwierdzenie. ## Najczęstsze pytania **FAQ** ### Czy mogę zatwierdzić kilka merge requestów naraz? Nie w jednej odpowiedzi. Kolejka pyta o pierwszy, merguje go i dopiero wtedy przechodzi do następnego. Dzięki temu każdy następny jest sprawdzany na kodzie, który zawiera już poprzedni. ### Co się stanie, gdy odpowiem "nie"? Tick się kończy, a merge request zostaje pierwszy w kolejce. Kolejka zapyta ponownie przy następnym ticku. Żeby go pominąć, zamknij merge request albo usuń go z kolejki. ### Czy agent może zatwierdzić własną zmianę? Nie. Polecenia zatwierdzenia strażnik komend odmawia agentom pomocniczym, a sesję główną zawsze pyta. Żadna flaga tego nie wyłącza. ### Zatwierdziłem zmianę, a kolejka pyta ponownie. Dlaczego? Na branchu pojawił się nowy commit: poprawka CI, rozwiązanie konfliktu albo ręczna zmiana. Zgoda dotyczyła poprzedniego commita, więc przeczytaj różnicę i odpowiedz jeszcze raz. ### Czy kolejka działa z GitHubem? Tak. Obsługuje merge requesty GitLaba przez narzędzie `glab` i pull requesty GitHuba przez narzędzie `gh`. Zasady zatwierdzania są te same. ## Słownik i następny krok **Słownik** - **Zatwierdzenie** - decyzja człowieka, że zmianę można zmergować; po angielsku approve - **Zgoda w rozmowie** - zatwierdzenie wyrażone w sesji z kolejką, zapisane razem z identyfikatorem commita - **Identyfikator commita** - skrót jednoznacznie wskazujący wersję kodu; po angielsku SHA - **Kolejka** - komenda `mr-queue`, która prowadzi merge requesty do merge jeden po drugim - **Strażnik komend** - hook pluginu, który pyta albo odmawia przed poleceniem merge i zatwierdzenia - **Branch docelowy** - branch, do którego trafia merge request Pełny opis kolejki znajdziesz we wpisie [Jak działa /monolynx:mr-queue](https://monolynx.com/blog/jak-dziala-monolynx-mr-queue). Kiedy ticket dostaje status Gotowe, wyjaśnia wpis [Statusy ticketu w Monolynx](https://monolynx.com/blog/statusy-ticketu-w-monolynx). Cały sprint od planu do zamknięcia prowadzi [Sprint z Monolynx krok po kroku](https://monolynx.com/blog/sprint-z-monolynx-krok-po-kroku). **Wezwanie do działania** Chcesz zobaczyć przebieg pracy agentów nad ticketem, zanim zatwierdzisz zmianę? [Zobacz moduł Pipelines w Monolynx](https://monolynx.com/features/pipelines)