git-blame — Online w chmurze

PROGRAM:

IMIĘ

git-blame — Pokaż, jaka wersja i autor ostatnio zmodyfikowali każdą linię pliku

STRESZCZENIE

odrzutowiec winić [-c] [-b] [-l] [--root] [-t] [-f] [-n] [-s] [-e] [-p] [-w] [--inkrementalny]
[-L ] [-S ] [-M] [-C] [-C] [-C] [--od= ]
[--skrót= ] [ | --zawartość | --odwracać ] [--]

OPIS

Adnotuje każdą linię w danym pliku informacjami z ostatniej wersji
zmodyfikował linię. Opcjonalnie rozpocznij opisywanie od podanej wersji.

Po określeniu jeden lub więcej razy, -L ogranicza adnotację do żądanych wierszy.

Pochodzenie wierszy jest automatycznie śledzone przy zmianach nazw całych plików (obecnie istnieje
nie ma opcji wyłączenia śledzenia zmiany nazwy). Aby śledzić linie przeniesione z jednego pliku do
innego, lub podążać za wierszami, które zostały skopiowane i wklejone z innego pliku itp., patrz
Opcje -C i -M.

Raport nie mówi nic o liniach, które zostały usunięte lub zastąpione; Ty
trzeba użyć narzędzia np odrzutowiec diff lub interfejs „kifa” krótko wspomniany w
następujący akapit.

Oprócz obsługi adnotacji do plików, Git obsługuje również przeszukiwanie historii rozwoju
w przypadku wystąpienia fragmentu kodu w zmianie. Dzięki temu możliwe jest śledzenie, kiedy kod
fragment został dodany do pliku, przeniesiony lub skopiowany między plikami, a ostatecznie usunięty lub
zastąpiony. Działa poprzez wyszukiwanie ciągu tekstowego w pliku różnicowym. Mały przykład tzw
interfejs kilofa, który wyszukuje podaną wartość blan_usage:

$ git log --pretty=oneline -S'blame_usage'
5040f17eba15504bad66b14a645bddd9b015ebb7 blame -S <ancestry-file>
ea4c7f9bf69e781dd0cd88d2bccb2bf5cc15c9a7 git-blame: Make the output

OPCJE

-b
Pokaż puste SHA-1 dla zatwierdzeń granic. Można to również kontrolować za pomocą
opcja konfiguracyjna fault.blankboundary.

--źródło
Nie traktuj zatwierdzeń root jako granic. Można to również kontrolować za pomocą
Opcja konfiguracji fault.showRoot.

--pokaż-statystyki
Dołącz dodatkowe statystyki na końcu danych wyjściowych adnotacji.

-L , , -L :
Opisz tylko podany zakres linii. Można podawać wielokrotnie. Nakładające się
zakresy są dozwolone.

oraz są opcjonalne. „-L ” lub „-L ”, obejmuje od do
koniec pliku. „-L , ” obejmuje od początku pliku do .

oraz może przybrać jedną z tych form:

· numer

Gdyby lub jest liczbą, określa bezwzględną liczbę wierszy (liczba wierszy
od 1).

· /wyrażenie regularne/

Ten formularz użyje pierwszej linii pasującej do podanego wyrażenia regularnego POSIX. Gdyby jest
wyrażenie regularne, wyszuka od końca poprzedniego zakresu -L, jeśli istnieje, w przeciwnym razie
od początku pliku. Gdyby to „^/regex/”, będzie wyszukiwane od początku
plik. Gdyby jest wyrażeniem regularnym, wyszukiwanie zaczyna się od linii podanej przez .

· +offset lub -offset

Dotyczy to tylko i określi liczbę linii przed lub po
linia podana przez .

Gdyby ": ” jest podane w miejsce oraz , jest to wyrażenie regularne
co oznacza zakres od pierwszego pasującego wiersza nazwy funkcji , do
następna linia nazwy funkcji. “: ” wyszukuje od końca poprzedniego zakresu -L, jeśli
dowolna, w przeciwnym razie od początku pliku. „^: ” wyszukuje od początku pliku.

-l
Pokaż długie obroty (Domyślnie: wyłączone).

-t
Pokaż nieprzetworzony znacznik czasu (domyślnie: wyłączone).

-S
Użyj wersji z pliku revs zamiast dzwonić git-rev-lista(1).

--odwrócić
Przejdź historię do przodu zamiast do tyłu. Zamiast pokazywać wersję, w której a
pojawiła się linia, która pokazuje ostatnią wersję, w której linia istniała. To wymaga
szereg poprawek, takich jak START..END, gdzie ścieżka do winy istnieje w START.

-p, --porcelana
Pokaż w formacie przeznaczonym do konsumpcji maszynowej.

--linia-porcelana
Pokaż format porcelany, ale wypisz informacje o zatwierdzeniu dla każdej linii, nie tylko
przy pierwszym odwołaniu do zatwierdzenia. Implikuje --porcelana.

--przyrostowe
Pokaż wynik przyrostowo w formacie przeznaczonym do wykorzystania przez maszynę.

--kodowanie=
Określa kodowanie używane do wyprowadzania nazwisk autorów i podsumowań zatwierdzeń. Ustawiam to na
żaden sprawia, że ​​dane wyjściowe z adnotacji nie są przekonwertowane. Więcej informacji w dyskusji
o kodowaniu w git-log(1) strona podręcznika.

--zawartość
Kiedy nie jest określony, polecenie odnotowuje zmiany, zaczynając od
kopia drzewa roboczego. Ta flaga sprawia, że ​​polecenie udaje, że kopia drzewa roboczego
zawiera zawartość nazwanego pliku (określ - aby polecenie było odczytywane z
standardowe wejście).

--Data
Określa format używany do wyprowadzania dat. Jeśli --date nie podano, wartość
Używana jest zmienna konfiguracyjna fault.date. Jeśli zmienna konfiguracyjna fault.date również nie jest ustawiona,
używany jest format ISO. Obsługiwane wartości można znaleźć w omówieniu opcji --date
at git-log(1).

-M| |
Wykryj przeniesione lub skopiowane linie w pliku. Kiedy zatwierdzenie przesuwa się lub kopiuje blok
wierszy (np. oryginalny plik ma A, a potem B, a zatwierdzenie zmienia go na B i
następnie A), tradycyjna winić algorytm zauważa tylko połowę ruchu i
zazwyczaj obwinia linie, które zostały przesunięte w górę (tj. B) do rodzica i przypisuje winę
do linii, które zostały przesunięte w dół (tj. A) do zatwierdzenia podrzędnego. Dzięki tej opcji zarówno
grupy linii są obwiniane na rodzica poprzez przeprowadzanie dodatkowych kontroli.

jest opcjonalne, ale jest to dolna granica liczby znaków alfanumerycznych
które Git musi wykryć jako przenoszenie/kopiowanie w pliku, aby mógł skojarzyć te wiersze
z nadrzędnym zatwierdzeniem. Wartość domyślna to 20.

-C| |
Oprócz -M wykrywa linie przeniesione lub skopiowane z innych plików, które zostały zmodyfikowane w
to samo zobowiązanie. Jest to przydatne, gdy reorganizujesz swój program i przenosisz kod
w plikach. Gdy ta opcja zostanie podana dwukrotnie, polecenie dodatkowo szuka
kopie z innych plików w zatwierdzeniu, które tworzy plik. Kiedy ta opcja jest podana
trzy razy polecenie dodatkowo szuka kopii z innych plików w dowolnym zatwierdzeniu.

jest opcjonalne, ale jest to dolna granica liczby znaków alfanumerycznych
które Git musi wykryć jako przenoszenie/kopiowanie między plikami, aby mógł skojarzyć te wiersze
z nadrzędnym zatwierdzeniem. A wartość domyślna to 40. Jeśli jest więcej niż jedno -C
podane opcje, Argument ostatniego -C zacznie obowiązywać.

-h
Pokaż komunikat pomocy.

-c
Użyj tego samego trybu wyjściowego, co git-adnotacja(1) (Domyślnie: wyłączone).

--score-debug
Dołącz informacje debugowania związane z ruchem linii między plikami (patrz -C)
i linie przeniesione w pliku (patrz -M). Pierwsza wymieniona liczba to wynik. To jest
liczba znaków alfanumerycznych wykrytych jako przesunięte pomiędzy lub w obrębie
akta. To musi być powyżej pewnego progu dla odrzutowiec winić rozważyć te linie
kod został przeniesiony.

-f, --pokaż-nazwę
Pokaż nazwę pliku w oryginalnym zatwierdzeniu. Domyślnie wyświetlana jest nazwa pliku, jeśli istnieje
dowolny wiersz, który pochodzi z pliku o innej nazwie, ze względu na wykrywanie zmiany nazwy.

-n, --pokaż-liczbę
Pokaż numer linii w oryginalnym zatwierdzeniu (domyślnie: wyłączone).

-s
Pomiń nazwisko autora i sygnaturę czasową z danych wyjściowych.

-e, --pokaż-e-mail
Pokaż adres e-mail autora zamiast nazwiska autora (domyślnie: wyłączone). To też może być
kontrolowane za pomocą opcji konfiguracyjnej blan.showEmail.

-w
Zignoruj ​​​​białe spacje podczas porównywania wersji rodzica i dziecka, aby dowiedzieć się, gdzie
pochodziły wiersze.

--skrót=
Zamiast używać domyślnych cyfr szesnastkowych 7+1 jako skróconej nazwy obiektu,
używać +1 cyfra. Zauważ, że 1 kolumna jest używana jako karetka do oznaczenia zatwierdzenia granicy.

THE PORCELANA FORMAT

W tym formacie każda linia jest wyprowadzana po nagłówku; nagłówek ma co najmniej
pierwsza linia, która ma:

· 40-bajtowy SHA-1 zatwierdzenia, do którego przypisana jest linia;

· numer linii w oryginalnym pliku;

· numer linii w pliku końcowym;

· w wierszu rozpoczynającym grupę wierszy od innego zatwierdzenia niż poprzedni,
liczbę linii w tej grupie. W kolejnych wierszach to pole jest nieobecne.

Po tej linii nagłówka co najmniej raz dla każdego zatwierdzenia następuje następująca informacja:

· nazwisko autora („autor”), adres e-mail („autor-mail”), czas („autor-czas”) i strefę czasową
("autor-tz"); podobnie dla committera.

· nazwa pliku w zatwierdzeniu, do którego przypisana jest linia.

· pierwszy wiersz komunikatu dziennika zatwierdzenia („podsumowanie”).

Zawartość rzeczywistej linii jest wyprowadzana po powyższym nagłówku, poprzedzona TAB. Ten
jest umożliwienie późniejszego dodania większej liczby elementów nagłówka.

Format porcelany generalnie pomija informacje o zatwierdzeniu, które zostały już zaobserwowane.
Na przykład dwa wiersze, które są obwiniane za to samo zatwierdzenie, zostaną pokazane, ale
szczegóły tego zatwierdzenia zostaną pokazane tylko raz. Jest to bardziej wydajne, ale może wymagać
czytelnik powinien zachować więcej stanu. Opcja --line-porcelain może być użyta do wyświetlenia pełnego
zatwierdzić informacje dla każdej linii, umożliwiając prostsze (ale mniej wydajne) użycie, takie jak:

# policz liczbę wierszy przypisanych każdemu autorowi
git blan --line-porcelain plik |
sed -n 's/^autor //p' |
sortować | uniq -c | sortuj -rn

OKREŚLANIE ZAKRESY

w odróżnieniu odrzutowiec winić i odrzutowiec komentować w starszych wersjach git zakres adnotacji
można ograniczyć zarówno do zakresów linii, jak i zakresów rewizji. Opcja -L, która ogranicza
adnotacja do zakresu wierszy, może być określona wiele razy.

Jeśli jesteś zainteresowany znalezieniem początku wierszy 40-60 dla pliku foo, możesz użyć
opcja -L w ten sposób (oznaczają to samo — oba proszą o 21 linii zaczynających się od line
40):

git obwiniać -L 40,60 foo
git obwiniać -L 40,+21 foo

Możesz także użyć wyrażenia regularnego, aby określić zakres linii:

git obwiniać -L '/^sub cześć {/,/^}$/' foo

co ogranicza adnotację do treści podprogramu hello.

Gdy nie interesują Cię zmiany starsze niż wersja v2.6.18 lub zmiany starsze niż 3
tygodni, możesz użyć specyfikatorów zakresu wersji podobnych do odrzutowiec lista rewizji:

git obwiniać v2.6.18 .. -- foo
git obwiniać --since=3.weeks -- foo

Gdy specyfikatory zakresu rewizji są używane do ograniczania adnotacji, linie, które ich nie mają
zmienił się od granicy zakresu (albo zatwierdzenie v2.6.18, albo ostatnie zatwierdzenie to
ma więcej niż 3 tygodnie w powyższym przykładzie) są obwiniani za to zatwierdzenie granicy zakresu.

Szczególnie przydatnym sposobem jest sprawdzenie, czy dodany plik zawiera wiersze utworzone przez kopiowanie i wklejanie
z istniejących plików. Czasami oznacza to, że programista był niechlujny i tak zrobił
niepoprawnie refaktoryzować kod. Możesz najpierw znaleźć zatwierdzenie, które wprowadziło plik
z:

git log --diff-filter=A --pretty=short -- foo

a następnie opisz zmianę między zatwierdzeniem a jego rodzicami, używając commit^! notacja:

git obwiniać -C -C -f $zatwierdź^! -- bla

PRZYROSTOWE WYDAJNOŚĆ

Wywołane z opcją --incremental polecenie wyświetla wynik w miarę jego tworzenia. The
wyjście generalnie będzie mówić najpierw o liniach dotkniętych nowszymi zatwierdzeniami (tj
wiersze będą opatrzone adnotacjami poza kolejnością) i są przeznaczone do użytku przez widzów interaktywnych.

Format wyjściowy jest podobny do formatu Porcelana, ale nie zawiera danych rzeczywistych
wiersze z pliku, który jest opatrzony adnotacją.

1. Każdy wpis winy zawsze zaczyna się od wiersza:

<40-bajtowy szesnastkowy sha1>

Numery linii liczą się od 1.

2. Gdy zatwierdzenie pojawia się w strumieniu po raz pierwszy, zawiera różne inne informacje
o tym wydrukowany z jednowyrazowym znacznikiem na początku każdej linii opisującej
dodatkowe informacje o zatwierdzeniu (autor, adres e-mail, osoba zatwierdzająca, daty, podsumowanie itp.).

3. W przeciwieństwie do formatu Porcelain, informacja o nazwie pliku jest zawsze podawana i kończy się
wejście:

"Nazwa pliku"

a zatem jest to naprawdę całkiem łatwe do przeanalizowania dla parsera zorientowanego na wiersze i słowa
(co powinno być całkiem naturalne dla większości języków skryptowych).

Note
Dla osób, które analizują: aby uczynić go bardziej niezawodnym, po prostu zignoruj ​​wszelkie linie między nimi
pierwszy i ostatni (" " i "nazwa pliku"), których nie rozpoznajesz
słowa tagu (lub obchodzić się z tym konkretnym) na początku
wiersze „informacji rozszerzonych”. W ten sposób, jeśli kiedykolwiek zostaną dodane informacje (np
kodowanie zatwierdzenia lub rozszerzony komentarz zatwierdzenia), przeglądarka winy nie będzie się tym przejmować.

MAPOWANIE AUTORSKI

Jeśli plik .mailmap istnieje na najwyższym poziomie repozytorium lub we wskazanej lokalizacji
do przez opcje konfiguracyjne mailmap.file lub mailmap.blob, służy do mapowania autora i
nazwiska i adresy e-mail autorów do kanonicznych prawdziwych nazwisk i adresów e-mail.

W prostej formie każdy wiersz w pliku składa się z kanonicznego prawdziwego imienia an
autor, białe znaki i adres e-mail użyty w zatwierdzeniu (załączony przez < i >) do mapy
do nazwy. Na przykład:

Prawidłowa nazwa[email chroniony]>

Bardziej złożone formy to:

<[email chroniony]>[email chroniony]>

co pozwala mailmapowi zamienić tylko część e-mailową zatwierdzenia oraz:

Prawidłowa nazwa[email chroniony]>[email chroniony]>

co pozwala mailmapowi zastąpić zarówno nazwę, jak i adres e-mail zatwierdzenia pasującego do
określony adres e-mail zatwierdzenia oraz:

Prawidłowa nazwa[email chroniony]> Nazwa zobowiązania[email chroniony]>

co pozwala mailmapowi zamienić zarówno nazwę, jak i adres e-mail zatwierdzenia pasującego do obu
określone imię i nazwisko oraz adres e-mail.

Przykład 1: Twoja historia zawiera zatwierdzenia dwóch autorów, Jane i Joe, których nazwiska pojawiają się
w repozytorium pod kilkoma postaciami:

Joe Deweloper[email chroniony]>
Joe R. Deweloper[email chroniony]>
Jane Łania[email chroniony]>
Jane Łania
Jane D.

Załóżmy teraz, że Joe chce, aby użyto inicjału drugiego imienia, a Jane woli swoje nazwisko
w pełni sprecyzowane. Prawidłowy plik .mailmap wyglądałby tak:

Jane Łania
Joe R. Deweloper[email chroniony]>

Zwróć uwagę, że nie ma potrzeby wprowadzania wpisu , bo prawdziwe imię
ten autor ma już rację.

Przykład 2: Twoje repozytorium zawiera zatwierdzenia od następujących autorów:

nick1[email chroniony]>
nick2[email chroniony]>
nick2[email chroniony]>
Święty[email chroniony]>
mikołaj[email chroniony]>
Dyrektor ds. Technicznych[email chroniony]>

Wtedy możesz chcieć plik .mailmap, który wygląda tak:

<[email chroniony]>[email chroniony]>
Jakiś koleś[email chroniony]> nick1[email chroniony]>
Inny autor[email chroniony]> nick2[email chroniony]>
Inny autor[email chroniony]>[email chroniony]>
Święty Mikołaj[email chroniony]>[email chroniony]>

Użyj skrótu # w przypadku komentarzy znajdujących się w osobnym wierszu lub po adresie e-mail.

Korzystaj z git-blame online, korzystając z usług onworks.net