{"schema_version":"1.0","service":"Publicasta","type":"article","id":881,"slug":"github_desktop_3_6_7_worktree_edge_cases","title":"GitHub Desktop 3.6.7 naprawia sytuacje brzegowe, które utrudniają pracę z worktree","excerpt":"GitHub Desktop 3.6.7 to konserwacyjne wydanie dla pracy z równoległymi checkoutami: utrzymuje widoczny bieżący worktree, bezpieczniej obsługuje referencje zaczynające się od myślnika, naprawia ścieżki Cygwina i awarię śledzenia postępu Git LFS.","language":"pl","default_language":"en","canonical_url":"https://publicasta.com/open_source_radar/github_desktop_3_6_7_worktree_edge_cases?lang=pl","image":{"url":"https://publicasta.com/storage/projects/10/pages/881/2026/10/b7302cd1-7397-4d9d-94fc-ebfd6382ba07.webp","alt":"Fotografia redakcyjna laptopa i uporządkowanych folderów projektów przedstawiających wiele powiązanych worktree Git."},"publisher":{"id":10,"slug":"open_source_radar","name":"Open Source Radar","url":"https://publicasta.com/open_source_radar"},"author":{"name":"Anton R"},"published_at":"2026-10-14T13:38:48+00:00","updated_at":"2026-10-14T13:38:48+00:00","content_markdown":"GitHub Desktop 3.6.7 to niewielkie wydanie wymierzone w bardzo praktyczny problem: sytuacje, w których graficzny klient Gita musi pokazać więcej niż jeden checkout tego samego repozytorium. Aktualizacja dodaje ustawienie utrzymujące bieżący worktree na ekranie, poprawia obsługę nazw zaczynających się od myślnika, naprawia problem ze ścieżką używaną przez Open in Cygwin i usuwa awarię śledzenia postępu Git LFS.\n\n ![Fotografia redakcyjna laptopa i uporządkowanych folderów projektów przedstawiających wiele powiązanych worktree Git.](https://publicasta.com/storage/projects/10/pages/881/2026/10/b7302cd1-7397-4d9d-94fc-ebfd6382ba07.webp)\n\n Nie zmienia to podstawowego charakteru GitHub Desktop. To nadal desktopowy klient dla Gita, a nie zamiennik modelu repozytorium używanego przez Git. Wartość tej aktualizacji jest węższa, ale konkretna: jeśli codzienna praca obejmuje równoległe gałęzie, połączone worktree, duże pliki albo repozytoria o nietypowych nazwach, wersja 3.6.7 usuwa kilka sposobów, na które interfejs mógł przeszkadzać.\n\n To wydanie zasługuje na testy u opiekunów repozytoriów i programistów regularnie korzystających z worktree. Nie jest natomiast powodem, by bez sprawdzenia zmieniać stabilny proces zespołu, ani nie czyni z GitHub Desktop kompletnego środowiska do zarządzania worktree. Własny changelog projektu i tag wydania opisują skoncentrowaną aktualizację utrzymaniową, a dokumentacja Gita wyjaśnia, dlaczego część pozostałych ograniczeń ma charakter strukturalny, a nie wyłącznie interfejsowy.\n\n ## Co zmieniło się w wersji 3.6.7\n\n Oficjalny [tag wydania 3.6.7](https://github.com/desktop/desktop/releases/tag/release-3.6.7) wymienia cztery grupy zmian.\n\n Po pierwsze, nazwy gałęzi, zdalnych repozytoriów i tagów zaczynające się od myślnika są teraz poprawnie obsługiwane podczas pobierania, wysyłania, checkoutu, scalania, rebase oraz operacji na worktree. Nazwa taka jak -maintenance jest nietypowa, ale repozytoria Git rzeczywiście mogą zawierać nazwy kłopotliwe na granicy z wierszem poleceń. Aplikacja graficzna nadal musi bezpiecznie przekazać je do Gita i odróżnić argument od opcji. Ta poprawka jest ważna nie dlatego, że większość zespołów używa nazw z początkowym myślnikiem, lecz dlatego, że zamyka klasę niejednoznaczności wejścia w kilku przepływach naraz.\n\n Po drugie, wydanie naprawia integrację Open in Cygwin, gdy folder repozytorium zawiera spacje lub znaki interpunkcyjne. Taki błąd może pozostać niewidoczny w starannie nazwanym katalogu testowym, a natychmiast stać się uciążliwy w rzeczywistym katalogu domowym Windows. Repozytorium może być prawidłowe, powłoka może być zainstalowana, a integracja i tak nie zadziała, jeśli ścieżka zostanie źle złożona albo zacytowana. Informacja w nocie wydania jest krótka, ale zakres problemu jest jasny: ścieżki są danymi, a integracje desktopowe muszą zachowywać je dokładnie.\n\n Po trzecie, śledzenie postępu Git LFS nie powoduje już awarii po napotkaniu błędu odczytu pliku. Nie sprawia to, że problematyczny plik staje się odczytywalny, ani nie zwalnia z konieczności sprawdzenia pamięci masowej, uprawnień czy uszkodzonego checkoutu. Oznacza jednak, że błąd raportowania postępu nie powinien już zabierać ze sobą całej aplikacji. W repozytoriach przechowujących przez Git LFS pliki binarne, materiały projektowe, zbiory danych lub inne duże obiekty jest to najbardziej bezpośrednio związana z niezawodnością poprawka w tym wydaniu.\n\n Wreszcie nowe ustawienie wyglądu utrzymuje widoczny segment paska worktree bieżącego checkoutu dzięki opcji Always show worktree list. Wcześniejszy changelog wersji beta opisuje zamierzone zachowanie: kontrolka bieżącego worktree pozostaje obecna, zamiast znikać po zwinięciu reszty listy. Różnica brzmi drobno, dopóki repozytorium nie ma kilku połączonych checkoutów i użytkownik nie musi przed zatwierdzeniem zmian upewnić się, który z nich jest aktywny.\n\n Wydanie zawiera także niewielkie poprawki typowe dla aktualizacji utrzymaniowej aplikacji desktopowej: lepszy kontrast ikon powodzenia i błędu w podsumowaniu kontroli oraz walidację ścieżek pakietów aplikacji macOS w oknie klonowania. Nie są to główne funkcje, ale pasują do ogólnego charakteru wydania. Wersja 3.6.7 ma sprawić, że warunki brzegowe będą czytelniejsze i mniej kruche.\n\n ## Dlaczego ustawienie worktree ma znaczenie\n\n Worktree Gita nie jest po prostu kolejnym klonem. [Dokumentacja git worktree](https://git-scm.com/docs/git-worktree) opisuje główne drzewo robocze oraz zero lub więcej połączonych worktree, które współdzielą większość danych repozytorium, ale utrzymują osobno taki stan jak HEAD i indeks. W praktyce jedno repozytorium może mieć jeden checkout na gałęzi funkcjonalnej, drugi na gałęzi wydaniowej, a trzeci na tymczasowej gałęzi dochodzeniowej, bez pobierania całej bazy obiektów trzy razy.\n\n Taki model jest szczególnie przydatny przy częstym przełączaniu kontekstu. Opiekun repozytorium może utrzymać czystą gałąź wydaniową podczas przeglądania pull requesta w innym katalogu. Programista może zostawić długi test lub lokalny serwer w jednym worktree i przejść do poprawki błędu w kolejnym. Narzędzia do automatyzacji kodowania również zwiększają widoczność worktree, bo często tworzą odizolowane checkouty dla równoległych zadań. Układ plików jest inny, ale ludzki problem pozostaje ten sam: kilka katalogów wygląda jak ten sam projekt, a pomyłka może skierować zmianę do niewłaściwego miejsca.\n\n Klient, który ukrywa bieżący worktree do chwili otwarcia menu, dodaje odrobinę niepewności do każdej czynności. Przy jednym checkoutcie ta niepewność nie jest szczególnie dotkliwa. Rośnie w kosztowny problem, gdy repozytorium ma podobne nazwy, gałęzie żyją krótko albo narzędzie tworzy katalogi o ogólnych nazwach, takich jak work, app czy checkout.\n\n Stałe wyświetlanie listy nie rozwiązuje samo przez się problemu identyfikacji. GitHub Desktop nadal musi pokazywać wystarczająco dużo informacji o ścieżce lub gałęzi, aby można było odróżnić worktree, a bieżący tracker spraw pokazuje, że pozostaje to aktywnym zagadnieniem użyteczności. Otwarta sprawa proponuje wyświetlanie pełnej ścieżki worktree po najechaniu kursorem, gdy kilka drzew ma tę samą nazwę katalogu bazowego. To dobre przypomnienie: utrzymanie listy na ekranie poprawia wykrywalność kontekstu, ale nie tworzy kompletnego systemu nazewnictwa.\n\n Najrozsądniej odczytywać tę zmianę skromnie. Utrudnia ona zapomnienie, w jakim kontekście pracujemy. Nie gwarantuje jednak, że wybrany katalog jest tym zamierzonym, i nie zastępuje sprawdzenia gałęzi oraz ścieżki przed nieodwracalną operacją.\n\n ## Wydanie nadal podlega ograniczeniom samego Gita\n\n Niektórych niespodzianek związanych z worktree nie da się w pełni naprawić po stronie klienta. Git celowo współdzieli referencje i obiekty między worktree, jednocześnie utrzymując stan właściwy dla każdego drzewa. Dokumentacja zaznacza, że HEAD i indeks są rozdzielone, ale wiele referencji pozostaje współdzielonych. Gałąź jest zwykle checkoutowana tylko w jednym worktree naraz, a Git odmówi części operacji, chyba że użytkownik jawnie wymusi ich wykonanie.\n\n To rozróżnienie wyjaśnia, dlaczego drugi checkout może być tani, a mimo to wymagać dyscypliny. Pobieranie może aktualizować współdzielone referencje śledzące zdalne repozytorium. Konfiguracja może być współdzielona, jeśli nie włączono konfiguracji właściwej dla worktree. Hooki, pliki generowane, cache kompilacji i pliki środowiskowe mogą zachowywać się tak, jakby wszystkie checkouty należały do jednego większego projektu, nawet gdy katalogi ze źródłami są osobne.\n\n Znaczenie mają także zasady sprzątania. Git zapisuje informacje administracyjne o połączonych drzewach w katalogu worktrees wewnątrz repozytorium. Jeśli ktoś usunie folder worktree w menedżerze plików, metadane mogą pozostać, dopóki nie zostaną wyczyszczone. Obsługiwana ścieżka to użycie git worktree remove dla czystego drzewa albo git worktree prune po upewnieniu się, że brakujące drzewo rzeczywiście zniknęło. Jeśli katalog został ręcznie przeniesiony, git worktree repair może ponownie połączyć metadane.\n\n GitHub Desktop może przedstawiać te stany czytelniej, ale nie może bezpiecznie ich zmienić. Użytkownik, który potraktuje widoczną listę worktree jak listę niezależnych klonów, nadal może błędnie założyć coś na temat współdzielonych gałęzi, konfiguracji lub przechowywania obiektów. Z wydania najlepiej korzystać razem z modelem Gita, a nie zamiast niego.\n\n ## Poprawka nazw zaczynających się od myślnika dotyczy parsowania, nie stylu\n\n Początkowe myślniki łatwo zbyć jako konwencję nazewniczą, której nikt nie powinien stosować. Taki pogląd pomija lekcję inżynieryjną stojącą za poprawką. Wiele programów wiersza poleceń używa myślnika do oznaczania opcji. Kiedy prawidłowa nazwa gałęzi, zdalnego repozytorium, taga lub ścieżki również zaczyna się od myślnika, każda warstwa budująca polecenie musi zachować rozróżnienie między wartością a flagą.\n\n Klient może rozwiązać ten problem na kilka sposobów: przez staranne przekazywanie tablic argumentów, jawne znaczniki końca opcji tam, gdzie są obsługiwane, walidację albo połączenie tych technik. Dla użytkownika najważniejszy jest efekt: zwykłe operacje nie powinny interpretować nazwy repozytorium jako opcji polecenia.\n\n Warto zwrócić uwagę na szerokość noty dotyczącej wersji 3.6.7. Poprawka nie ogranicza się do checkoutu. Obejmuje pobieranie, wysyłanie, scalanie, rebase i działania na worktree, co sugeruje, że problematyczna wartość może przechodzić przez wiele ścieżek wywołań. Repozytorium może wyglądać normalnie, dopóki nie pojawi się zdalne repozytorium albo tag o podobnym kształcie nazwy. Naprawienie całej rodziny operacji jest cenniejsze niż poprawienie jednego widocznego elementu menu.\n\n Opiekunowie repozytoriów nadal powinni traktować nietypowe nazwy referencji jako test zgodności. Jeśli automatyzacja projektu, skrypty wydaniowe, hooki hostingu albo dokumentacja zakładają, że każda nazwa gałęzi jest konwencjonalnym słowem rozdzielonym ukośnikami, klient desktopowy jest tylko jednym elementem systemu. Wersja 3.6.7 ogranicza jedno ryzyko po stronie klienta, ale nie sprawia, że każda integracja zewnętrzna staje się odporna.\n\n Niewielka macierz testowa wystarczy, aby sprawdzić zachowanie bez zamieniania testu w eksperyment na produkcji:\n\n - Utwórz tymczasowe repozytorium i gałąź z początkowym myślnikiem.\n- Lokalnie wykonaj fetch, checkout, merge i rebase, zanim zaangażujesz współdzielone zdalne repozytorium.\n- Wypróbuj zdalne repozytorium albo tag o takim samym kształcie tylko wtedy, gdy pozwala na to polityka repozytorium.\n- Potwierdź, że interfejs wiersza poleceń i interfejs webowy używane przez zespół tak samo rozumieją nazwę referencji.\n- Po teście poprawnie usuń testowe referencje.\n\n Nie chodzi o rekomendowanie nazw zaczynających się od myślnika. Chodzi o sprawdzenie, czy istniejące repozytorium z kłopotliwymi nazwami nadal działa.\n\n ## Git LFS: poprawka awarii nie zastępuje diagnozy magazynu\n\n Git LFS zmienia zakres możliwych awarii repozytorium. Git przechowuje w zwykłej historii pliki wskaźnikowe, podczas gdy duża zawartość jest zarządzana przez serwer LFS i pobierana w razie potrzeby. Wskaźnik postępu znajduje się więc pomiędzy interfejsem użytkownika, lokalnym systemem plików, procesem Gita i transferem LFS. Błąd odczytu może wynikać z uprawnień, znikającego pliku, działania oprogramowania antywirusowego, katalogu zamontowanego przez sieć, pełnego dysku albo problemu z samym transferem.\n\n Zmiana w wersji 3.6.7 dotyczy reakcji klienta na jeden z takich błędów: śledzenie postępu nie powinno doprowadzać do awarii aplikacji. To przydatne, bo awaria niszczy kontekst. Użytkownik może stracić widoczny stan operacji i musi ustalić, czy transfer się zakończył, nie powiódł, czy pozostawił częściowy plik. Działający klient może pokazać błąd i pozwolić na sprawdzenie repozytorium.\n\n Błędem byłoby opisywanie tego jako gwarancji integralności danych LFS. To poprawa odporności ścieżki raportowania. Po aktualizacji zespoły nadal powinny zweryfikować operacje na dużych plikach w repozytorium testowym albo w niekrytycznym checkoutcie, zwłaszcza na komputerach korzystających z udziałów sieciowych, dysków zewnętrznych, rygorystycznych zabezpieczeń punktów końcowych lub nietypowych uprawnień systemu plików.\n\n Jeśli transfer się nie powiedzie, przed wielokrotnym ponawianiem sprawdź podstawy. Potwierdź wolne miejsce i uprawnienia do zapisu. Sprawdź, czy ścieżka jest lokalna i stabilna. Zajrzyj do logów LFS oraz skonfigurowanego punktu końcowego repozytorium. Zweryfikuj checkout za pomocą zwykłego procesu budowania projektu albo walidacji zasobów. To, że aplikacja graficzna pozostaje otwarta, jest pomocne, ale nie dowodzi kompletności obiektu.\n\n W tym miejscu znaczenie ma również otwartoźródłowy charakter GitHub Desktop. [Repozytorium](https://github.com/desktop/desktop) jest publiczne, changelog zapisuje odwołania do zgłoszeń, a metadane aplikacji wskazują na licencję MIT. Licencja udostępnia kod do wglądu i ponownego wykorzystania, z zastrzeżeniem ograniczeń dotyczących znaków towarowych projektu oraz licencji zależności dołączonych do aplikacji. Nie tworzy jednak umowy wsparcia ani nie gwarantuje jednolitego działania każdej integracji na każdej platformie.\n\n ## Open in Cygwin i niepozorne znaczenie ścieżek\n\n Poprawka Cygwina należy do szerszej kategorii awarii oprogramowania desktopowego: aplikacja rozumie ścieżkę Windows, docelowa powłoka oczekuje ścieżki w stylu POSIX, a na granicy tych dwóch światów pojawiają się spacje albo znaki interpunkcyjne. Ścieżka taka jak katalog nazwany Open Source albo folder zawierający nawiasy jest czymś zwyczajnym dla systemu plików i częstym źródłem błędów cytowania w programach uruchamiających.\n\n Dla użytkownika praktyczne pytanie brzmi, czy naprawiona integracja pasuje do rzeczywistego układu katalogów. Jeśli repozytorium znajduje się w ścieżce zawierającej spacje, nawiasy, nawiasy kwadratowe, ampersandy lub znaki spoza ASCII, po aktualizacji przetestuj akcję menu. Wykonaj test na repozytorium, które nie jest jednorazowe, ale nie używaj do pierwszej walidacji aktywnego checkoutu wydaniowego. Potwierdź, że Cygwin otwiera się we właściwym katalogu i że powłoka widzi te same pliki co klient desktopowy.\n\n Ta zmiana pokazuje również, dlaczego noty wydań aplikacji graficznych mogą wydawać się mniejsze niż błędy, które naprawiają. Sama funkcja to tylko akcja menu. Jej awaria może zablokować cały przepływ pracy osobom korzystającym w Windows z uniksowego zestawu narzędzi. Niezawodne przekazanie ścieżki jest infrastrukturą, nawet jeśli nie brzmi jak atrakcyjna nowa funkcja.\n\n Ta sama ostrożność dotyczy skryptów uruchamianych z klienta. Nie zakładaj, że bieżący katalog roboczy jest wystarczającym kontekstem. Skrypty powinny rozwiązywać katalog główny repozytorium, obsługiwać spacje i kończyć się widocznym komunikatem diagnostycznym, gdy ścieżka nie istnieje. Aplikacja może przekazać prawidłową ścieżkę, ale wywoływane narzędzie nadal musi ją prawidłowo wykorzystać.\n\n ## Kto powinien zaktualizować aplikację jako pierwszy\n\n Najmocniejszy argument za szybką aktualizacją dotyczy programisty, który używa w GitHub Desktop kilku połączonych worktree, pracuje z Git LFS, korzysta z Cygwina w Windows albo ma repozytoria z nietypowymi nazwami referencji. Te osoby są najbliżej zmienionych ścieżek i najszybciej zauważą, czy poprawki pasują do ich pracy.\n\n Druga grupa to opiekunowie repozytoriów wdrażający współpracowników korzystających z różnych systemów operacyjnych. Wydanie usuwające błąd zależny od ścieżki albo nazwy może ograniczyć liczbę zgłoszeń wsparcia, ale lepiej opublikować przetestowane wersje i oczekiwania dotyczące konfiguracji niż traktować aktualizację klienta desktopowego jako uniwersalne rozwiązanie.\n\n Dla użytkownika pracującego z jednym checkoutem na stabilnym komputerze pilność jest mniejsza. W przywołanych notach wydania nie ma dużej nowej funkcji ani reakcji bezpieczeństwa. Aktualizacja pozostaje rozsądną czynnością utrzymaniową, ale niewiele zyskujemy, zakłócając kontrolowane środowisko bez sprawdzenia zgodności.\n\n Najbezpieczniejsze wdrożenie jest etapowe:\n\n 1. Zainstaluj wersję 3.6.7 na jednym komputerze odzwierciedlającym rzeczywisty proces zespołu.\n2. Otwórz repozytorium z połączonym worktree i sprawdź, czy bieżący worktree pozostaje widoczny.\n3. Wykonaj zwykły przepływ obejmujący gałąź, commit, fetch, push i pull request.\n4. Jeśli ma to zastosowanie, przetestuj transfer LFS oraz akcję Open in Cygwin ze ścieżki zawierającej spacje.\n5. Jeśli zespół wspiera więcej niż jedną platformę, osobno sprawdź macOS, Windows i Linux.\n6. Dopiero potem zaktualizuj udokumentowaną wersję bazową dla współpracowników.\n\n Wydanie jest na tyle małe, że taki proces powinien być szybki. Jest też na tyle wyspecjalizowane, że ogólny smoke test może pominąć dokładnie te błędy, które zostały naprawione.\n\n ## Czym GitHub Desktop nadal nie jest\n\n GitHub Desktop nie jest pełnym zamiennikiem wiersza poleceń Gita. Nie ukrywa różnicy między worktree a klonem i nie może zdecydować, czy gałąź należy współdzielić, usunąć, zablokować albo wyczyścić. Zaawansowane utrzymanie repozytorium nadal należy do poleceń Gita i własnej dokumentacji operacyjnej projektu.\n\n Nie jest też pełnym zamiennikiem terminala Cygwina. Naprawiona integracja otwiera inne środowisko, ale nie ujednolica semantyki ścieżek Windows i POSIX we wszystkich narzędziach. Zespół łączący PowerShell, Git Bash, Cygwin, WSL, kontenery i natywne narzędzia budowania powinien jawnie opisywać założenia dotyczące ścieżek.\n\n Nie jest również granicą bezpieczeństwa dla zawartości repozytorium. Otwarcie repozytorium może uruchamiać hooki, renderować niezaufane dane, wywoływać narzędzia zewnętrzne albo korzystać z danych uwierzytelniających, zależnie od przebiegu pracy. Poprawki z changelogu są wartościowe, ale zwykłe środki ostrożności nadal są potrzebne: przeglądaj skrypty repozytorium, ograniczaj dane uwierzytelniające, aktualizuj zależności i oddzielaj eksperymentalne checkouty od wrażliwych środowisk.\n\n Wreszcie otwarte źródła nie oznaczają, że każdy element dystrybucji ma tę samą licencję. Repozytorium określa aplikację jako objętą licencją MIT, natomiast zależności i znaki towarowe GitHub mają własne warunki. Organizacje rozpowszechniające zmodyfikowaną wersję powinny przejrzeć pliki licencyjne repozytorium, informacje o komponentach zewnętrznych i zasady używania marki, zamiast traktować określenie open source jako ogólny wniosek prawny.\n\n ## Alternatywy dla zespołów intensywnie korzystających z worktree\n\n Pierwszą alternatywą jest sam wiersz poleceń Gita. Udostępnia pełny model worktree i stanowi punkt odniesienia dla operacji takich jak add, list, lock, move, repair, prune i remove. Zespół mocno zależny od worktree powinien znać te polecenia, nawet jeśli większość codziennej pracy odbywa się w interfejsie graficznym.\n\n Drugą opcją jest edytor albo środowisko IDE z jawną obsługą wielu katalogów głównych i worktree. Zaletą jest bliskość kodu, terminali, testów i narzędzi językowych. Wadą może być łatwiejsze otwieranie wielu folderów przy mniejszej widoczności współdzielonego stanu Gita. Zespół powinien uzgodnić konwencje nazewnicze i etykiety obszarów roboczych.\n\n Trzecią możliwością jest dedykowany menedżer worktree albo niewielki zestaw skryptów powłoki. Takie narzędzia mogą narzucić układ katalogów, tworzyć przewidywalne nazwy i usuwać nieaktualne drzewa. Tworzą jednak nową powierzchnię utrzymania. Skrypt wygodny na jednym komputerze może stać się niebezpieczny, jeśli zakłada konkretny układ ścieżek, usuwa zmodyfikowane drzewo albo ignoruje blokady i nieśledzone pliki.\n\n GitHub Desktop 3.6.7 najlepiej pasuje do zespołu, który chce wizualnego klienta do codziennych operacji z Gitem i GitHubem, ale akceptuje zasady worktree Gita. To użyteczna warstwa pośrednia, a nie abstrakcja usuwająca stan repozytorium.\n\n ## Praktyczny werdykt\n\n GitHub Desktop 3.6.7 warto przetestować, jeśli w codziennej pracy pojawiają się worktree, Git LFS, Cygwin albo nietypowe nazwy referencji. Widoczne ustawienie worktree poprawia orientację w kontekście, poprawka nazw zaczynających się od myślnika zamyka rzeczywistą klasę błędów obsługi argumentów, naprawa Cygwina czyni częstą granicę ścieżek Windows mniej kruchą, a zmiana w LFS nie pozwala, by błąd odczytu pliku wyłączył klienta.\n\n Dla pozostałych użytkowników jest to zwykła aktualizacja utrzymaniowa o spokojnym profilu. Wydanie jest ciekawsze jako sygnał presji wywieranej na desktopowych klientów Gita: równoległe checkouty stają się codziennością, repozytoria zawierają więcej treści generowanych i binarnych, a programiści stale przechodzą między środowiskiem graficznym a terminalem.\n\n Zainstaluj aktualizację, a następnie sprawdź te krawędzie, które mają znaczenie dla twojego repozytorium. Przed commitem spójrz na aktywny worktree. Utrzymuj widoczne nazwy gałęzi i ścieżki. Przy usuwaniu lub naprawianiu katalogów korzystaj z własnych poleceń worktree Gita. Poprawkę awarii LFS traktuj jako większą odporność, nie jako etap weryfikacji danych. To wystarczy, aby wykorzystać wersję 3.6.7 bez przypisywania małemu wydaniu obietnic, których nie składa.\n\n ## Źródła\n\n - [Informacje o wydaniu GitHub Desktop 3.6.7](https://github.com/desktop/desktop/releases/tag/release-3.6.7)\n- [Changelog GitHub Desktop](https://github.com/desktop/desktop/blob/development/changelog.json)\n- [Repozytorium źródłowe GitHub Desktop i informacje licencyjne](https://github.com/desktop/desktop)\n- [Dokumentacja git-worktree](https://git-scm.com/docs/git-worktree)\n- [Zgłoszenie dotyczące rozróżniania połączonych worktree](https://github.com/desktop/desktop/issues/22211)\n- [Zgłoszenie dotyczące pełnej ścieżki worktree po najechaniu kursorem](https://github.com/desktop/desktop/issues/22946)","available_translations":[{"language":"ar","title":"GitHub Desktop 3.6.7 يصلح الحالات الطرفية التي تجعل Worktrees محفوفة بالمخاطر","html_url":"https://publicasta.com/open_source_radar/github_desktop_3_6_7_worktree_edge_cases?lang=ar","markdown_url":"https://publicasta.com/open_source_radar/github_desktop_3_6_7_worktree_edge_cases.md?lang=ar","json_url":"https://publicasta.com/open_source_radar/github_desktop_3_6_7_worktree_edge_cases.json?lang=ar","api_url":"https://publicasta.com/api/public/v1/channels/open_source_radar/articles/github_desktop_3_6_7_worktree_edge_cases?lang=ar"},{"language":"de","title":"GitHub Desktop 3.6.7 behebt die Sonderfälle, die Worktrees riskant machen","html_url":"https://publicasta.com/open_source_radar/github_desktop_3_6_7_worktree_edge_cases?lang=de","markdown_url":"https://publicasta.com/open_source_radar/github_desktop_3_6_7_worktree_edge_cases.md?lang=de","json_url":"https://publicasta.com/open_source_radar/github_desktop_3_6_7_worktree_edge_cases.json?lang=de","api_url":"https://publicasta.com/api/public/v1/channels/open_source_radar/articles/github_desktop_3_6_7_worktree_edge_cases?lang=de"},{"language":"en","title":"GitHub Desktop 3.6.7 fixes the edge cases that make worktrees risky","html_url":"https://publicasta.com/open_source_radar/github_desktop_3_6_7_worktree_edge_cases?lang=en","markdown_url":"https://publicasta.com/open_source_radar/github_desktop_3_6_7_worktree_edge_cases.md?lang=en","json_url":"https://publicasta.com/open_source_radar/github_desktop_3_6_7_worktree_edge_cases.json?lang=en","api_url":"https://publicasta.com/api/public/v1/channels/open_source_radar/articles/github_desktop_3_6_7_worktree_edge_cases?lang=en"},{"language":"es","title":"GitHub Desktop 3.6.7 corrige los casos límite que vuelven arriesgados los worktrees","html_url":"https://publicasta.com/open_source_radar/github_desktop_3_6_7_worktree_edge_cases?lang=es","markdown_url":"https://publicasta.com/open_source_radar/github_desktop_3_6_7_worktree_edge_cases.md?lang=es","json_url":"https://publicasta.com/open_source_radar/github_desktop_3_6_7_worktree_edge_cases.json?lang=es","api_url":"https://publicasta.com/api/public/v1/channels/open_source_radar/articles/github_desktop_3_6_7_worktree_edge_cases?lang=es"},{"language":"fr","title":"GitHub Desktop 3.6.7 corrige les cas limites qui rendent les worktrees risqués","html_url":"https://publicasta.com/open_source_radar/github_desktop_3_6_7_worktree_edge_cases?lang=fr","markdown_url":"https://publicasta.com/open_source_radar/github_desktop_3_6_7_worktree_edge_cases.md?lang=fr","json_url":"https://publicasta.com/open_source_radar/github_desktop_3_6_7_worktree_edge_cases.json?lang=fr","api_url":"https://publicasta.com/api/public/v1/channels/open_source_radar/articles/github_desktop_3_6_7_worktree_edge_cases?lang=fr"},{"language":"pl","title":"GitHub Desktop 3.6.7 naprawia sytuacje brzegowe, które utrudniają pracę z worktree","html_url":"https://publicasta.com/open_source_radar/github_desktop_3_6_7_worktree_edge_cases?lang=pl","markdown_url":"https://publicasta.com/open_source_radar/github_desktop_3_6_7_worktree_edge_cases.md?lang=pl","json_url":"https://publicasta.com/open_source_radar/github_desktop_3_6_7_worktree_edge_cases.json?lang=pl","api_url":"https://publicasta.com/api/public/v1/channels/open_source_radar/articles/github_desktop_3_6_7_worktree_edge_cases?lang=pl"},{"language":"ru","title":"GitHub Desktop 3.6.7 устраняет пограничные случаи, из-за которых worktree становятся рискованными","html_url":"https://publicasta.com/open_source_radar/github_desktop_3_6_7_worktree_edge_cases?lang=ru","markdown_url":"https://publicasta.com/open_source_radar/github_desktop_3_6_7_worktree_edge_cases.md?lang=ru","json_url":"https://publicasta.com/open_source_radar/github_desktop_3_6_7_worktree_edge_cases.json?lang=ru","api_url":"https://publicasta.com/api/public/v1/channels/open_source_radar/articles/github_desktop_3_6_7_worktree_edge_cases?lang=ru"},{"language":"zh","title":"GitHub Desktop 3.6.7 修复了让 worktree 变得棘手的边缘问题","html_url":"https://publicasta.com/open_source_radar/github_desktop_3_6_7_worktree_edge_cases?lang=zh","markdown_url":"https://publicasta.com/open_source_radar/github_desktop_3_6_7_worktree_edge_cases.md?lang=zh","json_url":"https://publicasta.com/open_source_radar/github_desktop_3_6_7_worktree_edge_cases.json?lang=zh","api_url":"https://publicasta.com/api/public/v1/channels/open_source_radar/articles/github_desktop_3_6_7_worktree_edge_cases?lang=zh"}],"_links":{"self":"https://publicasta.com/open_source_radar/github_desktop_3_6_7_worktree_edge_cases.json?lang=pl","api":"https://publicasta.com/api/public/v1/channels/open_source_radar/articles/github_desktop_3_6_7_worktree_edge_cases?lang=pl","html":"https://publicasta.com/open_source_radar/github_desktop_3_6_7_worktree_edge_cases?lang=pl","canonical":"https://publicasta.com/open_source_radar/github_desktop_3_6_7_worktree_edge_cases?lang=pl","markdown":"https://publicasta.com/open_source_radar/github_desktop_3_6_7_worktree_edge_cases.md?lang=pl","json":"https://publicasta.com/open_source_radar/github_desktop_3_6_7_worktree_edge_cases.json?lang=pl","channel":"https://publicasta.com/api/public/v1/channels/open_source_radar","channel_articles":"https://publicasta.com/api/public/v1/channels/open_source_radar/articles","search":"https://publicasta.com/api/public/v1/search","documentation":"https://publicasta.com/api-docs#reading-publicasta","openapi":"https://publicasta.com/api-docs/openapi.json","llms":"https://publicasta.com/llms.txt"}}