GitHub przebudowuje architekturę przechowywania stojącą za usługą Git, aby obsłużyć model wytwarzania oprogramowania, w którym ludzie, systemy CI i agenty programowe mogą jednocześnie zapisywać dane w tych samych repozytoriach. Najnowszy wpis inżynieryjny firmy opisuje rozwiązanie, które przenosi trwałe dane repozytoriów w kierunku Azure Blob Storage, pozwala niezależnie skalować wydajność odczytów i ogranicza koordynację zapisów z poziomu całego repozytorium do poszczególnych referencji Git, które rzeczywiście wymagają uporządkowania.

Redakcyjna wizualizacja infrastruktury chmurowej oddzielającej odczyty repozytoriów od koordynacji zapisów Git.

To istotna zmiana infrastrukturalna, ale nie nowa funkcja, którą użytkownicy mogą po prostu włączyć. GitHub przedstawia te prace jako trwającą przebudowę prowadzoną przy działającej platformie. Według wpisu uzupełniającego firma przeniosła już kopie 99,99999% swoich repozytoriów do Azure, natomiast pozostałe przypadki brzegowe wymagają zmian w protokole zapisu. Wpisy opisują również wewnętrzne wzrosty przepustowości, ale nie publikują wystarczających szczegółów benchmarków, by traktować te liczby jako gwarancję przepustowości dla konkretnego przedsiębiorstwa czy floty agentów.

Dla zespołów platformowych bezpośrednie pytanie nie brzmi więc, czy repozytorium nagle stanie się 35 razy szybsze. Chodzi o to, jak projektować zautomatyzowane obciążenia programistyczne, aby nie zależały od tego, że każdy punkt kontrolny stanie się pushem, każda gałąź będzie współdzielić tę samą gorącą referencję, a każde zadanie CI będzie wielokrotnie klonować te same dane.

Co zmienia GitHub

Obecna architektura GitHuba, opisywana w serii inżynieryjnej firmy jako Spokes, przechowuje kompletne kopie repozytoriów na węzłach pamięci masowej i wykorzystuje koordynację zapisów opartą na kworum. Takie rozwiązanie zapewnia trwałość i spójność, ale łączy ze sobą kilka różnych zadań. Ten sam ogólny zestaw replik uczestniczy w zapewnianiu trwałości zapisów, obsługuje odczyty Git i wspiera prace utrzymaniowe, takie jak kompaktowanie oraz garbage collection.

To powiązanie staje się kosztowniejsze, gdy aktywność rośnie jednocześnie w kilku obszarach. Agent może tworzyć commity lub punkty kontrolne znacznie częściej niż człowiek. Duża flota agentów może tworzyć wiele gałęzi w jednym repozytorium. CI może rozdzielać odczyty z końca gałęzi po każdej zmianie. Kolejki merge’ów i automatyzacja wydań mogą następnie skupiać zapisy z powrotem na niewielkiej liczbie referencji.

Przebudowa GitHuba opiera się na dwóch powiązanych zasadach: koordynować tylko to, co rzeczywiście musi być koordynowane, oraz oddzielić trwałe przechowywanie od mocy obliczeniowej obsługującej żądania.

Pierwsza zasada dotyczy aktualizacji referencji podczas git push. Repozytorium Git zawiera niezmienne obiekty identyfikowane na podstawie treści oraz zmienne referencje, takie jak wskaźniki gałęzi i tagów. Aktualizacja referencji to część wymagająca uporządkowania: gdy klient zobaczy nowszą wartość referencji, kolejne odczyty nie powinny zwracać starszej wartości. Wiele innych operacji związanych z pushem, w tym przechowywanie obiektów, weryfikacja łączności, skanowanie sekretów i prace utrzymaniowe, można wykonywać równolegle albo przenieść poza wąską ścieżkę potwierdzenia.

Druga zasada zmienia sposób wykorzystywania kopii repozytoriów. Zamiast wymagać, by każdy worker obsługujący odczyty był również pełną trwałą repliką, GitHub opisuje model, w którym Azure Blob Storage staje się trwałym źródłem danych, a lekkie workery zapewniają buforowaną wydajność odczytów. Awaria workera przypomina utratę pamięci podręcznej lub mocy obliczeniowej, a nie utratę autorytatywnej kopii repozytorium. Nowe workery można dodawać podczas obciążeniowych skoków odczytów bez automatycznego zwiększania takiego samego kosztu przy każdym zapisie.

Architektura jest wdrażana stopniowo. Wpisy GitHuba opisują wirtualne repliki, workery korzystające z magazynu, serializację na poziomie referencji oraz utrzymanie w tle jako elementy migracji, a nie jednego zakończonego uruchomienia produktu.

Dlaczego obciążenia agentów ujawniły stare wąskie gardło

Zmiana bywa przedstawiana jako historia o „infrastrukturze AI”, ale źródło presji jest bardziej konkretne: tworzenie oprogramowania przy wysokiej współbieżności generuje inny rozkład operacji Git.

Ludzki programista może pracować przez kilka minut, zanim utworzy commit i wypchnie gałąź. Zautomatyzowany agent może zapisywać stan po wykonaniu pojedynczych zadań, uruchamiać testy, poprawiać pliki i powtarzać cały cykl. Tysiące agentów pracujących w jednym repozytorium może więc generować wiele równoczesnych zapisów, odczytów, prób scalania i aktualizacji statusu. Nie muszą być autonomiczne w szerokim znaczeniu, żeby miało to znaczenie. Skryptowa pętla kodowania połączona z modelem może wywołać taką samą presję na infrastrukturę, jeśli często wykonuje operacje na repozytorium.

GitHub podaje, że miesięczna aktywność Git wzrosła z 218,2 mld zdarzeń we wrześniu 2025 r. do 473,3 mld w sierpniu 2026 r. Firma informuje również o 7,38 mld commitów we wrześniu, 3,35 mld wypchnięć miesięcznie, niemal czterokrotnym wzroście liczby scalonych pull requestów oraz 3,26 mld uruchomień GitHub Actions w tym miesiącu. Liczby te opisują całkowitą aktywność platformy, a nie precyzyjny pomiar aktywności wywołanej wyłącznie przez agentów. Obejmują zwykłą pracę programistów, CI, automatyzację i wzrost liczby klientów. Pokazują jednak, dlaczego ponownie analizowana jest usługa repozytoriów zaprojektowana z myślą o mniejszej współbieżności.

Presja nie ogranicza się do zapisów. Repozytorium z dużą liczbą agentów lub procesów CI może po każdej aktualizacji gałęzi otrzymywać nagły napływ operacji pobierania, klonowania, zapytań o status i działań związanych z pull requestami. Jeśli przepustowość odczytu jest powiązana z tymi samymi pełnymi replikami, które uczestniczą w kworum zapisu, skalowanie odczytów może zwiększać koszt zapisów. Jeżeli repozytorium potrzebuje wielu dodatkowych replik, aby obsłużyć skok ruchu odczytowego, repliki te mogą zwiększać obciążenie koordynacją i utrzymaniem, nawet gdy sposób wykonywania zapisów się nie zmienił.

Celem przebudowy jest przerwanie tej pętli sprzężenia zwrotnego. Pracowników obsługujących odczyty można skalować zgodnie z zapotrzebowaniem, podczas gdy trwały stan repozytorium i uporządkowane aktualizacje referencji pozostają w osobnej warstwie. Nie sprawia to, że każda operacja Git staje się tania ani nie usuwa potrzeby zachowania spójności. Zmienia natomiast miejsce, w którym system zużywa budżet koordynacji.

Koordynacja na poziomie referencji to najważniejszy szczegół projektu

Najbardziej przydatnym szczegółem technicznym w najnowszym wyjaśnieniu GitHuba jest przejście od koordynacji obejmującej całe repozytorium do serializacji na poziomie poszczególnych referencji.

Przy blokadzie całego repozytorium lub równoważnej serializowanej ścieżce zapisu dwa wypchnięcia mogą sobie przeszkadzać, nawet jeśli aktualizują niezależne gałęzie. Wypchnięcie do feature/alice czeka za wypchnięciem do feature/bob, ponieważ repozytorium jest jednostką, na poziomie której system koordynuje aktualizację. Takie podejście ułatwia rozumowanie o systemie, ale jego przepustowość ograniczają najwolniejsza replika, wymagane przez kworum podróże w obie strony przez sieć oraz liczba zapisów, które mogą przejść przez wspólną kolejkę.

Serializacja per referencja zawęża obszar konfliktu. Aktualizacje tej samej gałęzi nadal trzeba uporządkować. Dwóch wymuszonych wypchnięć do tej samej referencji nie można traktować jako niezależnych, ponieważ ich stan końcowy zależy od kolejności i reguł. Aktualizacje różnych gałęzi mogą jednak przebiegać równolegle, o ile nie naruszają reguł spójności Git ani zasad zarządzania repozytorium.

GitHub twierdzi, że wewnętrzne testy nowego podejścia wykazały około 3–4 razy większą przepustowość zapisów do różnych referencji przy niższych opóźnieniach w opisanym przez firmę scenariuszu migracji. To bardziej szczegółowy wynik niż szersza wartość „do 35 razy większa przepustowość zapisów”, przywołana we wcześniejszym wpisie o architekturze, ale oba rezultaty pozostają pomiarami wewnętrznymi. Opublikowane materiały nie podają wystarczających informacji o rozmiarze repozytorium, współbieżności, mieszance obciążeń, sprzęcie bazowym, percentylach opóźnień ani wdrożeniu produkcyjnym, by zewnętrzny zespół mógł bezpośrednio przełożyć te liczby na wzór doboru zasobów.

To rozróżnienie ma znaczenie przy planowaniu inżynieryjnym. Repozytorium z tysiącami niezależnych, krótkotrwałych gałęzi może skorzystać na ograniczeniu rywalizacji. Obciążenie, w którym tysiące pracowników aktualizują jedną wspólną gałąź, jeden tag wydania lub jedną kolejkę scalania, nadal ma gorącą referencję. Koordynacja per referencja ogranicza konflikty między niezależnymi operacjami, ale nie sprawia, że pojedynczy uporządkowany strumień staje się nieskończenie równoległy.

Trwałe przechowywanie i skalowanie odczytów

Model obiektów Git adresowanych przez zawartość stwarza możliwość oddzielenia niezmiennych danych od zmiennego stanu referencji. Gdy obiekt zostanie zapisany i zweryfikowany, jego tożsamość wynika z zawartości. Zmienna część repozytorium jest stosunkowo niewielka: referencje się przesuwają, a system musi zagwarantować, że klienci zobaczą kolejność zgodną z tymi zmianami.

GitHub opisuje Azure Blob Storage jako trwałą warstwę dla danych repozytoriów i wprowadza wirtualną replikę zapisu, która przesyła przychodzące zapisy do magazynu obiektowego. Zapis nie jest potwierdzany, dopóki dane nie zostaną utrwalone w tej warstwie. Lekkie repliki odczytu mogą następnie ogrzewać pamięci podręczne z magazynu obiektowego i obsługiwać ruch odczytowy, nie dołączając do kworum zapisu w taki sam sposób jak pełna trwała replika.

Korzyść nie sprowadza się po prostu do tego, że „magazyn w chmurze jest szybszy”. Magazyn obiektowy i zasoby obliczeniowe obsługujące żądania mogą być dostarczane oraz odtwarzane niezależnie. Worker odczytu można dodać, gdy zapotrzebowanie generują wydanie, rozproszony fan-out CI albo flota agentów. Uszkodzonego workera odczytu można zastąpić i ponownie wypełnić jego pamięć podręczną. Konserwację magazynu mogą wykonywać oddzielne workery, zamiast bezpośrednio konkurować o zasoby z bieżącymi pobraniami i wysyłaniem zmian na tych samych maszynach.

Są jednak kompromisy. Nowo utworzony worker odczytu może zaczynać z pustą pamięcią podręczną. Uzgadnianie ze stanem trwałym musi działać poprawnie przy równoczesnych aktualizacjach. Niektóre odczyty mogą wymagać świeższego stanu referencji niż inne, więc sama synchronizacja w tle może nie wystarczyć. GitHub twierdzi, że kolejne kroki przeniosą większą część uzgadniania do ścieżki obsługi żądania, aby replika mogła pobrać stan referencji oraz dane, które zmieniły się od czasu jej ostatniego nadrobienia zaległości.

Oznacza to, że architektura przesuwa problem, zamiast go usuwać. Zamiast wymagać udziału każdej pełnej repliki w każdej operacji, system musi zarządzać świeżością pamięci podręcznych, trwałym stanem referencji, odtwarzaniem, kompaktowaniem oraz granicami między obsługą żądań a konserwacją. Projekt jest atrakcyjny, ponieważ te odpowiedzialności można skalować niezależnie, ale niezależność wymaga również jawnych reguł spójności i dobrej obserwowalności.

Liczbę „35 razy” trzeba czytać ostrożnie

We wcześniejszym wpisie GitHub podał, że przebudowana architektura zapewniła w wewnętrznych testach porównawczych nawet 35 razy większą przepustowość zapisów. To użyteczny sygnał wskazujący kierunek prac, ale nie obietnica, że repozytorium klienta odnotuje trzydziestopięciokrotną poprawę.

Publiczny wpis nie opisuje konfiguracji testu na tyle szczegółowo, by ustalić, w jakich warunkach ta liczba ma zastosowanie. Nie podano rozmiaru repozytorium, liczby referencji, poziomu współbieżności, rozkładu zapisów, proporcji odczytów do zapisów, systemu bazowego, rozkładu opóźnień, warunków awarii ani informacji, czy test odtwarza ruch produkcyjny. Nie wskazano też, że każde repozytorium zostało przeniesione na nową ścieżkę ani że pomiar oznacza ogólnie dostępny limit usługi.

Ta sama ostrożność dotyczy statystyk aktywności firmy. Szybki wzrost liczby wysyłanych zmian i commitów pokazuje presję na platformę, ale nie dowodzi, że za cały wzrost odpowiadają agenci. Nie pokazuje również, że większa liczba operacji Git przekłada się proporcjonalnie na bardziej użyteczne oprogramowanie. Duża liczba automatycznych punktów kontrolnych może oznaczać produktywną pracę równoległą, zbędne zmiany, powtarzane ponowienia albo połączenie wszystkich tych zjawisk.

Wniosek operacyjny jest prosty: nie należy wymiarować platformy agentów, mnożąc obecną współbieżność przez nagłośniony wynik testu. Trzeba potraktować benchmark jako dowód na to, że GitHub usuwa strukturalne wąskie gardło, a następnie mierzyć własne obciążenie na podstawie opóźnienia wysyłania zmian, odrzuconych lub ponowionych wysyłek, limitów szybkości API, czasu oczekiwania w kolejce, fan-outu CI oraz czasu potrzebnego na scalenie zmian.

Co to oznacza teraz dla zespołów inżynieryjnych

Użytkownicy nie muszą przepisywać zwykłych przepływów pracy z Gitem z powodu tego ogłoszenia. Deklarowanym celem GitHub jest zachowanie rozgałęziania, przeglądów, scalania, historii, ochrony gałęzi, wymaganych akceptacji, dzienników audytowych, widoczności repozytoriów i innych mechanizmów kontroli przy jednoczesnej zmianie backendu, który je obsługuje.

Zespoły uruchamiające automatyzację o dużym wolumenie powinny mimo to przeanalizować sposób projektowania swoich obciążeń. Taki przegląd jest przydatny nawet wtedy, gdy migracja GitHub ostatecznie usunie znaczną część obecnej presji, ponieważ ogranicza marnotrawioną pracę i ułatwia odzyskiwanie po awariach.

Ogranicz niepotrzębną częstotliwość wysyłania zmian

Agent nie musi wysyłać każdego pośredniego punktu kontrolnego do współdzielonej gałęzi zdalnej. W miarę możliwości przechowuj lokalne punkty kontrolne podczas zadania, a następnie wysyłaj znaczące etapy albo ograniczone pakiety zmian. Właściwa częstotliwość zależy od wymagań dotyczących odtwarzania i kosztu utraty lokalnej pracy, ale polityka, która zamienia każde wywołanie narzędzia w zdalną wysyłkę, generuje możliwy do uniknięcia ruch zapisów.

W przypadku długotrwałych zadań należy przechowywać punkty kontrolne lokalnie lub zewnętrznie, niezależnie od aktualizacji gałęzi, jeśli zespół potrzebuje precyzyjnego odzyskiwania stanu. Dzięki temu trwały mechanizm odtwarzania pozostaje oddzielony od referencji Git, z której muszą korzystać inni programiści i systemy.

Unikaj tworzenia jednej przeciążonej referencji

Tysiące niezależnych gałęzi mogą nadal zbiegać się w jednej chronionej gałęzi, tagu wydania lub kolejce scalania. Zidentyfikuj referencje otrzymujące najwięcej zapisów oraz przepływy pracy, które są na nich serializowane. Repozytorium może zapewniać doskonałą równoległość pracy na gałęziach, a mimo to jedna współdzielona referencja może pozostać faktycznym wąskim gardłem.

Kolejek scalania i kontrolowanego grupowania zmian używaj tam, gdzie poprawiają kolejność operacji, ale monitoruj wiek kolejki oraz zachowanie przy ponawianiu prób. Kolejka, która wielokrotnie przelicza lub ponownie waliduje ten sam duży zestaw zmian, może przenieść obciążenie z zapisów Git na CI, interfejsy API pull requestów albo infrastrukturę testową.

Zaplanuj odczyty CI

Automatyzacja intensywnie odczytująca dane może przeciążyć repozytorium nawet przy umiarkowanej liczbie wypchnięć. Tam, gdzie pozwala na to dany przepływ pracy, preferuj płytkie lub częściowe klonowanie, ponownie wykorzystuj pamięci podręczne repozytoriów, unikaj wielokrotnego wykonywania pełnych klonów dla identycznych danych wejściowych i rozpraszaj uruchamianie zadań, gdy wydanie lub aktualizacja gałęzi wyzwala ich wiele naraz.

Wskazówki GitHuba dotyczące repozytoriów zalecają przestrzeganie limitów operacyjnych, takich jak rozmiar wypchnięcia wynoszący 2 GB, rekomendowany pułap 15 operacji odczytu Git na sekundę dla repozytorium oraz sześć wypchnięć na minutę na repozytorium jako zalecane tempo wysyłania zmian. Nie zastępują one planowania przepustowości i nie opisują każdego interfejsu API ani każdej konfiguracji firmowej, przypominają jednak, że repozytorium jest współdzieloną granicą usługi. Zautomatyzowani klienci powinni traktować opublikowane limity jako dane wejściowe do projektu, a nie poznawać je dopiero przez ograniczanie ruchu.

Nie dopuść, by ponawianie prób zwielokrotniło skutki incydentu

Błąd wypchnięcia lub pobrania może sprawić, że duża flota automatyzacji ponowi próbę w tej samej chwili. Stosuj wykładnicze opóźnienia z losowym rozproszeniem, ograniczaj liczbę prób, odróżniaj przejściowe błędy transportu od odrzuceń wynikających z zasad i zapisuj pierwotny identyfikator operacji albo zakres commitów, aby ponowienie nie tworzyło zduplikowanej pracy.

Polityka ponawiania prób powinna uwzględniać również ręczną weryfikację. Jeśli przepływ pracy czeka na aktualizację chronionej gałęzi, bezrefleksyjne ponawianie może przeciążyć tę samą referencję, podczas gdy operator prowadzi dochodzenie. Wycofanie kolejnych prób w czasie to mechanizm niezawodności, a nie tylko optymalizacja wydajności po stronie klienta.

Zachowaj nadzór przy zwiększaniu automatyzacji

GitHub twierdzi, że nowa infrastruktura ma zachować ochronę gałęzi, wymagane recenzje, dzienniki audytowe oraz widoczność repozytoriów. Organizacje powinny sprawdzić, czy ich własne przepływy pracy agentów korzystają z tych mechanizmów w sposób jawny. Szybsza ścieżka zapisu nie zastępuje reguł zatwierdzania, skanowania sekretów, podpisanych commitów tam, gdzie są wymagane, ochrony środowisk ani kontroli wdrożeń.

Agentom należy przyznawać wyłącznie minimalne uprawnienia do repozytorium i środowiska potrzebne do wykonania zadania. Oddziel dostęp do generowania kodu od uprawnień do scalania, poświadczeń wdrożeniowych i danych produkcyjnych. Jeśli agent może tworzyć gałęzie, ale bez recenzji nie może aktualizować chronionej gałęzi domyślnej, usprawnienia skalowania platformy zwiększą przepustowość bez cichego usuwania punktu wymagającego ludzkiej decyzji.

Co pozostaje niewiadome

W publicznym opisie GitHuba wciąż brakuje odpowiedzi na kilka istotnych pytań.

Firma nie opublikowała pełnego harmonogramu wdrażania nowej architektury. Nie wyjaśniła, ile repozytoriów produkcyjnych obsługuje model odczytu wspierany przez pamięć masową, które obciążenia się do niego kwalifikują ani kiedy klienci mogą spodziewać się zauważalnych zmian limitów i opóźnień.

Twierdzenia dotyczące benchmarków również wymagają szerszego kontekstu. Zewnętrzni odbiorcy potrzebują definicji obciążeń, rozmiarów repozytoriów, poziomów współbieżności, opóźnień p50 i p99, informacji o zachowaniu w razie błędów oraz porównań z dotychczasową ścieżką. Bez tych szczegółów określenie „do” jest użytecznym sygnałem inżynieryjnym, ale nie stanowi gwarancji, na której można oprzeć planowanie.

Kolejnym obszarem wymagającym obserwacji jest spójność podczas rozgrzewania pamięci podręcznej. Pracownik odtwarzający stan z magazynu obiektowego nie może zwracać nieaktualnych wartości referencji w sposób naruszający oczekiwania Git. System musi także obsługiwać kompaktowanie, garbage collection, przerwane zapisy, opóźnienia między regionami oraz odzyskiwanie po częściowych awariach, nie przekształcając utrzymania w nowe wąskie gardło obsługi.

Na koniec związek między aktywnością agentów a raportowanym wzrostem platformy pozostaje częściowo niezmierzony. Statystyki GitHuba łączą pracę programistów, tradycyjną automatyzację, CI oraz przepływy agentowe. To wystarcza, by uzasadnić zmiany architektoniczne, ale nie pozwala stwierdzić, że każda organizacja zobaczy taki sam wzorzec współbieżności.

Praktyczny odczyt ogłoszenia

GitHub reaguje na rzeczywistą zmianę w sposobie tworzenia oprogramowania: więcej operacji na repozytoriach, więcej równoległych gałęzi, więcej zautomatyzowanych odczytów i większa presja na współdzielone punkty integracji. Odpowiedzią firmy jest ograniczenie zbędnej koordynacji, oddzielenie trwałego przechowywania od mocy obliczeniowej obsługującej żądania oraz — tam, gdzie to możliwe — uniezależnienie przepustowości odczytu od kworum zapisu.

Dla klientów najważniejsza w najbliższym czasie jest dyscyplina obciążenia. Nie pozwalaj, by pośredni stan agentów zamieniał się w zdalny ruch Git, identyfikuj gorące referencje, kontroluj rozgałęzienia CI, buforuj powtarzające się odczyty i stosuj łagodne ponowienia. Nadal egzekwuj granice przeglądu kodu i wdrażania, nawet gdy automatyzacja staje się bardziej zaawansowana.

Architektura może ostatecznie zapewnić GitHubowi znacznie większy zapas możliwości, ale opublikowane benchmarki nie zwalniają z pomiaru rzeczywistych obciążeń. Dla zespołu platformowego użyteczne pytanie nie brzmi, czy GitHub ogłosił duży mnożnik. Trzeba ustalić, która część pętli wytwarzania oprogramowania jest obecnie szeregowa, czy ta serializacja jest konieczna oraz co się stanie, gdy nadejdzie kolejny zryw zautomatyzowanej pracy.