-
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 -> serverfix
Ito 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/serverfix
Importanteng 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 new
Kaya 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 -vv
Pag-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] serverfix
Talagang 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.