wydanie rozproszonego systemu zarządzania tekstami źródłowymi . Git jest jednym z najpopularniejszych, niezawodnych i wydajnych systemów zarządzania wersjami, oferującym elastyczne narzędzia do nieliniowego rozwoju, oparte na rozgałęzianiu i scalaniu. W celu zapewnienia integralności historii i odporności na zmiany wsteczne, stosuje się niejawne haszowanie całej poprzedniej historii w każdym commicie, możliwe jest również weryfikowanie cyfrowymi podpisami deweloperów poszczególnych tagów i commitów.
W porównaniu do poprzedniego wydania nowa wersja zawiera 745 zmian, przygotowanych przez 74 deweloperów, z których 18 po raz pierwszy wzięło udział w rozwoju. :
- Dostępny od wydania 1.18 nowy tryb przenoszenia zestawu commitów „git rebase —rebase-merges” zastąpił starą opcję „—preserve-merges”, która teraz jest oznaczona jako przestarzała. Operacja „git rebase” służy do zastąpienia serii commitów nowym bazowym commitem, na przykład w celu przesunięcia pojedynczej gałęzi, w której rozwijana jest nowa funkcjonalność, do aktualnego stanu gałęzi master, obejmującego poprawki dodane po rozgałęzieniu:
o — o — o (moja-funkcjonalność)
/
o — o — o — o — o (master)
o — o — o (moja-funkcjonalność)
/
o — o — o — o — o (master)
Aby zachować strukturę rozgałęziania w przenoszonej gałęzi, wcześniej można było stosować opcję „—preserve-merges”, która w trybie interaktywnym (git rebase -i —preserve-merges) pozwalała edytować historię commitów, ale nie gwarantowała pełnego zachowania struktury repozytorium. Nowy tryb „—rebase-merges” pozwala zachować strukturę zmian w przenoszonej gałęzi, oferując pełny zestaw operacji interaktywnych, w tym usuwanie, reorganizację i ponowne nazwanie commitów.
Na przykład „—rebase-merges” przenieść commity z osobnej gałęzi na nowszą gałąź master, zachowując przy tym strukturę rozgałęziania w przenoszonej gałęzi i wprowadzić na bieżąco pewne zmiany w notatkach do commitów.
- Dodano wsparcie dla tworzenia nowej gałęzi na podstawie wyniku określenia bazy scalania dwóch innych gałęzi (merge base, powiązanie z wspólnym przodkiem) za pomocą konstrukcji „git branch new A…B” oraz „git checkout -b new A…B”, w których „A…B” oznacza określenie bazy scalania między dwoma wskazanymi commitami, analogicznie do tego, jak „git checkout A…B” przesuwa HEAD na podstawowy commit, a „diff A…B” pokazuje zmiany między commitem „B” a wspólnym z commitem „A” przodkiem.
Na przykład, pracując nad osobną gałęzią my-feature, sugerowaną możliwość można wykorzystać, gdy trzeba rozpocząć z innej gałęzi, na przykład z tego samego miejsca w gałęzi master, z którego wyciągnięta została gałąź my-feature. Wcześniej wymagało to ręcznego przeglądania logu zmian, co stwarzało niedogodności przy dużej historii zmian, a następnie wykonania „git merge-base master my-feature” w celu obliczenia hasha bazy scalania między gałęziami master i my-feature oraz stworzenia nowej gałęzi w odniesieniu do wspólnego przodka „git branch my-other-feature hash”. W Git 2.22 do tworzenia gałęzi w odniesieniu do bazy scalania dwóch innych gałęzi można użyć składni „git branch my-other-feature A…B”;
- Dodano opcję „git branch —show-current” do wyświetlania nazwy gałęzi otrzymanej po wykonaniu operacji checkout;
- Dodano opcję „git checkout —no-overlay — dir”, która pozwala przy wykonaniu operacji checkout dostosować zawartość katalogu dir do stanu, który całkowicie odpowiada stanowi gałęzi master. Na przykład, jeśli w lokalnej kopii katalogu dir znajduje się plik, który nie występuje w gałęzi master, to domyślnie podczas wykonywania „git checkout master — dir” zostanie on pozostawiony, a przy wskazaniu opcji „—no-overlay” usunięty;
- W komendzie „git diff” wykorzystano uniwersalny API do analizy opcji, co pozwoliło na ujednolicenie przetwarzania opcji z innymi narzędziami git. Na przykład, w „git diff” dla wszystkich opcji są teraz dostępne również ich antagonisty („—function-context” i „—no-function-context”);
- Dodano możliwość filtrowania podczas wyświetlania „git log” dołączonych do commitów rozszerzonych etykiet („trailer” — dodatkowe flagi informacyjne, takie jak Signed-off-by i Co-authored-by). Możliwa jest filtracja etykiet zarówno według klucza, jak i według wartości, na przykład:
„git log —pretty=„%(trailers:key=Reviewed-by,valueonly)”; - Dodano nowe narzędzie śledzenia Trace2, które oferuje bardziej elastyczny i zorganizowany format wyjścia. Trace2 umożliwia zbieranie telemetrii na temat wykonywanych operacji oraz danych o wydajności do bardziej szczegółowej analizy i debugowania (użytkownik przypisuje obsługę, żadne dane nie są wysyłane na zewnątrz);
- Raport „git bisect” stał się bardziej czytelny, z teraz wyraźnie wyróżnionymi problematycznymi commitami oraz podsumowującą statystyką zmian dla każdego pliku (na poziomie liczby zmienionych linii);
- Zrewidowano heurystykę wykrywania zmian nazw katalogów, aby wyeliminować fałszywe oznaczenia zmian nazw. W przypadku wątpliwości takie katalogi są teraz oznaczane jako konfliktujące;
- Dodano ostrzeżenie przy próbie przypisania znacznika do innego znacznika, co zazwyczaj odbywa się przez pomyłkę i może prowadzić do przypisania znacznika do niewłaściwego commita (na przykład konstrukcja „git tag -f -m „updated message” my-tag1 my-tag2” prowadzi do stworzenia znacznika na starym znaczniku, podczas gdy deweloper spodziewał się, że nowy znacznik zostanie przypisany do commita, na który wskazuje stary znacznik);
- Włączono generowanie bitmap dostępności dla repozytoriów (struktura dyskowa „reachability bitmaps”), która przechowuje dane o zestawach obiektów dostępnych dla każdego commita, umożliwiając szybkie określenie obecności obiektu bazowego. Wskazana struktura znacząco skraca czas wykonywania operacji wyciągania danych (git fetch).
Źródło: opennet.ru
