Ang pagdating de git 2.54 Ito ay nagmamarka ng isang bagong hakbang sa ebolusyon ng pinakamalawak na ginagamit na version control system sa mundo para sa pagbuo ng software. Ang komunidad ng proyekto, na may mahigit 130 katao na nakikipagtulungan sa siklong ito, ay nakatuon sa pagpapasimple ng mga karaniwang gawain nang hindi isinasakripisyo ang kapangyarihang nagpapakilala sa Git.
Kabilang sa mga bagong tampok na maaaring maging pinakainteresante ay ang isang bagong paraan upang muling isulat ang kasaysayan Sa mas direktang paraan, ang kakayahang i-configure ang mga shared hook mula sa mga karaniwang configuration file at mga panloob na pagpapabuti na naghahangad ng mas mabilis at mas madaling mapanatiling mga repository, lalo na sa malalaki o corporate na mga proyekto.
Git 2.54: Pangkalahatang-ideya ng bagong release
Ang Git 2.54 ay isang intermediate na bersyon na patungo sa susunod na 3.0 na sangay, ngunit nagdadala ito ng mga pagbabago na nakakaapekto sa pang-araw-araw na gawain ng maraming developer. Una sa lahat, Inilabas na ang eksperimental na utos na git historyDinisenyo para sa mga simpleng operasyon sa muling pagsusulat ng kasaysayan. Bukod pa rito, ang sistema ng mga kawit ay pinalawak at pinamoderno, at maaari na ngayong pamahalaan mula sa mga setting; ang estratehiya sa pagpapanatili ng heometriko ay ang default na ngayon.
Bukod pa rito, kasama ang mga pagpapabuti sa mga kilalang utos tulad ng git add -p, git replay, git status o git rebasepati na rin ang mga pagsasaayos sa HTTP transport, ang paraan ng pagpapakita ng mga GPG signature, at ang mga panloob na paggana ng object database. Bagama't marami sa mga bagong tampok na ito ay mas advanced, ang kanilang epekto ay mapapansin sa mga karaniwang daloy ng trabaho sa mga negosyo, pampublikong administrasyon, at mga open source na proyekto na may malalaking repository.
Bagong kasaysayan ng eksperimental na utos na git: madaling muling pagsulat ng mga commit
Isa sa mga pangunahing karagdagan sa Git 2.54 ay kasaysayan ng git, isang utos na patuloy pa ring ginagamit sa eksperimento na nilayong sumaklaw sa mga kaso kung saan ang paggamit ng interactive rebase ay labis-labis. Hanggang ngayon, ang pangunahing tool para sa pagbabago ng lokal na kasaysayan ay git rebase -i, napaka-flexible ngunit mas kumplikado rin at madaling mag-iwan sa gumagamit sa magkakasalungat na mga estado na kailangang manu-manong lutasin.
may kasaysayan ng git Isang mas direktang pamamaraan ang hinahanap para sa mga partikular na gawain: halimbawa, itama ang isang typo sa mensahe ng isang commit mula sa ilang pagbabago na ang nakalipas, o paghahati ng isang commit na naging masyadong malaki sa dalawa. Ang ideya ay mag-alok ng isang kontroladong paraan upang baguhin ang kasaysayan nang hindi kinakailangang i-set up ang buong makinarya ng isang interactive rebase na may mga listahan ng gawain at mga intermediate na hakbang.
baguhin ang salita subcommand: i-tweak ang mga mensahe ng commit nang hindi hinahawakan ang gumaganang puno
Ang unang paraan na ilulunsad ng bagong order ay git history reword <commit>Kapag ginamit, binubuksan ng Git ang user-configured editor gamit ang tinukoy na mensahe ng commitna nagpapahintulot sa iyo na baguhin ito nang direkta. Kapag na-save at isinara mo ang editor, muling isinusulat ng Git ang commit na iyon at awtomatikong ina-update ang mga branch na bumababa mula rito upang tumuro sa bagong bersyon.
Ang pangunahing pagkakaiba kumpara sa isang interactive rebase ay Hindi tinatablan ng `git history reword` ang working tree o ang indexIna-update lamang nito ang history. Ginagawa itong lalong kapaki-pakinabang sa mga continuous integration environment o automated scripts, dahil maaari pa itong gumana sa mga bare repository, na karaniwan sa mga internal code server ng mga kumpanya o institusyon kung saan walang kaugnay na working tree.
hatiin ang subcommand: interactive na hatiin ang isang commit
Ang pangalawang modus, git history split <commit>Ito ay dinisenyo para sa mga sitwasyon kung saan ang isang commit ay naglalaman ng mga pagbabagong dapat paghiwalayin. Kapag naisakatuparan, ipinapakita ng Git ang mga hugs na nauugnay sa commit na iyon at nagbibigay-daan sa iyong pumili kung alin ang dapat i-extract sa isang bagong parent commit, katulad ng kung paano gumagana ang `git extract`. git add -p kapag nagpapasya kung aling mga piraso ng code ang idadagdag sa index.
Kapag napili na ang mga fragment, gagawa ang Git ng isang Bagong pangako kasama ang mga hunk na napili bilang magulang ng orihinalPinapanatili nito ang mga hindi napiling pagbabago sa nakaraang commit. Pagkatapos, isinusulat nito muli ang mga descendant branch upang ituro ang bagong istruktura ng kasaysayan. Muli, tumatakbo ang operasyon nang hindi binabago ang kasalukuyang nilalaman ng working tree, na binabawasan ang posibilidad na maiwan ang repository sa isang komplikadong intermediate state.
Mga Limitasyon at Pagkatugma sa Iba Pang mga Daloy ng Trabaho
Para mapanatiling kontrolado ang kilos, Hindi sinusuportahan ng kasaysayan ng git ang mga kasaysayan na may mga merge commit at tumatangging magpatuloy kung ang operasyon ay magreresulta sa mga conflict sa merge. Ito ay dinisenyo para sa maliliit na pagsasaayos, hindi para sa malalaking muling pagsulat tulad ng mga karaniwang hinahawakan gamit ang git rebase -i o mas agresibong mga estratehiya sa paglilinis ng kasaysayan.
Sa loob, ang utos ay umaasa sa makinarya ng git replayna pinagsasama-sama bilang isang eksperimental na kagamitan para sa pagkopya ng mga commit sa ibang base nang hindi hinahawakan ang working tree. Bahagi ng gawaing ito ay binubuo ng pagkuha ng lohikang iyon sa isang karaniwang library, upang ang parehong git history dahil ang iba pang mga functionality sa hinaharap ay maaaring makinabang mula sa isang mas modular na imprastraktura na mas madaling i-automate mula sa mga script o mga tool ng third-party.
Mga hook na nakabatay sa configuration: pagbabahagi at pagsasama-sama ng mga automation
Isa pang kapansin-pansing bagong tampok ng Git 2.54 ay ang kakayahang tukuyin ang mga hook nang direkta sa mga configuration file, sa halip na umasa lamang sa mga script na nakalagay sa direktoryo .git/hooks o sa rutang ipinahiwatig ng core.hooksPathGinagawang mas madali ng pagbabagong ito ang pagbabahagi ng mga tseke sa pagitan ng iba't ibang repositoryo nang hindi kinakailangang manu-manong kopyahin ang mga file.
Hanggang ngayon, para makapag-apply, halimbawa, ng code formatter o secrets analyzer bago ang bawat commit sa maraming proyekto, kinakailangang kopyahin ang hook script sa bawat repository o gumamit ng mga external hook management tool. Gamit ang bagong diskarte, posibleng tukuyin mga gitnang kawit sa ~/.gitconfig o sa a /etc/gitconfig korporasyon at ang mga ito ay ilalapat kung saan kinakailangan.
Pagtukoy sa mga hook ayon sa configuration at maraming command bawat event
Ang bagong syntax ay batay sa mga style configuration key hook.<nombre>.command y hook.<nombre>.eventAng una ay nagpapahiwatig kung aling utos ang isasagawa, at ang pangalawa ay tumutukoy aling hook event ang nagti-trigger nitohalimbawa isang pre-commit o isang pre-pushDahil ito ay isang karaniwang configuration, ang mga setting na ito ay maaaring magsabay na umiiral sa iba't ibang antas: user, system, o repository.
Bukod pa rito, pinapayagan na ngayon ng Git na maraming hook ang nakatalaga sa iisang kaganapanSa madaling salita, maaari kang magtakda, halimbawa, ng isang linter at isang credential scanner na tatakbo sa bawat isa pre-commitnang hindi kinakailangang manu-manong pagsamahin ang mga ito sa isang script. Sinusubaybayan ng Git ang mga entry ng configuration nang sunod-sunod at isinasagawa ang bawat command, habang pinapanatili rin ang suporta para sa klasikong script. $GIT_DIR/hooks, na patuloy na tumatakbo sa dulo upang hindi masira ang mga nakaraang configuration.
Pamamahala, pag-deactivate at panloob na modernisasyon ng mga kawit
Para malaman kung aling mga hook ang aktibo at kung saan sila nanggagaling, ginagamit ang sumusunod na command git hook listna nagpapakita ng pinagmulan ng bawat isa, isang bagay na kapaki-pakinabang kapag pinamamahalaan mga sentralisadong konpigurasyon Sa mga kapaligirang pangkorporasyon, kung kailangang ibukod ng isang partikular na repositoryo ang isang hook na minana mula sa isang pandaigdigang file, sapat na ang pagtatakda hook.<nombre>.enabled = false, nang hindi kinakailangang tanggalin o baguhin ang orihinal na configuration.
Sa ilalim ng hood, mayroon ang Git pinag-isa at pinamoderno ang paraan ng paghawak nito sa marami sa mga panloob na kawit nitoIlang integration point na dating pinamamahalaan gamit ang mga ad hoc route, tulad ng mga hook para sa pre-push, post-rewrite o ng mga receive-packGinagamit na nila ngayon ang bagong hooks API. Hindi lamang ito nagdudulot ng consistency, kundi ginagawang mas madali rin para sa mga continuous integration environment o code forging platform na umangkop sa mga pagbabago sa hinaharap nang hindi kinakailangang muling isulat ang mga partikular na integration.
Pagpapanatili ng heometriko bilang isang default na diskarte
Sa mga nakaraang bersyon, ipinakilala ng Git ang tinatawag na estratehiya geometriko sa loob git maintenanceDinisenyo upang mabawasan ang gastos ng mga gawain sa pag-repack sa malalaking repository, sinusuri ng estratehiyang ito ang mga umiiral na packfile at hinahanap ang mga kumbinasyon na bumubuo ng isang geometric progression ayon sa bilang ng mga bagay, pinapaikli ang kanilang mga nilalaman nang hindi kinakailangang magsagawa ng isang buong garbage collection sa bawat oras.
Sa Git 2.54, ang pamamaraang ito ay nagiging ang default na opsyon para sa manu-manong pagpapanatiliKapag tumatakbo ito git maintenance run Nang hindi tinutukoy ang estratehiya, awtomatikong pinipili ang geometric na pamamaraan, sa halip na direktang bumaling sa klasikong gawain ng gc na sumusubok na pangkatin ang lahat sa isang pakete.
Sa pagsasagawa, nangangahulugan ito na Mas mahusay na pinapanatili ang mga imbakan Sa simula pa lang, ito ay lalong kawili-wili para sa mga proyektong may mahabang kasaysayan o para sa mga organisasyong namamahala ng malalaking monorepository. Pinagsasama ng geometric strategy ang mga incremental package kapag ito ay may katuturan at bumabaling lamang sa isang gc Kumpletuhin kapag aktwal nitong pagsasama-samahin ang lahat sa isang packfile. Sa proseso, ang commit graph, mga reflog, at iba pang mga auxiliary structure ay pinapanatiling napapanahon.
Yaong mga nakapag-configure na maintenance.strategy = geometric Hindi nila mapapansin ang anumang pagbabago, dahil iginagalang ang kagustuhang iyon. At ang mga mas gustong magpatuloy sa tradisyonal na pamamaraan ay maaaring pilitin ang estratehiya gc pag-set up maintenance.strategy = gcsa gayon ay napapanatili ang pagiging tugma sa mas konserbatibong mga daloy.
Mga pagpapabuti sa mga interactive at eksperimental na utos
Higit pa sa mga pangunahing bagong tampok, ang Git 2.54 ay nagdadala ng maraming pagbabago na naglalayong pagbutihin ang pang-araw-araw na karanasan ng gumagamitlalo na sa mga utos na ginagamit nang interaktibo upang pamahalaan ang mga pagbabago.
Mga pagpipino sa git add -py mga bagong opsyon sa nabigasyon
Ang interaktibong paraan ng git add -p at mga kaugnay na utos ay tumatanggap ng iba't ibang pagpapabuti sa usability. Kapag nagna-navigate sa pagitan ng mga hunks gamit ang mga key J y KIpinapakita ngayon ng Git kung ang isang fragment tinanggap o nilaktawan na datiiniiwasan ang manu-manong pag-alala sa bawat desisyon.
Idinagdag din ang opsyon --no-auto-advancena nagbabago sa gawi kapag tinatapos ang mga piraso ng isang file. Sa halip na awtomatikong lumipat sa susunod na file, nananatili ang session sa kasalukuyan, na nagbibigay-daan sa iyong gamitin < y > para mas mahinahon na lumipat sa pagitan ng mga file. Ang ganitong paraan ng pagtatrabaho ay kapaki-pakinabang kapag gusto mong suriin ang mga napiling pagbabago sa kabuuan bago kumpirmahin ang mga ito.
git replay: mas maraming kapanahunan para sa muling pagpapatupad ng mga commit
Ang eksperimental na pagkakasunud-sunod git replayAng tampok na idinisenyo upang kopyahin ang mga commit sa isang bagong base nang hindi binabago ang working tree ay patuloy na nagkakaroon ng mga kakayahan. Sa bersyong ito, gumaganap na ito ngayon mga sanggunian na i-update nang atomiko Bilang default, sa halip na mag-dump ng mga utos update-ref sa karaniwang output.
Bukod pa rito, mayroon itong mode --revert nagpapahintulot baligtarin ang mga pagbabago mula sa isang hanay ng mga commitKaya nitong itapon ang mga commit na nawawalan ng laman habang isinasagawa ang proseso at ngayon ay sinusuportahan nito ang pag-replay ng history pabalik sa root commit. Ang mga pagpapabuting ito ay akma sa paggamit ng git history, na umaasa sa parehong imprastraktura upang mag-alok ng mas ligtas na karanasan.
Bagong opsyon – trailer sa git rebase
Isa pang kawili-wiling pagsasaayos ay ang pagdaragdag ng --trailer en git rebasena sinasamantala ang lohika ng interpret-trailers para idagdag ang parehong trailer sa bawat overshot commitSa halip na bumuo ng mahahabang utos gamit ang -x at tumatawag sa git commit --amend --no-edit --trailer=...Maaari mong direktang tukuyin ang nais na trailer kapag inilulunsad ang overrun.
Pinapasimple nito nang husto ang mga paulit-ulit na gawain tulad ng pagsasama ng mga linya ng tipo Reviewed-by: o mga anotasyon na katulad ng isang serye ng mga commit, isang bagay na karaniwan sa mga pormal na proseso ng pagsusuri ng code na ginagamit sa mga distributed team.
Paghahatid ng HTTP at pamamahala ng lagda: mas pinong pag-uugali
Sa usapin ng komunikasyon sa network, ipinakikilala ng Git 2.54 ang mga kaugnay na pagbabago sa paghawak ng mga tugon ng HTTP at sa interpretasyon ng mga cryptographic signature na nauugnay sa mga commit at tag.
Pamamahala ng tugon ng HTTP 429 at mga pagsubok na maaaring i-configure muli
Natututo ang HTTP transport ng Git na bigyang-kahulugan nang tama ang mga code 429 «Masyadong Maraming Kahilingan»Hanggang ngayon, kapag ang isang server ay nagbalik ng 429 error, ito ay itinuturing na isang nakamamatay na error at nabigo ang operasyon. Simula sa bersyong ito, maaaring subukan muli ng Git ang kahilingan habang nirerespeto ang halaga ng header. Retry-After kung mayroon, o gumagamit ng isang maaaring i-configure na pagkaantala sa pamamagitan ng bagong opsyon http.retryAfter.
Idinagdag din ang mga pagsasaayos http.maxRetries y http.maxRetryTime, na nagpapahintulot kontrolin ang pinakamataas na bilang ng mga muling pagsubok at ang kabuuang oras na ginugol sa mga itoPraktikal ito sa mga kapaligirang pangkorporasyon kung saan kinakailangan ang pag-access sa mga overloaded na server o mga server na may mahigpit na mga patakaran sa paglilimita sa kahilingan, na nakakatulong upang mapadali ang mga operasyon. fetch y push maging mas matatag nang hindi pinaparusahan ang server.
Paghawak ng mga lagda ng GPG na may mga expired na key
Tungkol sa seguridad, isang posibleng nakaliligaw na pag-uugali ang naitama: nang ang isang commit ay nilagdaan gamit ang isang GPG key na kalaunan ay nag-expire na, ipinakita ng Git ang lagda sa isang nakababahalang pulang kulayIpinahihiwatig nito na ang lagda ay hindi wasto. Gayunpaman, kung ang lagda ay wasto noong panahong iyon, ang bisa na iyon ay dapat manatili kahit na ang susi ay nag-expire na.
Inaayos ng Git 2.54 ang lohikang ito at nagpapatuloy sa pagsasaalang-alang Ang mga lagdang ginawa nang tama bago mag-expire ang susi ay balido.Naiiwasan nito ang mga hindi kinakailangang alerto. Nagbibigay ito ng mas tumpak na larawan ng kasaysayan ng repositoryo, na mahalaga para sa mga proyektong may mahahabang lifecycle, tulad ng institutional o public administration software na pinapanatili sa loob ng maraming taon.
Mga bagong kakayahan sa inspeksyon at pagpapasadya ng kasaysayan
Maraming mga utos na idinisenyo upang galugarin ang kasaysayan ay tumatanggap ng mga pagpapabuti na nagpapataas ng kanilang kakayahang umangkop at nagbibigay-daan para sa mas pinasadyang mga output para sa bawat kaso.
Ang `git log -L` ay isinasama sa karaniwang makinarya ng diff
Ang pagpipilian git log -LAng tungkuling nagbibigay-daan sa pagsubaybay sa ebolusyon ng isang hanay ng mga linya sa isang partikular na file ay muling ipinatupad upang iruta ang output nito sa pamamagitan ng karaniwang mekanismo ng pagkakaiba ng GitDati, gumamit ito ng sarili nitong landas, na naging dahilan upang hindi ito tugma sa mga kapaki-pakinabang na opsyon tulad ng -S y -G (ang tinatawag na "mga piko"), o may iba't ibang format ng patch.
Sa pagbabagong ipinakilala sa Git 2.54, -L nagiging tugma sa mga advanced na paghahanap ng nilalaman at iba't ibang formatkasama --word-diff o --color-movedSa ganitong paraan, ang output ay maaaring limitado sa isang partikular na function at, kasabay nito, mai-filter lamang para sa mga commit na nagdaragdag o nag-aalis ng isang partikular na simbolo, na nagpapadali sa mga code audit at regression analysis.
git blame gamit ang pagpili ng diff algorithm
Ang utos sisihin ang git, ginagamit upang makita kung aling commit ang nagpakilala sa bawat linya ng isang file, natututo ng isang bagong opsyon --diff-algorithmNagbibigay-daan ito sa iyo na pumili sa pagitan ng iba't ibang diff algorithm, tulad ng histogram, patience, o minimal, kapag kinakalkula ang line attribution.
Depende sa uri ng mga pagbabagong naranasan ng isang file, Ang pagpili ng isang algorithm kaysa sa iba ay maaaring mag-alok ng mas malinaw na mga resultaBinabawasan nito ang ingay sa mga history ng code na lubos na aktibo. Sa mga kapaligiran kung saan lubos na pinahahalagahan ang mga detalyadong pagsusuri, ang antas ng kontrol na ito ay maaaring gumawa ng malaking pagkakaiba kapag sinisiyasat kung sino ang nagpakilala ng isang partikular na bloke ng code.
Pag-optimize ng imbakan at mga database ng bagay
Ang mga pagbabago sa bersyong ito ay hindi limitado sa user interface; mayroon ding malaking pag-aaral na nagawa sa kung paano gumagana ang Git. nag-oorganisa at nag-a-access ng datos sa loobIto ay may partikular na makabuluhang epekto sa malalaking repositoryo.
Mga karagdagang indeks ng multi-pack at compaction
Ang mga tawag mga incremental index na may maraming pakete (MIDX)Dahil sa mga tampok na pinagbuti na sa mga nakaraang bersyon, ang Git 2.54 ngayon ay may suporta para sa layer compaction. Pinagsasama ng mekanismong ito ang mas maliliit na MIDX layer, kasama ang mga nauugnay na reachability bitmap, upang mapanatili ang layer chain sa makatwirang laki.
Mahalaga ang hakbang na ito para sa ginagawang praktikal ang incremental MIDX sa mga pangmatagalang repositoryotulad ng sa malalaking organisasyon o mga proyekto ng komunidad na may maraming taon ng kasaysayan. Ang pag-compact ng mga layer ay nakakabawas sa pagiging kumplikado ng mga paghahanap at nagpapabuti sa pagganap sa mga operasyon tulad ng fetch, clone mga inspeksyon na may bahagya o kasaysayan.
Muling Pagsasaayos ng Object Database (ODB)
Sa loob, isang malalim na refactoring ng object database API (ODB). Ngayon ay ginagamit ang isang pluggable backend design, kung saan ang mga tungkulin tulad ng read_object(), write_object() o for_each_object() Ipinapadala ang mga ito gamit ang mga function pointer ayon sa pinagmulan.
Bagama't hindi agad nakikita ng end user ang pagbabagong ito, inilalatag nito ang pundasyon para sa mga alternatibong backend ng imbakan sa hinaharap o mas nababaluktot na mga configuration ng object database. Para sa mga kumpanyang may mga partikular na kinakailangan sa pagsunod sa regulasyon o integrasyon sa kanilang sariling mga sistema ng imbakan, ang modularity na ito ay maaaring magbukas ng pinto para sa mas pinasadyang mga solusyon.
Mga pagpapabuti sa status, mga alias, backfill, at iba pang mga detalye
Isinasama rin ng Git 2.54 ang ilang mga pagsasaayos na, bagama't mas maliit, ay nakakatulong sa pagpino ng pang-araw-araw na paggamit at pag-aangkop ng Git sa iba't ibang konteksto ng wika at network.
katayuan ng git at paghahambing sa ilang malalayong sangay
Ang utos git status inilalabas ang opsyon sa pag-configure status.compareBranchesBilang default, ipinapakita ng utos na ito kung paano inihambing ang kasalukuyang sangay sa na-configure nitong upstream, isang tipikal na bagay tulad ng origin/mainGamit ang bagong opsyon, maaari kang humiling ng paghahambing gamit ang push branch, o sa pareho nang sabay.
Ang tungkuling ito ay dinisenyo upang mga tatsulok na daloy, karaniwan kapag gumagamit ng mga fork: maaari kang mag-download mula sa isang opisyal na remote at magpadala ng mga pagbabago sa isa pa, na palaging nililinaw kung gaano karaming mga commit ang naghihiwalay sa bawat branch, na nagbabawas ng mga sorpresa kapag nag-synchronize ng mga repository.
Alyas na may mga internasyonal na karakter
Hanggang ngayon, ang mga alias ng Git ay limitado lamang sa mga ASCII alphanumeric character at hyphen, na pumipigil sa paggamit ng mga pangalan sa ibang mga wika na may mga accent o iba't ibang alpabeto. Sinusuportahan ng bagong syntax ang halos anumang karakter maliban sa mga line break at NUL. Ang pagtutugma ay ginagawa bilang raw bytes at case-sensitive. Bukod pa rito, na-update ang shell autocomplete system upang pangasiwaan ang mga alias na ito, na ginagawang mas madaling gamitin ang Git sa mga multilingual team.
Mas praktikal ang Git backfill sa mga partial clone
Ang eksperimental na utos git backfillAng utos na ginagamit upang i-download ang mga nawawalang blob sa mga partial clone ay pinagtitibay din. Dati, ang utos ay palaging kumukuha ng mga maaabot na blob mula sa HEAD sa buong puno, na maaaring maging labis sa mga partikular na malalaking repositoryo.
Nagdagdag ang Git 2.54 ng suporta para sa pagsusuri ng mga argumento at pathspecupang ang backfill ay malimitahan sa isang hanay ng kasaysayan (halimbawa, main~100..main) o sa ilang partikular na ruta (git backfill -- '*.c'), kasama na ang mga wildcard pattern. Ginagawa nitong mas madaling pamahalaan ang pagtatrabaho sa malalaking partial clones kung saan kailangan mo lamang kumpletuhin ang history ng isang partikular na bahagi ng code.
Iba pang mga pagsasaayos at detalyadong mga pagpapabuti
Kasama sa changelog ng Git 2.54 ang mahabang listahan ng maliliit na pagpapabuti. Kabilang sa mga ito ang isang pag-aayos para sa diff algorithm. histogramna ngayon ay pumipigil sa yugto ng compaction mula sa paggalaw ng mga grupo ng mga pagbabago sa paraang sumisira sa mga napiling linya ng anchor, na nagreresulta sa mas malinis at hindi gaanong paulit-ulit na mga diff.
Mga kagamitan tulad ng git config list , na nagiging opisyal na paraan ng pag-configure ng listahan, git merge-file na kung saan ay nirerespeto ang magagamit na configuration kahit sa labas ng isang repository, at ilang kaugnay na utility git send-emailna nakakakuha ng suporta para sa mga sertipiko ng kliyente at mas maingat na paghawak ng mga set ng karakter na pinili ng gumagamit.
Ang ebolusyon ng Git ay nagpapatuloy sa mahusay na bilis kasama ang bersyon 2.54, na pinagsasama ang nakikitang mga pagpapabuti para sa gumagamit, tulad ng bagong kaayusan git history o mga nako-configure na hook, na nangangailangan ng malaking trabaho sa panloob na imprastraktura ng sistema. Ang lahat ng ito ay tumutukoy sa isang mas matatag at nababaluktot na ecosystem, mas handa para sa mga hamon ng lalong lumalaking mga repositoryo at mas magkakaibang mga koponan.
