git-subtree - Online sa Cloud

PROGRAMA:

NAME

git-subtree - Pagsamahin ang mga subtree at hatiin ang repository sa mga subtree

SINOPSIS

pumunta subtree idagdag -P
pumunta subtree idagdag -P
pumunta subtree hilahin -P
pumunta subtree itulak -P
pumunta subtree pagsamahin -P
pumunta subtree hati -P [OPSYON] [ ]

DESCRIPTION

Ang mga subtree ay nagpapahintulot sa mga subproject na maisama sa loob ng isang subdirectory ng pangunahing proyekto,
opsyonal na kasama ang buong kasaysayan ng subproyekto.

Halimbawa, maaari mong isama ang source code para sa isang library bilang isang subdirectory ng iyong
application.

Ang mga subtree ay hindi dapat ipagkamali sa mga submodules, na para sa parehong gawain. Unlike
submodules, subtree ay hindi nangangailangan ng anumang mga espesyal na constructions (tulad ng .gitmodule file o
gitlinks) na naroroon sa iyong repositoryo, at huwag pilitin ang mga end-user ng iyong repositoryo
gumawa ng anumang espesyal o upang maunawaan kung paano gumagana ang mga subtree. Ang isang subtree ay isang subdirectory lamang
na maaaring italaga sa, branched, at pinagsama kasama ng iyong proyekto sa anumang paraan mo
gusto mo.

Hindi rin sila dapat malito sa paggamit ng diskarte sa pagsasanib ng subtree. Pangunahing
Ang pagkakaiba ay, bukod sa pagsasama-sama ng iba pang proyekto bilang isang subdirectory, maaari mo rin
kunin ang buong kasaysayan ng isang subdirectory mula sa iyong proyekto at gawin itong isang
nakapag-iisang proyekto. Hindi tulad ng diskarte sa pagsasanib ng subtree maaari kang magpalit-palit pabalik-balik
sa pagitan ng dalawang operasyong ito. Kung maa-update ang standalone na library, magagawa mo
awtomatikong pagsamahin ang mga pagbabago sa iyong proyekto; kung i-update mo ang library sa loob ng iyong
proyekto, maaari mong "hatiin" muli ang mga pagbabago at pagsamahin ang mga ito pabalik sa library
proyekto.

Halimbawa, kung ang isang library na ginawa mo para sa isang application ay magiging kapaki-pakinabang sa ibang lugar, ikaw
maaaring kunin ang buong kasaysayan nito at mai-publish iyon bilang sarili nitong git repository, nang wala
hindi sinasadyang paghaluin ang kasaysayan ng iyong proyekto sa aplikasyon.

Tip
Upang mapanatiling malinis ang iyong mga commit na mensahe, inirerekomenda namin na hatiin ng mga tao ang kanilang mga mensahe
commit sa pagitan ng mga subtree at ng pangunahing proyekto hangga't maaari. Ibig sabihin, kung ikaw
gumawa ng pagbabago na makakaapekto sa library at sa pangunahing aplikasyon, gawin ito sa dalawa
mga piraso. Sa ganoong paraan, kapag nahati mo ang library ay gagawa sa ibang pagkakataon, ang kanilang mga paglalarawan
magkakaroon pa rin ng kahulugan. Ngunit kung ito ay hindi mahalaga sa iyo, ito ay hindi kinakailangan. git
Iiwan lang ng subtree ang mga bahagi ng commit na hindi nauugnay sa library kapag ito
hatiin ito sa subproyek mamaya.

UTOS

idagdag
Lumikha ng subtree sa pamamagitan ng pag-import ng mga nilalaman nito mula sa ibinigay o
at remote . Awtomatikong nagagawa ang isang bagong commit, na sumasali sa
kasaysayan ng na-import na proyekto gamit ang iyong sarili. Sa --kalabasa, nag-import lamang ng isang commit
mula sa subproyekto, sa halip na sa buong kasaysayan nito.

pagsamahin
Pagsamahin ang mga kamakailang pagbabago hanggang sa sa subtree. Gaya ng normal pumunta
pagsamahin, hindi nito inaalis ang sarili mong mga lokal na pagbabago; pinagsasama-sama lang nito ang mga pagbabagong iyon
ang pinakabago . Sa --kalabasa, lumilikha lamang ng isang commit na naglalaman ng lahat ng
pagbabago, sa halip na pagsamahin sa buong kasaysayan.

Kung gumagamit ka ng --kalabasa, ang direksyon ng pagsasanib ay hindi palaging kailangang pasulong; kaya mo
gamitin ang command na ito para bumalik sa nakaraan mula v2.5 hanggang v2.4, halimbawa. Kung ang iyong pagsasanib
nagpapakilala ng isang salungatan, maaari mo itong lutasin sa mga karaniwang paraan.

paghila
Eksakto tulad ng pagsamahin, ngunit magkatulad pumunta paghila dahil kinukuha nito ang ibinigay na ref mula sa
tinukoy na malayuang imbakan.

itulak
Ba ang a pagsibak (tingnan sa ibaba) gamit ang ibinibigay at pagkatapos ay a pumunta itulak para itulak
ang resulta sa repository at ref. Magagamit ito para itulak ang iyong subtree sa
iba't ibang sangay ng remote repository.

pagsibak
Mag-extract ng bago, sintetikong kasaysayan ng proyekto mula sa kasaysayan ng subtree. Ang
Kasama lang sa bagong kasaysayan ang mga commit (kabilang ang mga merge) na naapektuhan , at
bawat isa sa mga commit ay mayroon na ngayong mga nilalaman ng sa ugat ng proyekto
sa halip na sa isang subdirectory. Kaya, ang bagong likhang kasaysayan ay angkop para sa pag-export
bilang isang hiwalay na git repository.

Pagkatapos ng matagumpay na paghahati, ang isang solong commit id ay naka-print sa stdout. Ito
tumutugma sa HEAD ng bagong likhang puno, na maaari mong manipulahin gayunpaman
gusto mo.

Ang paulit-ulit na paghahati ng eksaktong kaparehong kasaysayan ay ginagarantiyahan na magkapareho (hal
gumawa ng parehong commit id). Dahil dito, kung magdadagdag ka ng mga bagong commit at pagkatapos
re-split, ang mga bagong commit ay ikakabit bilang mga commit sa ibabaw ng history mo
nabuo noong huling pagkakataon, kaya pumunta pagsamahin at ang mga kaibigan ay gagana gaya ng inaasahan.

Tandaan na kung gagamitin mo --kalabasa kapag nag-merge, dapat hindi lang basta --rejoin
kapag naghiwalay kayo.

Opsyon

-q, --tahimik
Pigilan ang mga hindi kinakailangang output na mensahe sa stderr.

-d, --debug
Gumawa ng higit pang hindi kinakailangang mga mensahe ng output sa stderr.

-P , --prefix=
Tukuyin ang path sa repository sa subtree na gusto mong manipulahin. Ang pagpipiliang ito
ay sapilitan para sa lahat ng mga utos.

-m , --message=
Ang pagpipiliang ito ay may bisa lamang para sa pagdaragdag, pagsasama at paghila (hindi sigurado). Tukuyin bilang ang
commit message para sa merge commit.

Opsyon PARA SA ADD, PAGSASAMA, PUSH, PILIT

--kalabasa
Ang opsyon na ito ay may bisa lamang para sa add, merge, at pull command.

Sa halip na pagsamahin ang buong kasaysayan mula sa subtree na proyekto, gumawa lamang ng isang solong
commit na naglalaman ng lahat ng mga pagkakaiba na gusto mong pagsamahin, at pagkatapos ay pagsamahin ang bago
mag-commit sa iyong proyekto.

Ang paggamit ng opsyong ito ay nakakatulong na mabawasan ang log clutter. Ang mga tao ay bihirang gustong makita ang bawat pagbabago
nangyari iyon sa pagitan ng v1.0 at v1.1 ng library na ginagamit nila, dahil wala sa
ang mga pansamantalang bersyon ay isinama sa kanilang aplikasyon.

paggamit --kalabasa nakakatulong din na maiwasan ang mga problema kapag ang parehong subproject ay kasama ng marami
beses sa parehong proyekto, o aalisin at pagkatapos ay muling idinagdag. Sa ganoong kaso, hindi
makatuwirang pagsamahin pa rin ang mga kasaysayan, dahil hindi malinaw kung aling bahagi ng
kasaysayan ay nabibilang sa aling subtree.

Bukod dito, kasama --kalabasa, maaari kang magpalipat-lipat sa iba't ibang bersyon
ng isang subtree, sa halip na mahigpit na pasulong. pumunta subtree pagsamahin --kalabasa laging nag aadjust
ang subtree upang tumugma sa eksaktong tinukoy na commit, kahit na makarating sa commit na iyon
mangangailangan ng pag-undo ng ilang pagbabago na idinagdag kanina.

Gumamit ka man o hindi --kalabasa, nananatiling buo ang mga pagbabagong ginawa sa iyong lokal na imbakan
at maaaring hatiin sa ibang pagkakataon at ipadala sa agos sa subproject.

Opsyon PARA SA Hatiin

--annotate=
Ang pagpipiliang ito ay may bisa lamang para sa split command.

Kapag bumubuo ng sintetikong kasaysayan, idagdag bilang prefix sa bawat commit
mensahe. Dahil gumagawa kami ng mga bagong commit na may parehong mensahe ng commit, ngunit posible
ibang content, mula sa orihinal na commits, makakatulong ito na maiba ang mga ito at
iwasan ang kalituhan.

Sa tuwing nahati ka, kailangan mong gamitin ang pareho , or else wala kang a
ginagarantiyahan na ang bagong muling nilikhang kasaysayan ay magiging kapareho ng dati. Iyon ay
pigilan ang pagsasanib na gumana nang tama. Sinusubukan pa rin ng git subtree na gawin itong gumana,
lalo na kung gumagamit ka ng --rejoin, ngunit maaaring hindi ito palaging epektibo.

-b , --branch=
Ang pagpipiliang ito ay may bisa lamang para sa split command.

Pagkatapos mabuo ang sintetikong kasaysayan, gumawa ng bagong sangay na tinatawag na
naglalaman ng bagong kasaysayan. Ito ay angkop para sa agarang pagtulak sa itaas ng agos.
hindi pa dapat umiral.

--ignore-join
Ang pagpipiliang ito ay may bisa lamang para sa split command.

Kung gumagamit ka ng --rejoin, sinusubukan ng git subtree na i-optimize ang muling pagtatayo ng kasaysayan nito sa
bumuo lamang ng mga bagong commit mula noong huli --rejoin. --ignore-join hindi pinapagana ito
pag-uugali, na pinipilit itong muling buuin ang buong kasaysayan. Sa isang malaking proyekto, maaari itong
tumagal ng mahabang panahon.

--sa =
Ang pagpipiliang ito ay may bisa lamang para sa split command.

Kung ang iyong subtree ay orihinal na na-import gamit ang isang bagay maliban sa git subtree, its
maaaring hindi tumugma ang kasaysayan sa inaasahan ng git subtree. Sa kasong iyon, maaari mong tukuyin ang
gumawa ng id na tumutugma sa unang rebisyon ng kasaysayan ng subproyekto
na na-import sa iyong proyekto, at susubukan ng git subtree na buuin ang kasaysayan nito
mula doon.

Kung ginamit mo pumunta subtree idagdag, hindi mo dapat kailanganin ang opsyong ito.

--rejoin
Ang pagpipiliang ito ay may bisa lamang para sa split command.

Pagkatapos hatiin, isama ang bagong likhang synthetic na history pabalik sa iyong pangunahing
proyekto. Sa ganoong paraan, ang mga paghahati sa hinaharap ay makakahanap lamang ng bahagi ng kasaysayan
idinagdag mula noong pinakahuling --rejoin.

Kung ang iyong split commit ay napagsama-sama sa upstream subproject, at pagkatapos ay gusto mo
makuha ang pinakabagong upstream na bersyon, ito ay magbibigay-daan sa git's merge algorithm sa higit pa
matalinong iwasan ang mga salungatan (dahil alam nitong bahagi na ang mga sintetikong commit na ito
ng upstream repository).

Sa kasamaang palad, ang paggamit ng opsyong ito ay nagreresulta sa pumunta mag-log nagpapakita ng karagdagang kopya ng bawat bago
commit na nilikha (ang orihinal, at ang synthetic).

Kung gagawin mo ang lahat ng iyong pagsasanib sa --kalabasa, huwag gamitin --rejoin kapag naghiwalay kayo, kasi
hindi mo nais na maging bahagi ng iyong proyekto ang kasaysayan ng subproyekto.

Halimbawa 1. ADD COMMAND

Ipagpalagay natin na mayroon kang lokal na imbakan na gusto mong magdagdag ng panlabas
vendor library sa. Sa kasong ito, idaragdag namin ang git-subtree repository bilang isang subdirectory
ng iyong umiiral nang git-extensions repository in ~/git-extensions/:

$ git subtree add --prefix=git-subtree --squash \
git://github.com/apenwarr/git-subtree.git master

panginoon kailangang wastong remote ref at maaaring ibang pangalan ng branch

Maaari mong alisin ang --squash flag, ngunit ang paggawa nito ay magpapataas ng bilang ng mga commit na iyon
kasama sa iyong lokal na imbakan.

Mayroon na tayong a ~/git-extensions/git-subtree direktoryo na naglalaman ng code mula sa master
sangay ng git://github.com/apenwarr/git-subtree.git sa aming git-extensions repository.

Halimbawa 2. MAGBABAGO A SUBTREE GAMIT COMMIT, Sumanib AT PILIT

Gamitin natin ang repository para sa git source code bilang isang halimbawa. Una, kumuha ng sarili mong kopya
ng git.git repository:

$ git clone git://git.kernel.org/pub/scm/git/git.git test-git
$ cd test-git

Ang gitweb (commit 1130ef3) ay pinagsama sa git bilang ng commit 0a8f4f0, pagkatapos nito ay hindi
mas matagal na pinananatili nang hiwalay. Ngunit isipin na ito ay pinananatili nang hiwalay, at gusto namin
upang kunin ang mga pagbabago ni git sa gitweb mula noong panahong iyon, upang ibahagi sa upstream. kaya mo
gawin ito:

$ git subtree split --prefix=gitweb --annotate='(split) ' \
0a8f4f0^.. --onto=1130ef3 --rejoin \
--branch gitweb-pinakabago
$ gitk gitweb-pinakabago
$ git push [protektado ng email]:whatever/gitweb.git gitweb-latest:master

(Ginagamit namin 0a8f4f0^.. dahil nangangahulugang "lahat ng mga pagbabago mula 0a8f4f0 hanggang sa kasalukuyan
bersyon, kasama ang 0a8f4f0 mismo.")

Kung ang gitweb ay orihinal na pinagsama gamit ang pumunta subtree idagdag (o nagkaroon ng nakaraang split
tapos na sa --rejoin na tinukoy) pagkatapos ay magagawa mo ang lahat ng iyong mga split nang hindi nagkakaroon
para matandaan ang anumang kakaibang commit id:

$ git subtree split --prefix=gitweb --annotate='(split) ' --rejoin \
--branch gitweb-latest2

At maaari mong pagsamahin ang mga pagbabago pabalik mula sa upstream na proyekto nang kasingdali:

$ git subtree pull --prefix=gitweb \
[protektado ng email]:whatever/gitweb.git master

O, gamit --kalabasa, maaari mong aktwal na i-rewind sa isang mas naunang bersyon ng gitweb:

$ git subtree merge --prefix=gitweb --squash gitweb-latest~10

Pagkatapos ay gumawa ng ilang pagbabago:

$ date >gitweb/myfile
$ git magdagdag ng gitweb/myfile
$ git commit -m 'nilikha ang myfile'

At fast forward muli:

$ git subtree merge --prefix=gitweb --squash gitweb-latest

At mapansin na ang iyong pagbabago ay buo pa rin:

$ ls -l gitweb/myfile

At maaari mo itong hatiin at tingnan ang iyong mga pagbabago kumpara sa karaniwang gitweb:

git log gitweb-latest..$(git subtree split --prefix=gitweb)

Halimbawa 3. MAGBABAGO A SUBTREE GAMIT BRANCH

Ipagpalagay na mayroon kang source directory na may maraming file at subdirectory, at gusto mo
i-extract ang direktoryo ng lib sa sarili nitong git project. Narito ang isang maikling paraan upang gawin ito:

Una, gawin ang bagong repository kung saan mo gusto:

$
$ git init --bare

Bumalik sa iyong orihinal na direktoryo:

$ git subtree split --prefix=lib --annotate="(split)" -b split

Pagkatapos ay itulak ang bagong sangay sa bagong walang laman na imbakan:

$ git push split: master

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