-
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
3.5 Pag-branch ng Git - Remote na mga Branch
Remote na mga Branch
Ang remote na mga reperensiya ay mga reperensiya (mga pointer) sa iyong remote na mga repositoryo, na nagsasama ng mga branch, mga tag, at iba pa. Maaari kang tahasang makakuha ng isang buong listahan ng remote na mga reperensya gamit ang git ls-remote [remote], o git remote show [remote] para sa remote na mga branch at marami pang impormasyon. Gayunpaman, isang mas karaniwang paraan ay ang pagsasamantala sa remote-tracking na mga branch.
Ang remote-tracking na mga branch ay mga reperensya sa estado ng remote na mga branch. Sila ay lokal na mga reperensya na hindi mo magagalaw; ginagalaw ng Git ang mga ito para sa iyo sa tuwing ikaw ay gumawa ng anumang network na komunikasyon, upang siguraduhing sila ay tama nagrerepresenta ng estado ng remote na repositoryo. Isipin sila bilang mga bookmark, upang paalalahanan ka kung saan ang mga branch sa iyong remote na mga repositoryo noong huling panahon na ikaw ay nakakonekta sa kanila.
Ang remote-tracking na mga branch ay nag-aanyong <remote>/<branch>. Halimbawa, kung gusto mong tingnan kung ano ang hitsura ng master na branch sa iyong origin na remote noong huling panahon na ikaw ay nakipag-usap nito, susuriin mo ang origin/master na branch. Kung ikaw ay nagtatrabaho sa isang isyu kasama ang isang kasosyo at sila ay nag-push paitaas ng isang iss53 na branch, maaaring mayroon kang sariling lokal na iss53 na branch, ngunit ang branch sa server ay marerepresenta ng remote-tracking na branch na origin/iss53.
Maaaring ito ay medyo nakakalito, kaya tumingin tayo sa isang halimbawa. Sabihin nating mayroon kang isang Git na server sa iyong network sa git.ourcompany.com. Kung ikaw ay magku-clone mula nito, ang clone na utos ng Git ay awtomatikong papangalanan itong origin para sa iyo, ipu-pull nito pababa ang lahat ng datos nito, gagawa ng isang pointer patungo kung saan ang master na branch nito, at lokal itong papangalanang origin/master. Ang Git ay nagbibigay din sa iyo ng iyong sariling lokal na master na branch sa pagsisimula sa parehong lugar bilang master na branch ng origin, kaya mayroon kang bagay na tatrabahuan.
Kutulad ng pangalan ng branch na “master” ay walang espesyal na kahulugan sa Git, pati na ring ang “origin”. Habang ang “master” ay ang default na pangalan para sa isang panimulang branch kapag ikaw ay nagpatakbo ng git init na ang natatanging dahilan kaya ito ay malawakang ginagamit, ang “origin” ay ang default na pangalan para sa isang remote kapag ikaw ay nagpatakbo ng git clone. Kung sa halip ikaw ay nagpatakbo ng git clone -o booyah, ikaw ay magkakaroon ng booyah/master bilang iyong default na remote na branch.
Kung ikaw ay gumawa ng ilang trabaho sa iyong lokal na master na branch, at, sa pansamantala, may ibang nagpu-push sa git.ourcompany.com at nag-update ng master na branch nito, ang iyong mga kasaysayan ay kakaibang ililipat nang pasulong. Gayundin, hangga’t mananatili kang umiwas sa pakikipag-usap sa iyong origin na server, ang iyong origin/master na pointer ay hindi gagalaw.
Upang mapagsabay-sabay ang iyong trabaho, magpapatakbo ka ng isang git fetch origin na utos. Ang utos na ito ay titingnan kung anong server ang “origin” (sa kasong ito, ito ay git.ourcompany.com), ipi-fetch ang anumang datos mula dito na hindi pa nasa iyo, at ia-update ang iyong lokal na database, ililipat ang iyong origin/master na pointer sa bago, mas napapanahon nitong posisyon.
git fetch ay ia-update ang iyong remote na mga reperensyaUpang ipakita ang pagkakaroon ng maramihang remote na mga server at kung ano ang hitsura ng remote na mga branch para sa mga remote na proyekto, ating ipalagay na mayroon kang ibang panloob na Git na server na ginagamit lamang para sa pag-develop ng isa sa iyong mga sprint na mga koponan. Ang server na ito ay nasa git.team1.ourcompany.com. Maaari mong idagdag ito bilang isang panibagong remote na reperensya kung saan mo kasalukuyang tinatrabaho ang git remote add na utos na ating nasakop sa Mga Pangunahing Kaalaman sa Git. Pangalanan itong remote na teamone, na magiging iyong maikling pangalan para sa buong URL na iyon.
Ngayon, maaari mong patakbuhin ang git fetch teamone upang i-fetch ang lahat ng nasa remote na teamone na hindi pa nasa iyo. Dahil ang server na iyon ay may isang subset ng datos na nasa iyong origin na server na ngayon, walang datos na ipi-fetch ang Git ngunit magtatakda ng isang remote-tracking na branch na tinatawag na teamone/master upang tumuro sa commit na mayroon sa teamone bilang master na branch nito.
teamone/master
Pag-push
Kapag gusto mong magbahagi ng isang branch sa mundo, kailangan mong i-push ito pataas sa isang remote na mayroon kang access sa pagsulat. Ang iyong lokal na mga branch ay hindi awtomatikong magkasabay-sabay sa mga remote na susulatan mo — kailangang mong tahasang i-push ang mga branch na gusto mong ibahagi. Sa paraang iyon, maaari kang gumamit ng pribadong mga branch para sa trabahong hindi mo gustong ibahagi, at i-push pataas ang mga paksa na mga branch lamang na gusto mong makipagtulungan.
Kung mayroon kang isang branch na nakapangalang serverfix na gusto mong trabahuin kasama ang iba, maaari mong i-push ito pataas sa parehong paraan na na-push mo ang iyong unang branch. Patakbuhin ang git push <remote> <branch>:
$ git push origin serverfix
Counting objects: 24, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (15/15), done.
Writing objects: 100% (24/24), 1.91 KiB | 0 bytes/s, done.
Total 24 (delta 2), reused 0 (delta 0)
To https://github.com/schacon/simplegit
* [new branch] serverfix -> serverfixIto ay medyo parang isang daang tuwiran. Ang Git ay awtomatikong pinapalaki ang serverfix na pangalan ng branch palabas sa refs/heads/serverfix:refs/heads/serverfix, na nangangahulugang, “Kunin mo ang aking serverfix na lokal na branch at i-push ito upang i-update ang serverfix na branch ng remote.” Dumako tayo sa refs/heads/ na bahagi sa detalye sa Mga Panloob ng GIT, ngunit kadalasan ay maaari mo itong hayaan. Maaari ka ring gumawa ng git push origin serverfix:serverfix, na gumagawa ng parehong bagay — nagsasabi ito na, “Kunin mo ang aking serverfix at gawin itong serverfix ng remote.” Maaari mong gamitin ang format na ito upang mag-push ng isang lokal na branch sa isang remote na branch na kakaibang nakapangalan. Kung hindi mo gustong tawagin itong serverfix sa remote, sa halip ay maaari mong patakbuhin ang git push origin serverfix:awesomebranch upang i-push ang iyong lokal na serverfix na branch patungo sa awesomebranch na branch sa remote na proyekto.
Kung ikaw ay gumagamit ng isang HTTPS na URL upang mag-push paitaas, ang Git na server ay hihingian ka para sa iyong username at password para sa pagpapatunay. Bilang default ito ay mag-uudyok sayo sa terminal para sa impormasyong ito upang mapagpasyahan ng server kung ikaw ay pinapahintulutang mag-push.
Kung hindi mo gustong i-type ito sa bawat isang pagkakataon na magpu-push ka, maaari mong magtakda ng isang “credential cache”. Ang pinakasimple ay ang panatilihin ito sa memorya sa isang maikling minuto, kung saan maaari mong madaling itakda sa pamamagitan ng pagpapatakbo ng git config --global credential.helper cache.
Para sa karagdagang impormasyon sa iba’t ibang mga opsyon ng credential caching na maaaring magamit, tingnan ang Kredensyal na ImbakanCredential Storage.
Sa susunod na panahon na isa sa iyong mga katulong ay mag-fetch mula sa server, sila ay makakatanggap ng isang reperensya kung saan ang bersyon ng server ng serverfix sa ilalim ng remote na branch na origin/serverfix:
$ git fetch origin
remote: Counting objects: 7, done.
remote: Compressing objects: 100% (2/2), done.
remote: Total 3 (delta 0), reused 3 (delta 0)
Unpacking objects: 100% (3/3), done.
From https://github.com/schacon/simplegit
* [new branch] serverfix -> origin/serverfixImportanteng tandaan na kapag ikaw ay gumawa ng isang fetch na humihila pababa ng bagong remote-tracking na mga branch, hindi ka awtomatikong magkakaroon ng lokal, mababagong mga kopya nito. Sa ibang mga salita, sa kasong ito, wala kang isang bagong serverfix na branch — mayroon ka lang isang origin/serverfix na pointer na hindi mo mababago.
Upang ma-merge ang trabahong ito sa iyong kasalukuyang tinatrabahong branch, maaari mong patakbuhin ang git merge origin/serverfix. Kung gusto mong magkaroon ng sariling serverfix na branch kung saan ka pwedeng magtrabaho, maaari kang mag-base nito sa iyong remote-tracking na branch:
$ git checkout -b serverfix origin/serverfix
Branch serverfix set up to track remote branch serverfix from origin.
Switched to a new branch 'serverfix'Ito ay nagbibigay sa iyo ng isang lokal na branch na kung saan maaari kang magtrabaho na nagsisimula kung saan ang origin/serverfix.
Sumusubaybay na mga Branch
Ang pag-check out ng isang lokal na branch mula sa isang remote-tracking na branch ay awtomatikong gumagawa ng kung tawagin ay isang “sumusubaybay branch” (at ang branch na sinusubaybayan ay tinatawag na isang “upstream branch”). Ang sumusubaybay na mga branch ay lokal na mga branch na may isang direktang relasyon sa isang remote na branch. Kung ikaw ay nasa sumusubaybay na branch at magta-type ng git pull, ang Git ay awtomatikong nalalaman kung anong server ang ipi-fetch at branch na imi-merge.
Kapag ikaw ay magko-clone ng isang repositoryo, ito ay kadalasang awtomatikong gumagawa ng isang master na branch na sumusubaybay sa origin/master. Samantala, maaari kang magtalaga ng ibang sumusubaybay na mga branch kung gugustuhin mo — yung mga sumusubaybay ng mga branch sa ibang mga remote, o huwag subaybayan ang master na branch. Ang simpleng kaso ay ang halimbawa na nakita mo kamakailan lamang, ang pagpapatakbo ng git checkout -b <branch> <remote>/<branch>. Ito ay isang karaniwang sapat na operasyon na ibinibigay ng Git ay ang --track na takigrapya:
$ git checkout --track origin/serverfix
Branch serverfix set up to track remote branch serverfix from origin.
Switched to a new branch 'serverfix'Sa katunayan, ito ay sobrang karaniwan na mayroon ding isang takigrapya para sa daang tuwiran na iyon. Kung ang pangalan ng branch na sinusubukan mong i-checkout (a) ay hindi umiiral at ang (b) ay eksaktong tumutugma sa isang pangalan sa isang remote lamang, ang Git ay gagawa ng isang sumusubaybay na branch para sa iyo:
$ git checkout serverfix
Branch serverfix set up to track remote branch serverfix from origin.
Switched to a new branch 'serverfix'Upang magtakda ng isang lokal na branch gamit ang isang naiibang pangalan kaysa sa remote branch, maaaring madali mong magamit ang unang bersyon gamit ang isang naiibang lokal na pangalan ng branch:
$ git checkout -b sf origin/serverfix
Branch sf set up to track remote branch serverfix from origin.
Switched to a new branch 'sf'Ngayon, ang iyong lokal na branch na sf ay awtomatikong magpu-pull mula sa origin/serverfix.
Kung ikaw ay mayroon nang isang lokal na branch at gustong itakda ito sa isang remote na branch na iyong na pull pababa, o gustong baguhin ang upstream na branch na iyong sinusubaybayan, maaari mong gamitin ang -u o --set-upstream-to na opsyon sa git branch upang tahasang itakda ito sa anumang panahon.
$ git branch -u origin/serverfix
Branch serverfix set up to track remote branch serverfix from origin.Kapag mayroon kang isang sumusubaybay na branch na naitakda, maaari mong ireperensya ang upstream na branch nito gamit ang @{upstream} o @{u} na takigrapya. Kaya kung ikaw ay nasa master na branch at ito ay sumusubaybay sa origin/master, maaari kang magsabi ng anuman katulad ng git merge @{u} sa halip ng git merge origin/master kung gugustuhin mo.
Kung gusto mong tingnan kung anong sumusubaybay na mga branch ang naitakda mo, maaari mong gamitin ang -vv na opsyon sa git branch. Ito ay ililista ang iyong lokal na mga branch na may maraming impormasyon na naglalaman ng kung ano ang sinusubaybayan ng bawat branch at kung ang iyong lokal na branch ay nauuna, nahuhuli, o pareho.
$ git branch -vv
iss53 7e424c3 [origin/iss53: ahead 2] forgot the brackets
master 1ae2a45 [origin/master] deploying index fix
* serverfix f8674d9 [teamone/server-fix-good: ahead 3, behind 1] this should do it
testing 5ea463a trying something newKaya dito ay makikita natin ang ating iss53 na branch na sumusubaybay sa origin/iss53 at “nauuna” ng dalawa, nangangahulugang may dalawang commit sa lokal na hindi pa na-push sa server. Maaari rin nating tingnan kung ang ating master na branch ay sumusubaybay sa origin/master at napapanahon. Susunod nakikita natin na ang ating serverfix na branch ay sumusubaybay sa server-fix-good na branch sa ating teamone na server at nauuna ng tatlo at nahuhuli ng isa, nangangahulugan na may isang commit sa server na hindi pa natin na merge at tatlong mga commit na nasa lokal na hindi pa natin na-push. Sa huli makikita natin na ang ating testing na branch ay hindi sumusubaybay ng anumang remote na branch.
Importanteng tandaan na ang mga ito ay numero lamang mula noong huling panahon na nag-fetch ka mula sa bawat server. Ang utos na ito hindi umaabot sa mga server, at sinasabi nito sa iyon ang tungkol sa kung ano ang lokal na na-cache nito mula sa mga server na ito. Kung gusto mong buong napapanahon na nauuna at nahuhuli sa mga numero, kailangan mong mag-fetch mula sa lahat ng iyong mga remote bago mo patakbuhin ito. Maaari mong gawin iyon kagaya nito:
$ git fetch --all; git branch -vvPag-pull
Habang ang git fetch na utos ay magpi-fetch pababa ng lahat ng mga pagbabago sa server na hindi pa nasa iyo, hindi nito babaguhin ang iyong tinatrabaho na direktoryo. Ito ay simpleng kukunin ang data para sa iyo at hahayaan kang i-merge ito. Samantala, mayroong isang utos na tinatawag na git pull na tunay na isang git fetch na kaagad na sinusundan ng isang git merge sa kadalasang kaso. Kung ikaw ay may isang sumusubaybay na branch na nakatakda base sa ipinakita sa huling seksyon, alinman sa pamamagitan ng tahas na pagtakda nito o sa pamamagitan ng paggawa nito para sa iyo gamit ang clone o checkout na utos, ang git pull ay hahanapin kung anong server at branch ang sinusubaybayan ng iyong kasalukuyang branch, mag-fetch mula sa server na iyon at pagkatapos ay susubukang i-merge ang remote na branch na iyon.
Sa pangkalahatan mas mabuti na simpleng gamitin ang fetch at merge na mga utos nang tahasan dahil ang mahika ng git pull ay maaaring nakakalito.
Pagbubura ng Remote na mga Branch
Ipagpalagay na natapos ka na sa isang remote na branch – sabihing ikaw at ang iyong mga katulong ay natapos na sa isang tampok at na-merge ito sa iyong master na branch ng remote (o anumang branch kung saan nandoon ang iyong matatag na codeline). Maaari mong burahin ang isang remote na branch gamit ang --delete na opsyon sa git push. Kung gusto mong burahin ang iyong serverfix na branch mula sa server, patakbuhin mo ang sumusunod:
$ git push origin --delete serverfix
To https://github.com/schacon/simplegit
- [deleted] serverfixTalagang lahat ng ginagawa nito ay magtanggal ng pointer mula sa server. Ang Git na server ay kadalasang pinapanatili ang data doon sa isang saglit hanggang ang isang koleksyon ng basura ay tatakbo, kaya kung ito ay aksidenteng nabura, ito ay kadalasang madaling bawiin.
