-
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
6.2 GitHub - Pag-aambag sa isang Proyekto
Pag-aambag sa isang Proyekto
Ngayon na na-set up na ang ating account, tingnan natin ang ilang mga detalye na maaaring kapaki-pakinabang sa pagtulong sa iyo na mag-ambag sa isang umiiral na proyekto.
Pag-fork ng mga Proyekto
Kung gusto mong mag-ambag sa isang umiiral na proyekto na wala kang access sa pag-push, maaari kang mag-“fork” sa proyekto. Kapag ikaw ay nag-“fork” ng isang proyekto, gagawan ka ng GitHub ng kopya sa proyekto na ganap na sa iyo; ito ay nasa iyong namespace, at maaari kang mag-push dito.
Sa kasaysayan, ang termino na “fork” ay medyo negatibo sa konteksto, ibig sabihin na may kumuha sa isang open-source na proyekto sa isang ibang direksiyon, na minsan ay lumilikha ng pakikipagkumpitensya sa proyekto at paghahati sa mga nag-aambag. Sa GitHub, ang “fork” ay ang parehong proyekto lamang sa iyong sariling namespace, nagbibigay-daan sa iyo na pampublikong gumawa ng mga pagbabago sa isang proyekto bilang isang paraan na mag-ambag sa isang mas bukas na pamamaraan.
Sa paraang ito, hindi na kailangan mag-alala ng mga proyekto tungkol sa pagdagdag ng mga user bilang mga tagatulong na bigyan sila ng access sa pag-push. Maaari mag-force ang mga tao sa isang proyekto, mag-push dito, at mag-ambag sa kanilang mga pagbabago pabalik sa kanilang orihinal na repositoryo sa pamamagitan ng paglilikha ng tinatawag na Kahilingan na Pull, na ating itatalakay sa susunod. Ito ay nagbubukas ng isang thread ng diskusyon sa pagsusuri ng code, at ang may-ari at nag-aambag ay maaari makikipag-usap tungkol sa pagbabago hanggang ang may-ari ay masaya dito, kung saan ang may-ari ay maaaring pagsamahin ito.
Para ma-fork ang isang proyekto, bisitahin ang pahina ng proyekto at i-click ang pindutan na “Fork” na nasa kanang itaas ng pahina.
Pagkatapos ng ilang segundo, dadalhin ka sa pahina ng iyong bagong proyekto, na may sariling kopya ng code na maaaring mabago.
Ang Daloy ng GitHub
Ang GitHub ay dinisenyo sa paligid ng isang partikular na workflow sa pakikipagtulungan, nakasentro sa mga Kahilingan na Pull. Ang daloy na ito ay gumagana kung nakikipagtulungan ka sa isang mahigpit na pangkat sa isang solong ibinahaging repositoryo, o isang kompanyang ibinahagi sa mundo o network ng mga estranghero na nag-aambag sa isang proyekto sa pamamagitan ng dose-dosenang mga fork. Ito ay nakasentro sa workflow na Paksa na mga Branch na tinalakay sa Pag-branch ng Git.
Narito kung paano ito gumagana:
-
I-fork ang proyekto
-
Lumikha ng isang branch ng paksa mula sa
master. -
Gumawa ng ilang commits upang mapabuti ang proyekto.
-
I-push ang branch na ito sa iyong proyekto sa GitHub.
-
Magbukas ng isang Kahilingan na Pull sa GitHub.
-
Talakayin, at opsyonal na patuloy na gumawa.
-
Pagsasamahin o isasara ng may-ari ng proyekto ang Kahilingan na Pull.
Ito ang karaniwan na workflow ng Tagapamahala ng Paglagom na tinalakay sa Integration-Manager Workflow, ngunit sa halip na gagamit ng email sa pakikipag-ugnayan at pagsusuri ng mga pagbabago, ang pangkat ay gumagamit ng mga kagamitan ng GitHub na nakabatay sa web.
Talakayin natin ang isang halimbawa ng pagpapanukala ng pagbabago sa isang open-source na proyekto na naka-host sa GitHub gamit ang daloy na ito.
Paglilikha ng isang Kahilingan na Pull
Naghahanap ng code si Tony na tatakbo sa kanyang Arduino programmable microcontroller at nakatagpo ng isang mahusay na file ng programa sa GitHub sa https://github.com/schacon/blink.
Ang tanging problema ay ang masyadong mabilis ang kumukurap na rate, sa tingin namin ito ay mas mahusay na maghintay ng 3 segundo sa halip ng 1 sa pagitan ng bawat pagbabago ng estado. Kaya ating pabutihin ang programa at isumite ito pabalik sa proyekto bilang isang iminungkahing pagbabago.
Una, ating i-click ang pindutan na Fork tulad ng nabanggit kanina upang makuha ang ating sariling kopya ng proyekto.
Ang pangalan ng gumagamit dito ay “tonychacon” kaya ang kopya ng ating proyekto ay nasa https://github.com/tonychacon/blink at diyan natin maaaring mabago ito.
Atin itong lokal na i-clone, lumikha ng isang branch ng paksa, gumawa ng pagbabago sa code at sa wakas ay i-push ang pagbabago na iyon pabalik sa GitHub.
$ git clone https://github.com/tonychacon/blink (1)
Nagko-clone sa 'blink'...
$ cd blink
$ git checkout -b slow-blink (2)
Lumipat sa isang bagong branch na 'slow-blink'
$ sed -i '' 's/1000/3000/' blink.ino (macOS) (3)
# Kung ikaw ay nasa isang sistema na Linux, gawin ito sa halip:
# $ sed -i 's/1000/3000/' blink.ino (3)
$ git diff --word-diff (4)
diff --git a/blink.ino b/blink.ino
index 15b9911..a6cc5a5 100644
--- a/blink.ino
+++ b/blink.ino
@@ -18,7 +18,7 @@ void setup() {
// ang loop na gawain ay tumatakbo nang paulit-ulit magpakailanman:
void loop() {
digitalWrite(led, HIGH); // i-on ang LED (HIGH ay ang antas ng boltahe)
[-delay(1000);-]{+delay(3000);+} // maghintay ng isang segundo
digitalWrite(led, LOW); // i-off ang LED sa pamamagitan ng paggawa ng boltahe sa LOW
[-delay(1000);-]{+delay(3000);+} // maghintay ng isang segundo
}
$ git commit -a -m 'mas mahusay ang tatlong segundo' (5)
[slow-blink 5ca509d] mas mahusay ang tatlong segundo
1 file ang nabago, 2 pagsisingit(+), 2 pagtatanggal(-)
$ git push origin slow-blink (6)
Username para sa 'https://github.com': tonychacon
Password para sa 'https://tonychacon@github.com':
Pagbibilang ng mga bagay: 5, tapos na.
Delta compression na gumagamit ng hanggang 8 threads.
Nagko-compress ng mga bagay: 100% (3/3), tapos na.
Nagsusulat ng mga bagay: 100% (3/3), 340 bytes | 0 bytes/s, tapos na.
Kabuuan 3 (delta 1), muling nagamit 0 (delta 0)
Sa https://github.com/tonychacon/blink
* [new branch] slow-blink -> slow-blink-
I-clone nang pa-lokal ang ating fork sa proyekto
-
Lumikha ng isang mapaglarawang branch ng paksa
-
Gawin ang ating pagbabago sa code
-
Suriin na ang pagbabago ay mabuti
-
I-commit ang ating pagbabago sa branch ng paksa
-
I-push ang ating bagong branch ng paksa pabalik sa ating fork sa GitHub
Ngayon kung tayo ay babalik sa ating fork sa GitHub, makikita natin na napansin ng GitHub na tayo ay nag-push ng isang bagong branch ng paksa at nagtatanghal sa atin ng isang malaking berdeng pindutan upang suriin ang ating mga pagbabago at magbukas ng isang Kahilingan na Pull sa orihinal na proyekto.
Maaari kang pumunta sa pahina ng “Branches” sa https://github.com/<user>/<project>/branches upang hanapin ang iyong branch at magbukas ng isang bagong Kahilingan na Pull mula doon.
Kung i-click natin ang berdeng pindutan na iyon, makikita natin ang isang screen na nagtatanong sa atin na magbigay ng titulo at paglalarawan sa ating Kahilingan na Pull. Ito ay halos palaging kapaki-pakibanang na maglagay ng ilang pagsisikap dito, dahil ang isang mahusay na paglalarawan ay nakakatulong sa may-ari ng orihinal na proyekto na matukoy ang anumang sinubukan mong gawin, kung ang iminungkahing pagbabago ay tama, o kung ang pagtatanggap ng mga pagbabago ay makakabuti sa orihinal na proyekto.
Nakikita rin natin ang isang listahan ng mga gumawa sa ating branch ng paksa na “ahead” sa ating branch na master (sa kasong ito, isa lamang) at ang isang pinag-isang diff sa lahat ng mga pagbabago na gagawin kung dapat bang ang branch na ito ay isama ng may-ari ng proyekto.
Kapag pinindot mo ang pindutan na Lumikha ng kahilingan na pull, ang may-ari ng proyekto na iyong na-fork ay makakakuha ng abiso na may nagmumungkahi ng isang pagbabago at magli-link sa isang pahina kung saan naroon ang lahat ng mga impormasyon na ito.
Kahit ang mga Kahilingan na Pull ay pangkaraniwan na ginamit para sa mga pampublikong proyekto kagaya nito kung saan ang nag-aambag ay mayroong kumpletong pagbabago na handang gawin, ito rin ay madalas na ginamit sa mga panloob na mga proyekto sa simula ng cycle ng development. Dahil maaari kang patuloy na mag-push sa branch ng paksa kahit pagkatapos na nabuksan ang Kahilingan na Pull, ito’y madalas na nakabukas nang maaga at ginamit bilang isang paraan upang ulitin ang paggawa bilang isang pangkat sa loob ng konteksto, sa halip na buksan sa kaduluhan ng proseso.
Pag-uulit sa Kahilingan na Pull
Sa puntong ito, ang may-ari ng proyekto ay maaari tumingin sa iminungkahing pagbabago at pagsamahin ito, tanggihan ito o magkomento dito. Sabihin natin na hindi niya gusto ang ideya, ngunit mas gusto ng isang bahagyang mas mahabang oras para sa liwanag na i-off kaysa i-on.
Kung saan ang pag-uusap na ito ay maaaring maganap sa email sa workflow na ipinakita sa << _distributed_git >>, sa GitHub nangyayari ito online. Maaaring suriin ng may-ari ng proyekto ang pinag-isang diff at mag-iwan ng komento sa pamamagitan ng pag-click sa alinman sa mga linya.
Kapag ang tagapangasiwa ay gumagawa ng komentong ito, ang taong nagbukas ng Kahilingan na Pull (at sa katunayan, ang sinumang iba pa na nanonood sa repositoryo) ay makakakuha ng isang abiso. Susubukan nating baguhin ang pagpapasadya na ito sa ibang pagkakataon, ngunit kung mayroon siyang mga abiso sa email na naka-on, makakakuha si Tony ng isang email na katulad nito:
Sinuman ay maaari ring mag-iwan ng mga pangkalahatang komento sa Kahilingan na Pull. Sa Pahina ng Talakayan ng Kahilingan na Pull, maaari nating makita na ang may-ari ng proyekto ay kapwa nagkokomento sa isang linya ng code at pagkatapos ay nag-iiwan ng pangkalahatang komento sa seksyon ng talakayan. Maaari mong makita na ang mga komento ng code ay dinala na rin sa pag-uusap.
Ngayon ang nag-aambag ay maaaring makakita kung ano ang kanilang kailangang gawin upang makakuha ng mga natanggap na pagbabago. Sa kabutihang-palad ito ay napakatuwiran. Kung saan sa email, maaaring kailangan mong muling igulong ang iyong mga serye at muling isumite ito sa listahan ng mga mail, sa GitHub i-commit mo lamang ulit sa branch ng paksa at i-push, kung saan ay awtomatikong na-update sa Kahilingan na Pull. Sa Panghuling Kahilingan na Pull maaari mo ring makita ang komento sa lumang code ay nabagsak sa nabagong Kahiligan na Pull, dahil ito ay nagawa sa isang linya na nabago na.
Pagdaragdag ng mga commit sa umiiral na Kahilingan na Pull ay hindi nag-trigger ng abiso, kaya sa sandaling mag-push si Tony ng mga pagtatama, nagdedesisyon siya na mag-iwan ng komento upang ipaalam sa may-ari ng proyekto na siya ay gumawa ng hiniling na pagbabago.
Isang nakawiwiling bagay na mapapansin ay kung nag-click ka sa tab ng “Nabagong mga File” sa Kahilingan na Pull na ito, makakakuha ka ng “unified” diff — iyon ang kabuuang pinagsama-samang pagkakaiba na ipapakilala sa iyong pangunahing branch kapag ang paksang ito ay pinagsama. Sa mga termino ng git diff, ito talaga ay awtomatikong nagpapakita sa iyo ng git diff master... para sa branch kung saan nakabatay ang Kahilingan na Pull na ito. Tingnan sa Determining What Is Introduced para sa karagdagang uri ng diff na ito.
Ang ibang bagay na iyong mapapansin ay ang pagsusuri ng GitHub kung ang Kahilingan na Pull ay nasama nang malinis at nagbibigay ng isang pindutan na gagawa ng pagsama para sa iyo sa server. Ang pindutan na ito ay nakikita lamang kung ikaw ay may access sa pagsulat sa repositoryo at ang isang walang halaga na pagsasama ay posible. Kung i-click mo ito, magsasagawa ang GitHub ng isang pagsasama na “non-fast-forward”, ibig sabihin na kahit ang pagsasama ay maaari na isang fast-forward, ito ay lilikha pa rin ng isang commit na pagsamahin.
Kung naisin mo, maari mo lamamg i-pull ang branch at lokal na isama ito. Kapag isama mo ang branch na ito sa branch na master branch at i-push ito sa GitHub, awtomatikong masasara ang Kahilingan na Pull.
Ito ang pinagbabatayang workflow na ginagamit ng karamihan sa mga proyekto ng GitHub. Ang mga branch ng paksa ay nalikha, mga Kahilingan na Pull ay nabuksan sa kanila, isang talakayin ang naganap, posibleng mas maraming trabaho ang ginagawa sa branch at sa huli ang kahilingan ay sarado o pinagsama.
Mahalaga na tandaan na maaari ka ring magbukas ng isang Kahilingan na Pull sa pagitan ng dalawang branch sa parehong repositoryo. Kung ikaw ay nagtatrabaho sa isang tampok at pareho kayong may access sa pagsulat sa proyekto, maaari kang mag-push ng branch ng paksa repositoryo at magbukas ng isang Kahilingan na Pull dito sa branch na master sa parehong proyekto na iyon upang masimulan ang pagsusuri sa review at proseso ng talakayin. Walang kinakailangang pag-fork.
Mga Advanced na Kahilingan na Pull
Ngayon na ating natalakay ang mga pangunahing kaalaman sa pag-aambag sa isang proyekto sa GitHub, talakayin natin ang ilang mga kagiliw-giliw na tip at kaalaman tungkol sa mga Kahilingan na Pull upang ikaw ay mas magiging epektibo sa paggamit nito.
Mga Kahilangan na Pull bilang mga Patch
Mahalagang maintindihan na maraming mga proyekto ang hindi talaga nag-iisip ng Kahilangan na Pull bilang mga queue ng perpektong mga patch na dapat ilapat nang malinis sa pagkakasunud-sunod, tulad ng karamihan sa mga proyekto nakabatay sa listahan ng mail na iniisip ang mga kontribusyon ng serye ng patch. Iniisip ng karamihan sa mga proyekto ng GitHub ang mga branch ng Kahilingan na Pull bilang umuulit na pag-uusap sa paligid ng isang ipinanukalang pagbabago, nagtatapos sa isang pinag-isang diff na inilalapat sa pamamagitan ng pagsasama.
Ito ay isang mahalagang pagkakaiba, dahil sa pangkalahatan, ang pagbabago ay iminungkahi bago ang code ay naisip na maging perpekto, na kung saan ay malayong mas bihira sa mga listahan ng mail na nakabatay sa patch serye ng mga kontribusyon. Ito ay nagbibigay-daan sa isang mas maagang pag-uusap sa mga tagapagpanatili upang ang pagdating sa tamang solusyon ay higit pa sa pagsisikap ng komunidad. Kung ang code ay iminungkahi sa isang Kahilingan na Pull at mga tagapagpanatili o komunidad ay nagmumungkahi ng pagbabago, ang mga serye ng patch ay pangkalahatang hindi nagulong muli, ngunit sa halip ang pagkakaiba ay na-psu bilang isang bagong commit sa branch, na inililipat ang pag-uusap nang pasulong sa konteksto ng nakaraang trabaho na buo.
Halimbawa, kung babalikan mo at tingnang muli sa Panghuling Kahilingan na Pull, mapapansin mo na ang nag-aambagag ay hindi nag-rebase sa kanyang commit at nagpadala ng ibang Kahilingan na Pull. Sa halip ay nagdagdag sila ng mga bagong commit at nag-push sila sa umiiiral na branch. Sa paraang ito kung ikaw ay babalik at titingin sa Kahilingan na Pull na ito sa hinaharap, madali mong mahanap ang lahat ng konteksto kung bakit ang mga desisyon ay nagawa. Pasadyang pagpindot sa “Merge” na pindutan sa site ay naglilikha ng isang commit na pagsasama na nagsasangguni sa Kahilingan na Pull upang madaling bumalik at magsaliksik sa orihinal na pag-uusap kung kinakailangan.
Pagpapanatili sa Upstream
Kung ang Kahilingan na Pull ay nagiging luma o hindi malinas na naisama, gugustuhin mong ayusin ito upaang ang tagapanatili ay madali makapagsama dito. Susuriin ito ng GitHub para sa iyo at ipapaalam sa iyo sa ibaba ng bawat Kahilingan na Pull kung ang pagsasama ay walang halaga o hindi.
Kung nakakita ka ng isang bagay tulad ng Hindi malinis na nasama ang Kahilingan na Pull, gugustuhin mong ayusin ang iyong branch upang ito ay nagiging berde at ang tagapagpanatili ay hindi kailangang gumawa ng dagdag na trabaho.
Mayroon kang dalawang pangunahing mga opsyon upang magawa ito. Maaari mong i-rebase ang iyong branch sa itaas ng anumang ang branch na target (karaniwan ang branch na master repositoryo na iyong na-fork), o maaari mong isama ang branch na target sa iyong branch.
Pipiliin ng karamihan sa mga developer sa GitHub na gawin ang paghuli, para sa parehong dahilan na ating tinalakay sa nakaraang seksyon. Ang mahalaga ay ang kasaysayan at ang panghuling merge, kaya ang pag-rebase ay hindi nagkukuha sa iyo ng marami maliban sa isang bahagyang mas malinis na kasaysayan at sa pagbabalik ay malayo na mas mahirap at madaling kapitan ng error.
Kung gusto mong mag-merge sa branch ng target upang magawa mong maaari i-merge ang iyong Kahilingan na Pull,idadagdag mo ang orihinal na repositoryo bilang isang bagong remote, mag-fetch mula dito, mag-merge ng pangunahing branch ng repositoryo na iyon sa iyong branch ng paksa, mag-ayos ng anumang mga isyo at panghuli ay i-push ito sa parehong branch kung saan mo binuksan ang Kahilingan na Pull.
Halimbawa, sabihin natin na sa halimbawa na “tonychacon” na ginamit natin dati, ang orihinal na may-akda ay gumawa ng pagbabago na maaari maglikha ng salungatan sa Kahilingan na Pull. Puntahan natin ang mga hakbang na iyon.
$ git remote add upstream https://github.com/schacon/blink (1)
$ git fetch upstream (2)
remote: Nagbibilang ng mga bagay: 3, tapos na.
remote: Nagko-compress ng mga bagay: 100% (3/3), tapos na.
Nag-a-unpack ng mga bagay: 100% (3/3), tapos na.
remote: Kabuuan 3 (delta 0), muling nagamit 0 (delta 0)
Mula sa https://github.com/schacon/blink
* [new branch] master -> upstream/master
$ git merge upstream/master (3)
Auto-merging blink.ino
SALUNGANTAN (nilalaman): Salungatan sa merge sa blink.ino
Nabigo ang awtomating merge; ayusin ang mga salungatan at pagkatapos i-commit ang resulta.
$ vim blink.ino (4)
$ git add blink.ino
$ git commit
[slow-blink 3c8d735] Merge remote-tracking branch 'upstream/master' \
sa slower-blink
$ git push origin slow-blink (5)
Nagbibilang ng mga bagay: 6, tapos na.
Delta compression gumagamit hanggang 8 threads.
Nagko-compress ng mga bagay: 100% (6/6), tapos na.
Nagsusulat ng mga bagay: 100% (6/6), 682 bytes | 0 bytes/s, tapos na.
Kabuuan 6 (delta 2), muling nagamit 0 (delta 0)
Sa https://github.com/tonychacon/blink
ef4725c..3c8d735 slower-blink -> slow-blink-
Idagdag ang orihinal na repositoryo bilang isang remote na pinangalanang “upstream”
-
Kunin ang pinakabagong trabaho mula sa remote na iyon
-
I-merge ang pangunahing branch sa repositoryo na iyon sa iyong branch ng paksa
-
Ayusin ang nangyaring salungatan
-
I-push pabalik sa parehong branch ng paksa
Kapag ginawa mo iyon, ang Kahilingan na Pull ay awtomatikong mai-update at muling susuriin upang makita kung na-merge ito nang malinis.
Isa sa mga magagandang bagay tungkol sa Git ay maaari mong patuloy na gawin iyon. Kung mayroon kang isang napakatagal na proyekto, madali mong ma-merge mula sa branch ng target nang paulit-ulit at kailangan lamang makitungo sa mga salungatan na nangyari mula noong huli na ikaw ay nag-merge, ginagawa ang proseso na napapamahalaan.
Kung talagang gusto mong i-rebase ang branch upang malinis ito, maaari mong tiyak na gawin ito, ngunit ito ay lubos na hinihikayat na huwag piliting mag-push sa branch na ang Kahilingan na Pull ay binuksan na. Kung ang ibang tao ay naka-pull na dito at nakagawa ng mas maraming trabaho, mararanasan mo ang lahat ng isyo na nakabalangkas sa Ang mga Panganib ng Pag-rebase. Sa halip, i-push ang branch na naka-rebase sa isang bagong branch sa GitHub at magbukas ng isang bagong Kahilingan na Pull na tumutukoy sa luma, pagkatapos ay isara ang orihinal.
Mga Reperensiya
Ang iyong susunod na tanong ay maaaring “Paano ko ireperensiya ang lumang Kahilingan na Pull?”. Lumilitaw na mayroong maraming, maraming mga paraan upang magamit ang iba pang mga bagay halos kahit saan maaari kang sumulat sa GitHub.
Simulan natin kung paano magtukoy ng ibang Kahilingan na Pull o isang Isyu. Lahat ng mga Kahilingan na Pull at mga Isyu ay mga nakatalagang numero at ito ay natatangi sa proyekto. Halimbawa, hindi ka maaaring magkaroon ng Kahilingan na Pull #3 at Isyu #3. Kung gusto mong magreperensiya ng anumang Kahilingan na Pull o Isyu mula sa iba pa, maaari mo lamang ilagay ang #<num> sa anumang komento o paglalarawan. Maaari ka ring maging mas tiyak kung ang Isyu o ang Kahilingan na Pull ay nabubuhay sa ibang lugar; sumulat ng username#<num> kung ikaw ay nagtutukoy ng isang Isyu o Kahilingan na Pull sa isang fork ng repositoryo kung ikaw ay nasaan, o username/repo#<num> upang ireperensiya ang ilang bagay sa ibang repositoryo.
Tingnan natin ang isang halimbawa. Sabihing ating na-rebase ang branch sa nakaraang halimbawa, naglikha ng isang bagong kahilingan na pull para rito, at ngayon gusto natin na ireperensiya ang lumang kahilingan na pull mula sa bago. Gusto din natin na ireperensiya ang isang isyu sa fork ng repositoryo at isyu sa ganap na naiibang proyekto. Maaari nating punan ang paglalarawan kagaya ng Mga Pagtukoy sa isang Kahilingan na Pull..
Kapag tayo ay nagsumite ng kahilingan na pull na ito, makikita natin ang lahat ng mga naibigay tulad ng Mga pagtukoy na naibigay sa isang Kahilingan na Pull..
Pansinin na ang buong URL ng GitHub na ating nilagay doon ay pinaikli sa kailangan lamang na impormasyon.
Ngayon kung babalik si Tony at isasara ang orihinal na Kahilingan na Pull, maaari nating makita na sa pagbabanggit nito sa isang bago, awtomatikong nilikha ng GitHub ang isang trackback event sa timeline ng Kahilingan na Pull. Ito ay nangangahulugan na sinuman ang bibisita sa Kahilingan na Pull na ito at makakakita na ito ay naisara ay maaaring madaling maka-link pabalik sa pumalit nito. Magiging tulad ng I-link pabalik sa bagong Kahilingan na Pull sa nakasarang timeline ng Kahilingan na Pull. ang link.
Bilang karagdagan sa mga numero ng isyu, maaari ka ring magreperensiya ng isang tiyak na commit sa pamamagitan ng SHA-1. Kailangan mong magtukoy ng isang buong 40 karakter na SHA-1, ngunit kung nakikita ito ng GitHub sa komento, ito ay mali-link direkta sa commit. Muli, maaari mong ireperensiya ang mga commit sa mga force o ibang mga repositoryo sa parehong paraan na iyong ginawa sa mga isyu.
Pinalasang Markdown ng GitHub
Ang pag-link sa ibang mga Isyu ay simula lamang ng kawili-wiling mga bagay na maaari mong magawa sa halos anumang kahon ng teksto sa GitHub. Sa mga paglalarawan ng Isyu at Kahilingan na Pull, mga komento, mga komento ng code at marami pa, maaari kang gumamit ng tinatawag na “Pinalasang Markdown ng GitHub”. Ang markdown ay katulad ng pagsusulat sa isang payak na teksto ngunit ibinigay ng mas sagana..
Tingnan ang Isang halimbawa ng Pinalasang Markdown ng GitHub na nakasulat at nagawa. para sa isang halimbawa kung paano masusulat ang mga komento at teksto at pagkatapos ay gawin gamit ang Markdown.
Ang timpla ng Markdown ng GitHub ay nagdadagdag ng mas maraming bagay na maaari mong gawin lampas sa pangunahing Markdown syntax. Ang mga ito ay maaaring magagamit kapag naglilikha ng kapaki-pakinabang na Kahilingan na Pull o mga komento o paglalarawan ng Isyu.
Mga Listahan ng Gawain
Ang una talagang kapaki-pakinabang na tampok ng Markdown na tiyak sa GitHub, lalo na para sa gamit sa mga Kahilingan na Pull, Listahan ng Gawain. Ang listahan ng gawain ay isang listahan ng mga checkbox ng mga bagay na gusto mong tapusin. Paglalagay sa mga ito sa isang Isyu o Kahilingan na Pull ay karaniwang nagpapahiwatig ng mga bagay na gusto mong matapos bago mo isaalang-alang ang mga kompletong aytem.
Maaari kang lumikha ng isang listahan ng gawain kagaya nito:
- [X] Isulat ang code
- [ ] Isulat lahat ang mga pasulit
- [ ] Idokumento ang codeKung ating isasama ang mga ito sa paglalarawan ng ating Kahilingan na Pull o Isyu, makikita natin ito na ginawa tulad ng Mga listahan ng gawain na nagawa sa isang komento ng Markdown.
Ito ay kadalasan ginamit sa mga Kahilingan na pull upang ipahiwatig kung ano ang lahat na gusto mong tapusin sa branch bago maging handang i-merge ang Kahilingan na Pull. Ang talagang magandang bahagi ay maaari kang mag-click lamang sa mga checkbox upang ma-update ang komento — hindi mo na kailangan na baguhin nang direkta ang Markdown upang masuri ang mga gawain.
Ano pa, hahanapin ng GitHub ang mga listahan ng gawain sa iyong mga Isyu at Kahilingan na Pull at ipakita ang mga ito bilang metadata sa mga pahina na naglilista sa kanila. Halimbawa, kung mayroon kang Kahilingan na Pull sa mga gawain at titingnan mo ang pahina ng pangkalahatang-ideya ng lahat ng Kahilingan na Pull, maaari mong makita kung gaano kalayo ang ginawa nito. Tinutulungan nito ang mga tao na iwaksi ang Kahilingan na Pull sa mga subtask at tulungan ang ibang tao na subaybayan ang pag-unlad ng branch. Makikita mo ang halimbawa nito sa Buod ng listahan ng gawain sa listahan ng Kahilingan na Pull..
Ang mga ito ay hindi kapani-paniwala na kapaki-pakinabang kapag binuksan mo ang isang Kahilingan na Pull nang maaga at gamitin ito upang subaybayan ang iyong pag-unlad sa pamamagitan ng pagpapatupad ng mga tampok.
Mga Code Snippet
Maaari ka ring magdagdag ng mga code snippet sa mga komento. Ito ay lalong kapaki-pakinabang kung nais mong ipakita ang isang bagay na maaari mong subukan na gawin bago aktwal na ipatupad ito bilang isang commit sa iyong branch. Ito ay kadalasang ginagamit upang magdagdag ng halimbawa ng code kung ano ang hindi gumagana o kung ano ang maaaring ipatupad ng Kahilingan na Pull.
Upang magdagdag ng isang snippet sa code, kailangan mong i-“fence” ito sa mga backtick.
```java
for(int i=0 ; i < 5 ; i++)
{
System.out.println("i ay : " + i);
}
```Kung nagdagdag ka ng isang pangalan ng wika tulad ng ginawa natin doon sa java, susubukan din ng GitHub na i-highlight ang syntax ng snippet. Sa kaso sa itaas na halimbawa, ito ay matatapos sa paggawa tulad ng Halimbawa ng naka-render fenced code..
Pag-quote
Kung tumutugon ka sa isang maliit na bahagi ng isang mahabang komento, maaari kang pumiling mag-quote ng iba pang komento sa pamamagitan ng nauna sa mga linya kasama ang > na karakter. Sa katunayan, ito ay karaniwan at kapaki-pakinabang na may shortcut sa keyboard para dito. Kung iyong i-highlight ang teksto sa isang komento na nais mong direktang tumugon at pindutin ang r key, ito ay mag-quote sa teksto na iyon sa kahon ng komento para sa iyo.
Ang mga quote ay magiging tulad nito:
> Kahit na ito'y Nobler sa isip na magdusa
> Ang mga Sling at Arrow ng mapangahas na Kapalaran,
Gaano kalaki ang mga sling na ito at sa partikular, ang mga arrow na ito?Kapag nagawa, ang komento ay magiging tulad ng Halimbawa ng nagawang pag-quote..
Emoji
Sa wakas, maaari ka ring gumamit ng emoji sa iyong mga komento. Talagang ginagamit ito nang lubos sa mga komento na nakikita mo sa maraming mga isyu ng GitHub at mga Kahilingan na Pull. Mayroon ding isang emoji helper sa GitHub. Kung nagta-type ka ng komento at nagsimula ka ng isang : na karakter, tutulungan ka ng autocompleter na makita kung ano ang iyong hinahanap.
Ang Emojis ay kumukuha sa form ng :<name>: saanman sa komento. Halimbawa, maaari kang magsulat ng ilang bagay tulad nito:
Ako ay :eyes: sa :bug: at ako'y :cold_sweat:.
:trophy: para :microscope: ito.
:+1: at :sparkles: sa :ship: na ito, ito'y :fire::poop:!
:clap::tada::panda_face:Kapag nagawa, ito ay magiging tulad ng Mabibigay na pagkokomento na emoji..
Hindi sa ito ay hindi kapani-paniwala kapaki-pakinabang, ngunit ito ay nagdaragdag ng isang elemento ng kasiyahan at damdamin sa isang daluyan na kung hindi man ay mahirap upang ihatid ang damdamin.
Mayroon talagang maraming bilang ng mga serbisyo ng web na gumagamit sa mga araw na ito ng mga karakter na emoji. Isang magaling na sheet ng panlilinlang na magamit upang mahanap ang emoji na nagpapahayag kung ano ang gusto mong sabihin ay matatagpuan sa:
Mga Larawan
Hindi ito Pinalasang Markdown ng GitHub, ngunit ito ay lubhang kapaki-pakinabang. Bilang karagdagan sa pagdaragdag ng mga link ng larawan ng Markdown sa mga komento, na maaaring magin mahirap na mahanap at para ma-embed ang mga URL, ang GitHub ay nagpapahintulot sa iyo na i-drag at ihulog ang mga larawan sa mga text area upang ma-embed ang mga ito.
Kung titingnan mo sa I-drag at ihulog ang mga larawan upang ma-upload ito at auto-embed ang mga ito., maaari kang makakita ng maliit na hint na “Naka-parse bilang Markdown” sa itaas ng text area. Pag-click doon ay magbibigay sa iyo ng buong sheet ng panlilinlang sa lahat na maaari mong gawin sa Markdown ng GitHub.
