-
1. Pagsisimula
-
2. Mga Pangunahing Kaalaman sa Git
-
3. Pag-branch ng Git
-
4. Git sa Server
- 4.1 Ang Mga Protokol
- 4.2 Pagkuha ng Git sa isang Server
- 4.3 Ang paglikha ng iyong Pampublikong Susi ng SSH
- 4.4 Pag-Setup ng Server
- 4.5 Git Daemon
- 4.6 Smart HTTP
- 4.7 GitWeb
- 4.8 GitLab
- 4.9 Mga Opsyon ng Naka-host sa Third Party
- 4.10 Buod
-
5. Distributed Git
- 5.1 Distributed Workflows
- 5.2 Contributing to a Project
- 5.3 Maintaining a Project
- 5.4 Summary
-
6. GitHub
-
7. Mga Git na Kasangkapan
- 7.1 Pagpipili ng Rebisyon
- 7.2 Staging na Interactive
- 7.3 Pag-stash at Paglilinis
- 7.4 Pag-sign sa Iyong Trabaho
- 7.5 Paghahanap
- 7.6 Pagsulat muli ng Kasaysayan
- 7.7 Ang Reset Demystified
- 7.8 Advanced na Pag-merge
- 7.9 Ang Rerere
- 7.10 Pagdebug gamit ang Git
- 7.11 Mga Submodule
- 7.12 Pagbibigkis
- 7.13 Pagpapalit
- 7.14 Kredensyal na ImbakanCredential Storage
- 7.15 Buod
-
8. Pag-aangkop sa Sariling Pangangailagan ng Git
- 8.1 Kompigurasyon ng Git
- 8.2 Mga Katangian ng Git
- 8.3 Mga Hook ng Git
- 8.4 An Example Git-Enforced Policy
- 8.5 Buod
-
9. Ang Git at iba pang mga Sistema
- 9.1 Git bilang isang Kliyente
- 9.2 Paglilipat sa Git
- 9.3 Buod
-
10. Mga Panloob ng GIT
- 10.1 Plumbing and Porcelain
- 10.2 Git Objects
- 10.3 Git References
- 10.4 Packfiles
- 10.5 Ang Refspec
- 10.6 Transfer Protocols
- 10.7 Pagpapanatili At Pagbalik ng Datos
- 10.8 Mga Variable sa Kapaligiran
- 10.9 Buod
-
A1. Appendix A: Git in Other Environments
- A1.1 Grapikal Interfaces
- A1.2 Git in Visual Studio
- A1.3 Git sa Eclipse
- A1.4 Git in Bash
- A1.5 Git in Zsh
- A1.6 Git sa Powershell
- A1.7 Summary
-
A2. Appendix B: Pag-embed ng Git sa iyong Mga Aplikasyon
- A2.1 Command-line Git
- A2.2 Libgit2
- A2.3 JGit
-
A3. Appendix C: Mga Kautusan ng Git
- A3.1 Setup at Config
- A3.2 Pagkuha at Paglikha ng Mga Proyekto
- A3.3 Pangunahing Snapshotting
- A3.4 Branching at Merging
- A3.5 Pagbabahagi at Pagbabago ng mga Proyekto
- A3.6 Pagsisiyasat at Paghahambing
- A3.7 Debugging
- A3.8 Patching
- A3.9 Email
- A3.10 External Systems
- A3.11 Administration
- A3.12 Pagtutuberong mga Utos
10.5 Mga Panloob ng GIT - Ang Refspec
Ang Refspec
Sa buong aklat na ito, ginamit namin ang simpleng pagmapa mula sa remote na mga branch patungo sa mga lokal na reperensiya, ngunit maaring maging mas komplikado ang mga ito. Ipagpalagay na sumunod ka sa mga huling pares na mga seksyon at nakagawa ng isang maliit na lokal na Git na repositoryo, at ngayon ay nais magdagdag ng remote nito:
$ git remote add origin https://github.com/schacon/simplegit-progit
Ang pagpapatakbo ng utos na nasa ibabaw ay magdaragdag ng seksyon sa .git/config
na file ng iyong repositoryo, na tumutukoy sa pangalan ng remote (origin
), ang URL ng remote na repositoryo, at ang refspec na gagamitin para sa pagkuha:
[remote "origin"]
url = https://github.com/schacon/simplegit-progit
fetch = +refs/heads/*:refs/remotes/origin/*
Ang format ng refspec ay, una, ang opsyonal na {plus}
, sinusundan ng <src>:<dst>
, kung saan ang <src>
ay ang pattern para sa mga reperensiya sa remote na bahagi at <dst>
ay kung saan ang mga reperensiya ay susubaybayan nang lokal.
Ang {plus}
ay nagsasabi sa Git na i-update ang reperensiya kahit na ito ay hindi isang mabilis na pasulong.
Sa default na kaso na awtomatikong isinulat ng isang git remote add
na utos, kinukuha ng Git ang lahat ng mga reperensiya sa ilalim ng mga refs/heads/
sa server at sinusulat ito sa refs/remotes/origin/
nang lokal.
Kaya, kung mayroong isang master na branch sa server, maaari mong ma-access ang log ng branch na iyon nang lokal gamit ang alinman sa mga sumusunod:
$ git log origin/master
$ git log remotes/origin/master
$ git log refs/remotes/origin/master
Lahat ng mga ito ay magkatumbas, sapagkat pinapalawak ng Git ang mga ito sa refs/remotes/origin/master
.
Kung nais mong kunin ng Git ang master
na branch lang sa bawat pagkakataon, at hindi lahat ng ibang mga branch sa remote na server, maari mong baguhin ang linya ng pagkuha upang sumangguni sa branch na iyon lamang:
fetch = +refs/heads/master:refs/remotes/origin/master
Ito ay default lamang na refspec para sa git fetch
para sa remote na iyon.
Kung nais mong gawin ang isang beses lamang na pagkuha, maaari mo ring tukuyin ang partikular na refspec sa command line.
Upang kunin ang master
na branch sa remote patungo sa origin/mymaster
nang lokal, maaring patakbuhin ang:
$ git fetch origin master:refs/remotes/origin/mymaster
Maaring ring magtukoy ng maraming mga refspecs. Sa command line, maaari mong kunin ang ilang mga branch tulad nito:
$ git fetch origin master:refs/remotes/origin/mymaster \
topic:refs/remotes/origin/topic
From git@github.com:schacon/simplegit
! [rejected] master -> origin/mymaster (non fast forward)
* [new branch] topic -> origin/topic
Sa kasong ito, ang master
na branch na pull ay tinanggihan dahil hindi ito nakalista bilang mabilis na pasulong na reperensiya.
Maari mo itong sapawan sa pamamagitan ng pagdagdag ng {plus}
sa unang bahagi ng refspec.
Maaari mo ring tukuyin ang maramihang mga refspec sa iyong configuration file para sa pagkuha.
Kung nais mong palaging kunin ang master
at experiment
na mga branch mula sa origin
na remote, idagdag ang dalawang linya:
[remote "origin"]
url = https://github.com/schacon/simplegit-progit
fetch = +refs/heads/master:refs/remotes/origin/master
fetch = +refs/heads/experiment:refs/remotes/origin/experiment
Hindi mo maaring gamiting ang bahagyang globs sa pattern, kaya’t ito ay hindi wasto:
fetch = +refs/heads/qa*:refs/remotes/origin/qa*
Gayunpaman, maaari mong gamitin ang mga namespace (o mga direktoryo) upang magawa ang isang bagay tulad nito.
Kung mayroon kang koponan ng QA na nagpu-push ng serye ng mga branch, at nais mong kunin ang master
na branch at alinman sa mga branch ng koponan ng QA ngunit wala ng iba, maari mong gamiting ang config na seksyon tulad nito:
[remote "origin"]
url = https://github.com/schacon/simplegit-progit
fetch = +refs/heads/master:refs/remotes/origin/master
fetch = +refs/heads/qa/*:refs/remotes/origin/qa/*
Kung mayroon kang isang kumplikadong proseso ng daloy ng trabaho na may isang koponan ng QA na nagpu-push ng mga branch, mga developer na nagpu-push ng mga branch, at mga koponon ng mga pagsasama-sama na nagpu-push at nakikipagtulungan sa mga remote na branch, maari mo itong i-namespace ng madali sa ganitong paraan.
Pag-push Ng Mga Refspec
Maganda na maaari mong makuha ang mga naka-namespace na mga reperensiya sa ganyang paraan, ngunit paano ba kinukuha ng QA na koponan ang kanilang mga branch sa isang qa/
na namespace sa simula pa lamang?
Maari mong gawin yan sa pamamagitan ng paggamit ng refspecs sa pag-push.
Kung nais ng koponan ng QA na i-push ang master
na branch patungo sa qa/master
sa remote na server, maaring nilang patukbuhin ang
$ git push origin master:refs/heads/qa/master
Kung gusto nila itong awtomatikong patakbuhin ng Git sa tuwing pinapatakbo ang git push origin
, maari silang magdagdag ng push
na halaga sa kanilang config na file:
[remote "origin"]
url = https://github.com/schacon/simplegit-progit
fetch = +refs/heads/*:refs/remotes/origin/*
push = refs/heads/master:refs/heads/qa/master
Sa uulitin, ito ay magiging dahilan na ang git push origin
ay ipu-push ang lokal na master
na branch patungo sa remote na qa/master
na branch nang default.
Pagtanggal Ng Mga Reperensiya
Maari mo ring gamitin ang refspec upang tanggalin ang mga reperensiya mula sa remote na server sa pamamagitan ng pagpapatakbo ng tulad nito:
$ git push origin :topic
Dahil ang refspec ay <src>:<dst>
, sa pamamagitan ng pagtanggal ng <src>
na bahagi, ito ay nagsasabi na gawing ang topic
na branch sa remote na wala, na tinatanggal ito.
O maaari mong gamitin ang mas bagong syntax (magagamit mula sa Git v1.7.0):
$ git push origin --delete topic