InglesPransesEspanyol

Ad


OnWorks favicon

git-blame - Online sa Cloud

Patakbuhin ang git-blame sa OnWorks na libreng hosting provider sa Ubuntu Online, Fedora Online, Windows online emulator o MAC OS online emulator

Ito ang command git-blame na maaaring patakbuhin sa OnWorks free hosting provider gamit ang isa sa aming maramihang libreng online na workstation gaya ng Ubuntu Online, Fedora Online, Windows online emulator o MAC OS online emulator

PROGRAMA:

NAME


git-blame - Ipakita kung anong rebisyon at may-akda ang huling binago ang bawat linya ng isang file

SINOPSIS


pumunta magbigay-sala [-c] [-b] [-l] [--root] [-t] [-f] [-n] [-s] [-e] [-p] [-w] [--incremental]
[-L ] [-S ] [-M] [-C] [-C] [-C] [--since= ]
[--abbrev= ] [ | --nilalaman | --baligtad ] [--]

DESCRIPTION


Nag-annotate sa bawat linya sa ibinigay na file na may impormasyon mula sa rebisyon na tumatagal
binago ang linya. Opsyonal, simulan ang pag-annotate mula sa ibinigay na rebisyon.

Kapag tinukoy ng isa o higit pang beses, nililimitahan ng -L ang anotasyon sa mga hiniling na linya.

Awtomatikong sinusundan ang pinagmulan ng mga linya sa buong mga pangalan ng file (kasalukuyang nariyan
ay walang opsyon na i-off ang rename-following). Upang sundin ang mga linyang inilipat mula sa isang file patungo sa
isa pa, o upang sundan ang mga linyang kinopya at na-paste mula sa isa pang file, atbp., tingnan ang
-C at -M na mga pagpipilian.

Walang sinasabi sa iyo ang ulat tungkol sa mga linyang tinanggal o pinalitan; ikaw
kailangang gumamit ng kasangkapan tulad ng pumunta Diff o ang interface ng "pickaxe" na maikling binanggit sa
sumusunod na talata.

Bukod sa pagsuporta sa anotasyon ng file, sinusuportahan din ng Git ang paghahanap sa kasaysayan ng pag-unlad
para kapag may naganap na snippet ng code sa isang pagbabago. Ginagawa nitong posible na masubaybayan kung kailan ang isang code
Ang snippet ay idinagdag sa isang file, inilipat o kinopya sa pagitan ng mga file, at kalaunan ay tinanggal o
pinalitan. Gumagana ito sa pamamagitan ng paghahanap ng text string sa diff. Isang maliit na halimbawa ng
pickaxe interface na naghahanap ng blame_usage:

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

Opsyon


-b
Ipakita ang blangkong SHA-1 para sa mga boundary commit. Maaari din itong kontrolin sa pamamagitan ng
blame.blankboundary config na opsyon.

--ugat
Huwag ituring ang root commit bilang mga hangganan. Maaari din itong kontrolin sa pamamagitan ng
blame.showRoot config na opsyon.

--show-stats
Isama ang mga karagdagang istatistika sa dulo ng output ng sisihin.

-L , , -L :
I-annotate lamang ang ibinigay na hanay ng linya. Maaaring tukuyin ng maraming beses. Nagsasapawan
pinapayagan ang mga saklaw.

at ay opsyonal. “-L ” o “-L ,” sumasaklaw mula sa sa
dulo ng file. “-L , ” sumasaklaw mula sa simula ng file hanggang .

at maaaring kumuha ng isa sa mga form na ito:

· numero

Kung o ay isang numero, ito ay tumutukoy sa isang ganap na numero ng linya (mga linya ng bilang
mula sa 1).

· /regex/

Gagamitin ng form na ito ang unang linya na tumutugma sa ibinigay na POSIX regex. Kung ay isang
regex, maghahanap ito mula sa dulo ng nakaraang hanay ng -L, kung mayroon man, kung hindi man
mula sa simula ng file. Kung ay “^/regex/”, maghahanap ito mula sa simula ng
file. Kung ay isang regex, maghahanap ito simula sa linyang ibinigay ni .

· +offset o -offset

Ito ay may bisa lamang para sa at tutukuyin ang ilang linya bago o pagkatapos
ang linyang ibinigay ni .

Kung ": ” ay ibinigay bilang kapalit ng at , ito ay isang regular na expression
na nagsasaad ng hanay mula sa unang linya ng funcname na tumutugma , hanggang sa
susunod na linya ng funcname. “: ” mga paghahanap mula sa dulo ng nakaraang hanay ng -L, kung
anuman, kung hindi man mula sa simula ng file. “^: ” mga paghahanap mula sa simula ng file.

-l
Ipakita ang mahabang rev (Default: naka-off).

-t
Ipakita ang hilaw na timestamp (Default: naka-off).

-S
Gumamit ng mga rebisyon mula sa revs-file sa halip na tumawag git-rev-listNa (1).

--baligtad
Ilakad ang kasaysayan pasulong sa halip na paatras. Sa halip na ipakita ang rebisyon kung saan a
lumitaw ang linya, ipinapakita nito ang huling rebisyon kung saan umiral ang isang linya. Nangangailangan ito
isang hanay ng rebisyon tulad ng START..END kung saan ang path na dapat sisihin ay umiiral sa START.

-p, --porselana
Ipakita sa isang format na idinisenyo para sa pagkonsumo ng makina.

--linya-porselana
Ipakita ang porselana na format, ngunit ang output ay nagbibigay ng impormasyon para sa bawat linya, hindi lamang ang
unang beses na na-reference ang isang commit. Nagpapahiwatig --porselana.

--incremental
Ipakita ang resulta nang paunti-unti sa isang format na idinisenyo para sa pagkonsumo ng makina.

--encoding=
Tinutukoy ang pag-encode na ginagamit upang mag-output ng mga pangalan ng may-akda at gumawa ng mga buod. Pagtatakda nito sa
walang sinisisi ang output na hindi na-convert na data. Para sa karagdagang impormasyon tingnan ang talakayan
tungkol sa pag-encode sa git-log(1) manu-manong pahina.

--nilalaman
Kailan ay hindi tinukoy, ang utos ay nag-annotate ng mga pagbabago simula pabalik mula sa
ang working tree copy. Ginagawa ng watawat na ito ang utos na magpanggap na parang gumaganang kopya ng puno
ay may mga nilalaman ng pinangalanang file (tukuyin - upang gawin ang command na basahin mula sa
karaniwang input).

--date
Tinutukoy ang format na ginamit upang mag-output ng mga petsa. Kung hindi ibinigay ang --date, ang halaga ng
blame.date config variable ang ginagamit. Kung hindi rin nakatakda ang blame.date config variable,
ang iso format ang ginagamit. Para sa mga sinusuportahang halaga, tingnan ang talakayan ng --date na opsyon
at git-logNa (1).

-M| |
I-detect ang mga inilipat o nakopyang linya sa loob ng isang file. Kapag ang isang commit ay gumagalaw o nakopya ng isang bloke ng
mga linya (hal. ang orihinal na file ay may A at pagkatapos ay B, at binago ito ng commit sa B at
pagkatapos A), ang tradisyonal magbigay-sala napapansin lamang ng algorithm ang kalahati ng paggalaw at
karaniwang sinisisi ang mga linyang inilipat pataas (ibig sabihin B) sa magulang at sinisisi
sa mga linyang inilipat pababa (ibig sabihin A) sa child commit. Sa pagpipiliang ito, pareho
ang mga grupo ng mga linya ay sinisisi sa magulang sa pamamagitan ng pagpapatakbo ng mga karagdagang pass ng inspeksyon.

ay opsyonal ngunit ito ang mas mababang hangganan sa bilang ng mga alphanumeric na character
na dapat makita ng Git bilang gumagalaw/kumopya sa loob ng isang file para maiugnay nito ang mga linyang iyon
kasama ang magulang commit. Ang default na halaga ay 20.

-C| |
Bilang karagdagan sa -M, makita ang mga linyang inilipat o kinopya mula sa iba pang mga file na binago sa
ang parehong pangako. Ito ay kapaki-pakinabang kapag inayos mong muli ang iyong programa at inilipat ang code sa paligid
sa kabuuan ng mga file. Kapag ang pagpipiliang ito ay ibinigay ng dalawang beses, ang utos ay naghahanap din
mga kopya mula sa iba pang mga file sa commit na lumilikha ng file. Kapag ibinigay ang pagpipiliang ito
tatlong beses, ang utos ay naghahanap din ng mga kopya mula sa iba pang mga file sa anumang commit.

ay opsyonal ngunit ito ang mas mababang hangganan sa bilang ng mga alphanumeric na character
na dapat makita ng Git bilang gumagalaw/kumopya sa pagitan ng mga file para maiugnay nito ang mga linyang iyon
kasama ang magulang commit. At ang default na halaga ay 40. Kung mayroong higit sa isang -C
mga opsyon na ibinigay, ang Ang argumento ng huling -C ay magkakabisa.

-h
Ipakita ang mensahe ng tulong.

-c
Gamitin ang parehong output mode bilang git-annotate(1) (Default: naka-off).

--score-debug
Isama ang impormasyon sa pag-debug na nauugnay sa paggalaw ng mga linya sa pagitan ng mga file (tingnan ang -C)
at mga linyang inilipat sa loob ng isang file (tingnan ang -M). Ang unang numerong nakalista ay ang iskor. Ito ay
ang bilang ng mga alphanumeric na character na nakitang inilipat sa pagitan o sa loob
mga file. Ito ay dapat na higit sa isang tiyak na limitasyon para sa pumunta magbigay-sala upang isaalang-alang ang mga linya ng
code na inilipat.

-f, --show-name
Ipakita ang filename sa orihinal na commit. Bilang default ang filename ay ipinapakita kung mayroon
anumang linya na nagmula sa isang file na may ibang pangalan, dahil sa rename detection.

-n, --ipakita ang numero
Ipakita ang numero ng linya sa orihinal na commit (Default: off).

-s
Pigilan ang pangalan ng may-akda at timestamp mula sa output.

-e, --ipakita ang email
Ipakita ang email ng may-akda sa halip na pangalan ng may-akda (Default: naka-off). Pwede rin ito
kinokontrol sa pamamagitan ng opsyon na blame.showEmail config.

-w
Huwag pansinin ang whitespace kapag inihahambing ang bersyon ng magulang at ng bata upang mahanap kung saan
nanggaling ang mga linya.

--abbrev=
Sa halip na gamitin ang default na 7+1 hexadecimal digit bilang pinaikling pangalan ng bagay,
gamitin +1 na digit. Tandaan na 1 column ang ginagamit para sa isang caret para markahan ang boundary commit.

ANG PORSELANA FORMAT


Sa format na ito, ang bawat linya ay output pagkatapos ng isang header; ang header sa pinakamababa ay mayroong
unang linya na mayroong:

· 40-byte SHA-1 ng commit ang linya ay iniuugnay sa;

· ang numero ng linya ng linya sa orihinal na file;

· ang numero ng linya ng linya sa huling file;

· sa isang linya na nagsisimula ng isang pangkat ng mga linya mula sa ibang commit kaysa sa nauna,
ang bilang ng mga linya sa pangkat na ito. Sa mga kasunod na linya ay wala ang field na ito.

Ang linya ng header na ito ay sinusundan ng sumusunod na impormasyon nang hindi bababa sa isang beses para sa bawat commit:

· ang pangalan ng may-akda ("may-akda"), email ("may-akda-mail"), oras ("oras ng may-akda"), at time zone
("may-akda-tz"); katulad din para sa committer.

· ang filename sa commit kung saan iniuugnay ang linya.

· ang unang linya ng commit log message ("buod").

Ang mga nilalaman ng aktwal na linya ay output pagkatapos ng header sa itaas, na prefix ng isang TAB. Ito
ay upang payagan ang pagdaragdag ng higit pang mga elemento ng header sa ibang pagkakataon.

Ang porselana na format ay karaniwang pinipigilan ang commit na impormasyon na nakita na.
Halimbawa, ang dalawang linya na sinisisi sa parehong commit ay parehong ipapakita, ngunit ang
isang beses lang ipapakita ang mga detalye para sa commit na iyon. Ito ay mas mahusay, ngunit maaaring mangailangan
higit na estado ang dapat panatilihin ng mambabasa. Maaaring gamitin ang --line-porcelain na opsyon para buo ang output
gumawa ng impormasyon para sa bawat linya, na nagpapahintulot sa mas simple (ngunit hindi gaanong mahusay) paggamit tulad ng:

# bilangin ang bilang ng mga linyang naiugnay sa bawat may-akda
git blame --line-porcelain file |
sed -n 's/^may-akda //p' |
uri | uniq -c | uri -rn

PAGTUKOY PAGBABAGO


Hindi magkatulad pumunta magbigay-sala at pumunta i-annotate sa mga mas lumang bersyon ng git, ang lawak ng anotasyon
maaaring limitado sa parehong hanay ng linya at hanay ng rebisyon. Ang -L na opsyon, na naglilimita
anotasyon sa isang hanay ng mga linya, maaaring tukuyin nang maraming beses.

Kapag interesado kang hanapin ang pinagmulan ng mga linya 40-60 para sa file foo, maaari mong gamitin
ang -L na opsyon na tulad nito (pareho ang ibig nilang sabihin — parehong humihingi ng 21 linya na nagsisimula sa linya
40):

git blame -L 40,60 foo
git blame -L 40+21 foo

Maaari ka ring gumamit ng isang regular na expression upang tukuyin ang hanay ng linya:

git blame -L '/^sub hello {/,/^}$/' foo

na naglilimita sa anotasyon sa katawan ng hello subroutine.

Kapag hindi ka interesado sa mga pagbabagong mas luma sa bersyon v2.6.18, o mga pagbabagong mas luma sa 3
linggo, maaari kang gumamit ng mga specifier ng hanay ng rebisyon na katulad ng pumunta rev-list:

git blame v2.6.18.. -- foo
git blame --since=3.weeks -- foo

Kapag ginamit ang mga specifier ng hanay ng rebisyon upang limitahan ang anotasyon, mga linyang wala pa
nagbago mula noong hangganan ng saklaw (alinman sa commit v2.6.18 o sa pinakahuling commit na
ay higit sa 3 linggong gulang sa halimbawa sa itaas) ay sinisisi para sa commit ng hangganan ng hanay na iyon.

Ang isang partikular na kapaki-pakinabang na paraan ay upang makita kung ang isang idinagdag na file ay may mga linya na nilikha sa pamamagitan ng copy-and-paste
mula sa mga kasalukuyang file. Minsan ito ay nagpapahiwatig na ang developer ay nanggigitata at ginawa
hindi refactor ang code ng maayos. Mahahanap mo muna ang commit na nagpakilala sa file
na may:

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

at pagkatapos ay i-annotate ang pagbabago sa pagitan ng commit at ng mga magulang nito, gamit ang commit^! notasyon:

git blame -C -C -f $commit^! -- foo

INCREMENTAL oUTPUT


Kapag tinawag na may --incremental na opsyon, ang command ay naglalabas ng resulta habang ito ay binuo. Ang
output sa pangkalahatan ay magsasalita tungkol sa mga linya na naantig ng mas kamakailang mga commit muna (ibig sabihin, ang
ang mga linya ay bibigyan ng annotate na wala sa pagkakasunud-sunod) at nilalayong gamitin ng mga interactive na manonood.

Ang format ng output ay katulad ng Porcelain format, ngunit hindi ito naglalaman ng aktwal
mga linya mula sa file na binibigyan ng anotasyon.

1. Ang bawat blame entry ay palaging nagsisimula sa isang linya ng:

<40-byte hex sha1>

Ang mga numero ng linya ay binibilang mula sa 1.

2. Sa unang pagkakataon na lumabas ang isang commit sa stream, mayroon itong iba't ibang impormasyon
tungkol dito na naka-print na may isang salitang tag sa simula ng bawat linya na naglalarawan sa
karagdagang impormasyon sa commit (may-akda, email, committer, petsa, buod, atbp.).

3. Hindi tulad ng Porcelain format, ang impormasyon ng filename ay palaging ibinibigay at nagtatapos
ang entry:

"filename"

at sa gayon ito ay talagang napakadaling i-parse para sa ilang line- at word-oriented na parser
(na dapat ay medyo natural para sa karamihan ng mga scripting language).

nota
Para sa mga taong nag-parse: para maging mas matatag ito, huwag pansinin ang anumang linya sa pagitan
ang una at huli (" " at "filename" na mga linya) kung saan hindi mo nakikilala
ang mga salitang tag (o nagmamalasakit sa partikular na iyon) sa simula ng
"pinalawak na impormasyon" na mga linya. Sa ganoong paraan, kung may idinagdag na impormasyon (tulad ng
ang commit encoding o extended commit commentary), walang pakialam ang isang masisisi na tumitingin.

Pagma-map MGA AUTHORS


Kung ang file na .mailmap ay umiiral sa tuktok na antas ng repositoryo, o sa lokasyong itinuro
sa pamamagitan ng mga opsyon sa pagsasaayos ng mailmap.file o mailmap.blob, ginagamit ito upang i-map ang may-akda at
mga pangalan ng committer at email address sa mga canonical na tunay na pangalan at email address.

Sa simpleng anyo, ang bawat linya sa file ay binubuo ng canonical na tunay na pangalan ng isang
may-akda, whitespace, at isang email address na ginamit sa commit (kalakip ng < at >) sa mapa
sa pangalan. Halimbawa:

Wastong Pangalan[protektado ng email]>

Ang mga mas kumplikadong anyo ay:

<[protektado ng email]>[protektado ng email]>

na nagpapahintulot sa mailmap na palitan lamang ang bahagi ng email ng isang commit, at:

Wastong Pangalan[protektado ng email]>[protektado ng email]>

na nagpapahintulot sa mailmap na palitan ang parehong pangalan at ang email ng isang commit na tumutugma sa
tinukoy na commit email address, at:

Wastong Pangalan[protektado ng email]> Pangalan ng Pangalan[protektado ng email]>

na nagpapahintulot sa mailmap na palitan ang parehong pangalan at ang email ng isang commit na tumutugma sa parehong
tinukoy na pangalan ng commit at email address.

Halimbawa 1: Ang iyong kasaysayan ay naglalaman ng mga pangako ng dalawang may-akda, sina Jane at Joe, na ang mga pangalan ay lumalabas
sa imbakan sa ilalim ng ilang mga form:

Joe Developer[protektado ng email]>
Joe R. Developer[protektado ng email]>
Jane Doe[protektado ng email]>
Jane Doe
Jane D.

Ngayon, ipagpalagay na gusto ni Joe na gamitin ang kanyang middle name, at mas gusto ni Jane ang kanyang family name
ganap na nabaybay. Ang isang maayos na .mailmap file ay magiging ganito ang hitsura:

Jane Doe
Joe R. Developer[protektado ng email]>

Tandaan kung paano hindi na kailangan para sa isang entry para sa , dahil ang tunay na pangalan ng
tama na ang author na yan.

Halimbawa 2: Ang iyong repository ay naglalaman ng mga commit mula sa mga sumusunod na may-akda:

nick1[protektado ng email]>
nick2[protektado ng email]>
nick2[protektado ng email]>
santa[protektado ng email]>
claus[protektado ng email]>
CTO[protektado ng email]>

Pagkatapos ay maaaring gusto mo ng .mailmap file na mukhang:

<[protektado ng email]>[protektado ng email]>
Ilang Dude[protektado ng email]> nick1[protektado ng email]>
Ibang May-akda[protektado ng email]> nick2[protektado ng email]>
Ibang May-akda[protektado ng email]>[protektado ng email]>
Santa Claus[protektado ng email]>[protektado ng email]>

Gumamit ng hash # para sa mga komento na alinman sa kanilang sariling linya, o pagkatapos ng email address.

Gumamit ng git-blame online gamit ang mga serbisyo ng onworks.net


Mga Libreng Server at Workstation

Mag-download ng Windows at Linux apps

Linux command

Ad