Paglabas ng distributed source control system na Git 2.22

Ipinasa ni paglabas ng isang distributed source control system git 2.22.0. Ang Git ay isa sa pinakasikat, maaasahan at may mataas na pagganap na mga sistema ng kontrol ng bersyon, na nagbibigay ng nababaluktot na non-linear na mga tool sa pagpapaunlad batay sa pagsasanga at pagsasama. Upang matiyak ang integridad ng kasaysayan at paglaban sa mga retroaktibong pagbabago, ginagamit ang implicit na pag-hash ng buong nakaraang kasaysayan sa bawat commit, at posible ring patunayan ang mga indibidwal na tag at commit na may mga digital na lagda ng mga developer.

Kung ikukumpara sa nakaraang paglabas, ang bagong bersyon ay may kasamang 745 na pagbabago, na inihanda kasama ang pakikilahok ng 74 na mga developer, kung saan 18 ang nakibahagi sa pag-unlad sa unang pagkakataon. Ang pangunahing mga inobasyon:

• Available mula noong release 1.18, pinapalitan ng bagong commit rebase mode na "git rebase --rebase-merges" ang lumang opsyon na "--preserve-merges", na hindi na ginagamit ngayon. Ang "git rebase" na operasyon ay ginagamit upang palitan ang isang serye ng mga commit ng isang bagong base commit, halimbawa, upang ilipat ang isang hiwalay na sangay na bumubuo ng ilang bagong tampok sa kasalukuyang estado ng master branch, na kinabibilangan ng mga pag-aayos na idinagdag pagkatapos ng branch :

  o - o - o (aking-tampok)

  /

  o - o - o - o - o (master)

  o - o - o (aking-tampok)

  /

  o - o - o - o - o (master)

  Upang mapanatili ang istraktura ng sangay sa isang migrate na sangay, ang opsyong "--preserve-merges" ay maaaring gamitin dati, na, kapag tumakbo sa interactive na mode (git rebase -i --preserve-merges), pinapayagan ang pag-edit ng commit history, ngunit hindi ginagarantiyahan ang kumpletong pangangalaga ng istraktura ng imbakan. Ang bagong mode na "--rebase-merges" ay nagbibigay-daan sa iyo na mapanatili ang istruktura ng mga pagbabago sa branch na ini-migrate, habang nagbibigay ng buong hanay ng mga interactive na operasyon, kabilang ang pagtanggal, muling pagpapangkat at pagpapalit ng pangalan sa mga commit.

  Halimbawa, "--rebase-merges" ay nagbibigay-daan sa muling pag-upload ng mga commit mula sa isang hiwalay na branch patungo sa isang mas bagong master branch, habang pinapanatili ang istraktura ng branch sa migrate na branch, at gumagawa ng ilang pagbabago sa mga commit na tala sa mabilisang.

• Nagdagdag ng suporta para sa paglikha ng isang bagong sangay batay sa resulta ng pagtukoy sa pinagsanib na base ng dalawang iba pang mga sangay (pagsamahin ang base, nagbubuklod sa isang karaniwang ninuno) gamit ang mga konstruksyon na "git branch new A...B" at "git checkout -b new A...B", kung saan ang "A ...B" ay kinabibilangan ng pagtukoy ng merge base sa pagitan ng dalawang tinukoy na commit, katulad ng kung paano inilipat ng "git checkout A...B" ang HEAD sa base commit at "diff A. ..B" ay nagpapakita ng mga pagbabago sa pagitan ng commit "B" at kapareho ng commit "A" "Ancestor.

  Halimbawa, kapag nagtatrabaho sa isang hiwalay na my-feature branch, maaaring gamitin ang feature na ito kapag gusto mong magsimula sa ibang branch, halimbawa, mula sa parehong lugar sa master branch kung saan na-check out ang my-feature branch. Dati, kailangan nitong manual na suriin ang log ng pagbabago, na hindi maginhawa kung mayroon kang malaking kasaysayan ng mga pagbabago, pagkatapos ay patakbuhin ang "git merge-base master my-feature" upang kalkulahin ang hash ng merge base sa pagitan ng master at my-feature branch at paggawa ng bagong sangay na nauugnay sa karaniwang ninuno na " git branch my-other-feature hash." Sa Git 2.22, maaari mong gamitin ang syntax na "git branch my-other-feature A...B" upang lumikha ng isang sangay na nauugnay sa pinagsanib na base ng dalawa pang branch;

• Idinagdag ang opsyon na "git branch --show-current" upang ipakita ang pangalan ng branch na nakuha sa panahon ng pagpapatakbo ng pag-checkout;
• Idinagdag ang opsyong “git checkout —no-overlay — dir”, na nagbibigay-daan, kapag nagsasagawa ng operasyon ng pag-checkout, na dalhin ang mga nilalaman ng direktoryo ng dir sa isang form na ganap na tumutugma sa estado ng master branch. Halimbawa, kung mayroong isang file sa lokal na kopya ng direktoryo ng dir na wala sa master branch, pagkatapos ay sa pamamagitan ng default kapag nag-execute ng "git checkout master - dir" ito ay maiiwan, at kung ang "--no-overlay ” ang pagpipilian ay tinukoy, ito ay tatanggalin;
• Ang utos na "git diff" ay gumagamit ng isang unibersal na API para sa mga opsyon sa pag-parse, na ginagawang posible na pag-isahin ang paghawak ng opsyon sa iba pang mga git utilities. Halimbawa, sa "git diff", ang lahat ng mga opsyon ay mayroon na ngayong mga antagonist ("--function-context" at "--no-function-context");
• Idinagdag ang kakayahang mag-filter ng mga pinahabang tag na naka-attach sa mga commit sa "git log" na output ("trailer" - mga karagdagang flag ng impormasyon, tulad ng Signed-off-by at Co-authored-by). Posibleng i-filter ang mga label ayon sa key at value, halimbawa:
  "git log --pretty="%(trailer:key=Reviewed-by,valueonly)";

• Ang isang bagong tracing engine, ang Trace2, ay idinagdag, na nag-aalok ng isang mas flexible at structured na format ng output. Pinapayagan ka ng Trace2 na mangolekta ng telemetry tungkol sa mga isinagawang operasyon at data ng pagganap para sa mas detalyadong pagsusuri at pag-debug (ang handler ay itinalaga ng user, walang data na ipinapadala sa labas);
• Ang ulat na "git bisect" ay ginawang mas nababasa, kung saan ang mga may problemang commit ay mas malinaw na na-highlight at ang mga buod na istatistika sa mga pagbabago para sa bawat file ay ipinapakita (sa antas ng bilang ng mga linyang binago);
• Ang heuristics para sa pagtukoy ng mga pagpapalit ng pangalan ng direktoryo ay muling ginawa upang maalis ang maling pag-install ng pagpapalit ng pangalan ng mga label. Kapag may pagdududa, ang mga naturang direktoryo ay minarkahan na ngayon bilang magkasalungat;
• Ang isang babala ay ipinapakita kapag sinubukan mong mag-install ng tag sa isa pang tag, na kadalasang ginagawa nang hindi sinasadya at maaaring humantong sa pagtatakda ng tag sa maling commit (halimbawa, isang construction tulad ng "git tag -f -m "updated message" my-tag1 my- tag2″ ay magreresulta sa isang tag na gagawin sa lumang tag, samantalang inaasahan ng developer na mai-install ang bagong tag sa commit na itinuro ng lumang tag);
• Ang pagbuo ay pinagana para sa mga bitmap repository (disk-based na "reachability bitmaps" na istraktura), na nag-iimbak ng data tungkol sa mga hanay ng mga bagay na magagamit para sa bawat commit at nagbibigay-daan sa iyong mabilis na matukoy ang pagkakaroon ng isang base object. Ang istrukturang ito ay makabuluhang binabawasan ang oras ng pagpapatupad ng mga operasyon sa pagkuha ng data (git fetch).

Pinagmulan: opennet.ru