Workspace Indexing: jak Copilot szuka w Twoim kodzie | Kurs GitHub Copilot

Czego się nauczysz

Czym naprawdę jest workspace indexing i czym nie jest
Jak działają remote, local i basic index
Dlaczego indexing pomaga znaleźć relewantny kod, ale nie zastępuje świadomego kontekstu

Copilot nie czyta repo jak książki od deski do deski

Jedno z najbardziej uporczywych nieporozumień wygląda tak: “przecież Copilot ma mój projekt, więc powinien wszystko o nim wiedzieć”.

Nie. Nie w ten sposób.

Copilot nie wrzuca całego repo do modelu i nie analizuje go linearnie. Zamiast tego korzysta z workspace context i workspace indexingu, żeby znaleźć najbardziej relewantne fragmenty kodu dla Twojego pytania.

To jest ogromna różnica, bo zmienia oczekiwania wobec produktu.

Workspace context to warstwa wyszukiwania

Dokumentacja How Copilot understands your workspace opisuje to bardzo jasno: VS Code używa inteligentnych strategii wyszukiwania, żeby znaleźć kod najbardziej związany z Twoim promptem.

W praktyce system korzysta z kilku źródeł naraz:

indexable files w workspace
struktury katalogów i nazw plików
symboli i definicji z language intelligence
aktualnego zaznaczenia albo widocznego tekstu w aktywnym edytorze

To ważne, bo Copilot szuka podobnie do tego, jak dobry programista sam eksploruje repo: po nazwach, strukturze, symbolach, referencjach i aktualnym punkcie pracy.

Search strategy jest wielotorowa

VS Code nie polega na jednej metodzie.

Docs mówią wprost, że uruchamiane są różne strategie równolegle i system bierze to, co da najlepszy wynik najszybciej.

Wśród tych strategii są między innymi:

GitHub code search
local semantic search
zwykłe text search po plikach i nazwach
language intelligence przez IntelliSense i LSP

To praktycznie oznacza tyle: pytanie jest interpretowane, potem system szuka kodu różnymi drogami, a na końcu do promptu trafia tylko najbardziej relewantny wycinek.

Czyli znowu: indexing jest mechanizmem znajdowania, nie pełnym przekazaniem całego repo do modelu.

Mały projekt i duży projekt to nie ten sam przypadek

Dokumentacja zaznacza, że dla małych projektów cały workspace może czasem wejść bezpośrednio do kontekstu. Dla większych repo działa już selekcja najistotniejszych fragmentów.

To dobry powód, żeby nie wyciągać zbyt mocnych wniosków z pracy na małym playgroundzie.

W małym repo możesz mieć wrażenie, że Copilot “wie wszystko”. W większym projekcie nagle okaże się, że jakość odpowiedzi dużo bardziej zależy od dołączonego kontekstu, jakości nazw i sposobu sformułowania pytania.

Trzy tryby indeksu: remote, local, basic

To najważniejsza część tej lekcji.

Remote index

Remote index jest budowany i utrzymywany zdalnie. Dla GitHuba działa od razu po zalogowaniu i otwarciu repo, a dla Azure DevOps również jest wspierany przez zdalny indeks.

To jest najlepsza opcja przy większych codebase’ach, bo daje szybkie i szerokie wyniki wyszukiwania.

Ale ma ważne ograniczenie: zdalny indeks jest oparty na committed state repozytorium.

Czyli lokalne, niecommitowane zmiany nie siedzą w samym remote indexie.

Hybryda przy lokalnych zmianach

I tutaj docs dodają ważny szczegół: gdy masz lokalne, niecommitowane zmiany, VS Code używa podejścia hybrydowego.

Łączy:

remote index z commitniętego stanu
lokalne śledzenie plików zmienionych od czasu indeksu
bieżącą zawartość edytora dla real-time context

To bardzo ważne, bo tłumaczy, dlaczego Copilot nadal potrafi pracować sensownie na niezatwierdzonych zmianach, mimo że zdalny indeks sam w sobie ich nie obejmuje.

Local index

Jeśli nie możesz użyć remote indexu, VS Code może zbudować advanced semantic index lokalnie.

Docs podają konkretne progi:

mniej niż 750 indexable files: advanced local index buduje się automatycznie
od 750 do 2500: można go uruchomić ręcznie przez Build local workspace index
powyżej 2500: wchodzi basic index

To ważne z punktu widzenia praktyki. Jeśli pracujesz poza GitHubem albo Azure DevOps, nadal możesz mieć dobre wyniki, ale trzeba rozumieć ograniczenia lokalnego indeksu.

Basic index

Basic index to fallback dla większych projektów bez remote indexu.

Działa lokalnie i używa prostszych algorytmów. Dla wielu pytań wciąż jest wystarczający, ale jeśli odpowiedzi robią się zbyt słabe przy pytaniach o szeroki kod, docs sugerują rozważyć remote index.

Czyli basic index to nie “zepsuty tryb”. To po prostu mniej zaawansowana strategia dla trudniejszych warunków.

Co w ogóle wchodzi do indeksu

To też warto zrozumieć, bo tu rodzi się sporo błędnych oczekiwań.

Docs mówią, że indeks obejmuje istotne pliki tekstowe w projekcie, ale pomija między innymi:

pliki z .gitignore
pliki wykluczone przez files.exclude
część typowych nieistotnych formatów typu .tmp albo .out
pliki binarne jak obrazy czy PDF-y

Jest jednak ważny wyjątek: jeśli masz otwarty plik ignorowany albo zaznaczenie w takim pliku, .gitignore może zostać ominięte dla bieżącego kontekstu.

To kolejny przykład, że aktywna praca w edytorze i explicit context potrafią nadpisać domyślną logikę indeksowania.

Ask i Agent korzystają z workspace context bardziej podobnie, niż wiele osób myśli

W aktualnych docsach to też jest wyraźne.

Ask mode nie jest już tylko pasywnym FAQ. Ask też automatycznie przeszukuje codebase odpowiednimi narzędziami i zbiera relewantne fragmenty. Agent robi to samo, tylko może pójść dalej i uruchamiać kolejne, bardziej celowane wyszukiwania w trakcie pracy.

Praktyczny wniosek:

Ask potrafi sam szukać w repo
Agent potrafi szukać i iterować jeszcze głębiej

To dlatego w wielu przypadkach nie musisz dopisywać #codebase ręcznie, choć czasem nadal warto to zrobić jako jawny sygnał.

Czy trzeba używać `#codebase`?

Dokumentacja daje tu bardzo dobrą odpowiedź: w większości przypadków nie.

Ask i Agent i tak automatycznie przeszukują workspace. #codebase jest bardziej wymuszeniem albo wzmocnieniem intencji niż obowiązkowym rytuałem.

To ważne, bo część osób robi z #codebase magiczne zaklęcie do każdego promptu. To niepotrzebne.

Lepszy filtr jest taki:

jeśli pytanie jest już jednoznacznie repo-centric, często nie trzeba nic dopisywać
jeśli chcesz jawnie wymusić szersze przeszukanie albo temat jest niejednoznaczny, #codebase ma sens

Największy błąd: mylić indexing z pełnym zrozumieniem repo

Indexing pomaga bardzo, ale nie rozwiązuje wszystkiego.

Jeśli pytanie jest mgliste, nazwy w kodzie są słabe albo prosisz o coś w stylu “znajdź wszystkie bugi w projekcie”, nawet dobry indeks nie zamieni tego w sensowną analizę.

Docs mówią to całkiem otwarcie: nie oczekuj kompletnego code audit tylko dlatego, że model potrafi przeszukać workspace.

To nadal system ograniczony przez:

jakość pytania
relewantność znalezionych fragmentów
limit context window

Ćwiczenie praktyczne

W swoim repo zrób trzy krótkie testy:

Zadaj szerokie pytanie typu: gdzie w projekcie obsługiwana jest autoryzacja?
Powtórz je z #codebase.
Sprawdź w status barze, jaki typ indeksu jest używany w Twoim workspace.

Na końcu oceń:

czy #codebase realnie zmieniło trafność odpowiedzi
czy model odwołuje się do realnych plików i symboli
czy rozumiesz już, kiedy problem wynika z braku indeksu, a kiedy z braku konkretu w pytaniu

Kluczowe wnioski

Workspace indexing służy do wyszukiwania relewantnego kodu, a nie do wrzucania całego repo do promptu.
VS Code korzysta równolegle z kilku strategii wyszukiwania, w tym code search, semantic search i language intelligence.
Remote, local i basic index mają różne możliwości i ograniczenia.
Remote index opiera się na committed state, ale VS Code łączy go z lokalnymi zmianami przez podejście hybrydowe.
#codebase bywa przydatny, ale nie jest obowiązkowy przy każdym pytaniu o repo.

Co dalej

Skoro wiesz już, jak działa automatyczne wyszukiwanie kontekstu, trzeba jeszcze oddzielić to, co VS Code dołącza sam z bieżącej pracy, od tego, co musisz dopiąć ręcznie.