-
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.3 GitHub - Pagpapanatili ng isang Proyekto
Pagpapanatili ng isang Proyekto
Ngayon na kumportable tayong nag-aambag sa isang proyekto, tingnan natin ang kabilang panig: paglikha, pagpapanatili at pangangasiwa ng iyong sariling proyekto.
Paglilikha ng isang Bagong Repositoryo
Lumikha ng isang bagong repositoryo upang maibahagi ang ating code ng proyekto.
Simulan sa pamamagitan ng pag-click sa pindutan na “Bagong Repositoryo” sa kanang bahagi ng dashboard, o mula sa pindutan na +
sa itaas na toolbar kasunod sa iyong usernmame gaya ng nakikita sa Ang dropdown na “Bagong repositoryo”..
Ito ay nagdadala sa iyo sa form ng “bagong repositoryo”:
Ang kailangan mo lang gawin dito ay magbigay ng isang pangalan ng proyekto; ang lahat ng mga patlang ay ganap na opsyonal.
Sa ngayon, i-click lamang ang pindutan na “Lumikha ng Repositoryo” - mayroon kang isang bagong repositoryo sa GitHub, pinangalanang <user>/<project_name>
.
Dahil wala kang code doon, ipapakita sa iyo ng GitHub ang mga tagubilin kung paano lumikha ng isang bagong tatak ng repositoryo ng Git, o ikonekta ang isang umiiral na proyekto ng Git. Hindi namin balabaan ito dito; kung kailangan mo ng refresher, i-check out ang Mga Pangunahing Kaalaman sa Git.
Ngayon na naka-host na ang iyong proyekto sa GitHub, maaari kang magbigay ng URL sa sinuman na gusto mong bahagian ng iyong proyekto.
Bawat proyekto sa GitHub ay maaaring i-access sa HTTPS bilang https://github.com/<user>/<project_name>
, at sa SSH bilang git@github.com:<user>/<project_name>
.
Maaaring mag-fetch ang Git mula sa at mag-push sa parehong mga URL na ito, ngunit sila ay kontrolado ng access batay sa mga kredensyal ng gumagamit na kumukonekto dito.
Madalas na lalong kanais-nais na ibahagi ang URL na nakabatay sa HTTPS para sa isang pampublikong proyekto, dahil ang gumagamit ay hindi kailangang magkaroon ng isang account sa GitHub upang ma-access ito para sa pag-clone. Ang mga gumagamit ay magkakaroon ng isang account at isang na-upload na SSH key upang ma-access ang iyong proyekto kung binibigyan mo sila ng SSH URL. Ang HTTPS ay isa ring eksaktong parehong URL na kanilang idikit sa isang browser upang tingnan ang proyekto doon.
Pagdaragdag ng mga Tagapangasiwa
Kung ikaw ay nagtatrabaho kasama ang ibang tao na nais mong bigyan ng access sa pag-commit, kailangan mong idagdag sila bilang “tagapangasiwa”. Kung si Ben, Jeff, and Louise ay nag-sign up ng mga account sa GitHub, at gusto mo silang bigyan ng access sa pag-push sa iyong repositoryo, maaari mo silang idagdag sa iyong proyekto. Ang paggawa nito ay nagbibigay sa kanila ng access sa “push”, na nangangahulugan na mayroon silang access sa pagbasa at pagsulat sa proyekto at repositoryo ng Git.
I-click ang link ng “Settings” sa ibaba ng kanang sidebar.
Pagkatapos piliin ang =“Tagapangasiwa” mula sa menu sa kaliwang bahagi. Pagkatapos, magtipa ng username sa kahon, at i-click ang “Magdagdag ng tagapangasiwa.” Maaari mong ulitin ito nang maraming beses hangga’t gusto mo upang magbigay ng access sa lahat ng iyong gusto Kung kailangan mong bawiin ang access, i-click lamang ang ‘` X '’ sa kanang bahagi ng kanilang hilera.
Pamamahala ng mga Kahilingan na Pull
Ngayon na mayroon kang isang proyekto na may ilang mga code at marahil kahit na ilang mga tagapangasiwa na mayroon ding access sa push, talakayin natin kung ano ang gagawin kapag kumuha ka ng isang Kahilingan na Pull sa iyong sarili.
Ang Kahilingan na Pull ay maaaring mula sa isang branch sa isang fork ng iyong repositoryo o sila ay maaari mula sa ibang branch sa parehong repositoryo. Ang tanging kaibahan ay ang mga nasa isang fork ay madalas mula sa mga tao kung saan hindi ka maaaring mag-push sa kanilang branch at hindi nila maaaring mag-push sa iyo, samantalang ang panloob na Kahilingan na Pull ay maaaring ma-access ng parehong partido sa branch.
Para sa mga halimbawang ito, ating ipalagay na ikaw ay “tonychacon” at naglikha ka ng isang bagong proyekto na Arduino code na pinangalanang “fade”.
Mga Abiso sa Email
May nagsasama at gumagawa ng pagbabago sa iyong code at nagpapadala sa iyo ng Kahilingan na Pull. Dapat kang makakuha ng email na nag-aabiso sa iyo tungkol sa bagong Kahilingan na Pull at dapat itong magmukhang tulad ng Abiso sa email ng isang bagong Kahilingan na Pull..
Mayroong ilang mga bagay na napapansin tungkol sa email na ito. Ito ay magbibigay sa iyo ng isang maliit na diffstat - isang listahan ng mga file na nagbago sa Kahilingan na Pull at kung gaano. Nagbibigay ito sa iyo ng isang link sa Kahilingan na Pull sa GitHub. Nagbibigay din ito sa iyo ng ilang mga URL na maaari mong gamitin mula sa command line.
Kung mapapansin mo ang linya na nagsasabing git pull <url> patch-1
, ito ay isang simpleng paraan upang pagsamahin sa isang remote branch nang hindi na kinakailangang magdagdag ng isang remote.
Tinalakay natin ito nang mabilis sa Checking Out Remote Branches.
Kung naisin mo, maaari kang lumikha at lumipat sa isang branch ng paksa at pagkatapos ay patakbuhin ang utos na ito upang magsama sa mga pagbabago sa Kahilingan na Pull.
Ang iba pang mga kagiliw-giliw na mga URL ay ang mga URL na .diff
at` .patch`, na kung saan ay maaari mong hulaan, magbigay ng pinag-isang diff at patch na bersyon ng Kahilingan na Pull.
Maaari mong pagsamahin sa trabaho ng Kahilingan na Pull sa isang bagay na tulad nito:
$ curl http://github.com/tonychacon/fade/pull/1.patch | git am
Pangangasiwa sa Kahilingan na Pull
Sa natalakay sa Ang Daloy ng GitHub, maaari ka na ngayong magkaroon ng pag-uusap sa taong nagbukas ng Kahilingan na Pull. Maaari kang magkomento sa mga tiyak na linya ng code, magkomento sa buong commit o magkomento sa buong Kahilingan na Pull mismo, gamit ang GitHub Flavored Markdown saanman.
Sa tuwing may ibang komento sa Kahilingan na Pull patuloy kang makakakuha ng mga abiso sa email upang malaman mo na may nangyayaring aktibidad. Ang bawat isa ay may isang link sa Kahilingan na Pull kung saan ang aktibidad ay nangyayari at maaari mo ring direktang tumugon sa email upang magkomento sa thread ng Kahilingan na Pull.
Sa sandaling ang code ay nasa isang lugar na gusto mo at nais na pagsamahin ito, maaari mong i-pull ang code pababa at pagsamahin ito nang lokal, alinman sa git pull <url> <branch>
syntax na nakita natin kanina, o sa pamamagitan ng pagdaragdag ng fork bilang isang remote at pagkuha at pagsasama.
Kung ang pagsama-sama ay walang halaga, maaari mo ring pindutin ang pindutan na “Merge” sa site ng GitHub. Ito ay gagawa ng isang pagsama-sama na “non-fast-forward”, na naglilikha ng isang merge commit kahit na ang merge na naka-fast-forward ay posible. Nangangahulugan ito na kung anuman, sa bawat oras na pindutin mo ang pindutan ng merge, isang merge commit ay nilikha. Sa makikita mo sa Pindutan na merge at mga tagubilin sa manu-manong pagsama-sama ng isang Kahilingan na Pull., binibigay sa iyo ng GitHub ang lahat na impormasyong ito kung i-click mo ang link ng implikasyon.
Kung nagpasya kang hindi mo nais na pagsamahin ito, maaari mo ring isara ang Kahilingan na Pull at aabisuhan ang taong nagbukas nito.
Refs ng Kahilingan na Pull
Kung ikaw ay nakikitungo sa isang maraming mga Kahilingan na Pull at hindi nais na magdagdag ng isang bungkos ng mga remote o gumawa ng isang beses na mga pull sa bawat oras, may isang malinis na trick na pinapahintulutan ng GitHub na gawin mo. Ito ay isang konting advanced na trick at tatalakayin natin ang mga detalye nito sa Ang Refspec, ngunit ito ay maaaring kapaki-pakinabang.
Ang GitHub ay tunay na nag-aanunsiyo ng mga branch ng Kahilingan na Pull para sa isang repositoryo bilang uri ng mga pseudo-branch sa server. Bilang default hindi mo makuha ang mga ito kapag ikaw ay nag-clone, ngunit doon sila sa isang nakakubling paraan at maaari mong madaling ma-access ang mga ito.
Upang ipakita ito, gagamitin namin ang isang mababang antas na utos (madalas na tinutukoy bilang isang utos na “plumbing”, kung saan babasahin natin ang tungkol dito nang higit pa sa Plumbing and Porcelain) na tinawag na ls-remote
.
Ang utos na ito ay karaniwang hindi ginagamit sa pang-araw-araw na pagpapatakbo ng Git ngunit ito ay kapaki-pakinabang upang ipakita sa atin kung anong mga reperensiya ang naroroon sa server.
Kung papatakbuhin natin ang utos na ito laban sa repositoryo na “blink” na ating ginamit natin kanina, makakakuha tayo ng listahan sa lahat ng mga branch at mga tag at ibang mga reperensiya sa repositoryo.
$ git ls-remote https://github.com/schacon/blink
10d539600d86723087810ec636870a504f4fee4d HEAD
10d539600d86723087810ec636870a504f4fee4d refs/heads/master
6a83107c62950be9453aac297bb0193fd743cd6e refs/pull/1/head
afe83c2d1a70674c9505cc1d8b7d380d5e076ed3 refs/pull/1/merge
3c8d735ee16296c242be7a9742ebfbc2665adec1 refs/pull/2/head
15c9f4f80973a2758462ab2066b6ad9fe8dcf03d refs/pull/2/merge
a5a7751a33b7e86c5e9bb07b26001bb17d775d1a refs/pull/4/head
31a45fc257e8433c8d8804e3e848cf61c9d3166c refs/pull/4/merge
Siyempre, kung ikaw ay nasa iyong repositoryo at nagpapatakbo ka ng git ls-remote origin
o anumang remote na nais mong suriin, ipapakita nito sa iyo ang isang bagay na katulad nito.
Kung ang repositoryo ay nasa GitHub at mayroon kang anumang mga Kahilingan na Pull na nabuksan, makakakuha ng mga reperensiyang ito na naka-prefix ng refs/pull/
.
Ang mga ito ay talagang mga branch, ngunit dahil ang mga ito ay wala sa ilalim ng refs/heads/
hindi mo makuha ang mga ito nang normal kapag nag-clone ka o kumukuha mula sa server - ang proseso ng pagkuha ay hindi pinapansin ang mga ito nang normal.
Mayroong dalawang reperensiya sa bawat Kahilingan na Pull - ang isang na nagtatapos sa mga punto na /head
sa estaktong parehong commit bilang huling commit sa branch ng Kahilingan na Pull.
Kaya kung may isang nagbubukas ng Kahilingan na Pull sa ating repositoryo at ang kanilang branch ay pinangalanang bug-fix
at ito ay nakaturo sa commit na a5a775
, kung gayon sa ating repositoryo, wala tayong branch na bug-fix
(dahil iyon ay nasa kanilang fork), nganit tayo ay magkakaroon ng pull/<pr#>/head
na nakatuturo sa a5a775
.
Ito ay nangangahulugan na madali nating ma-pull ang bawat branch ng Kahilingan na Pull sa isang beses nang walang kinakailangang pagdagdag ng isang bungkos ng mga remote.
Ngayon, maaari mong gawin ang isang bagay tulad ng pagkuha ng direktang reperensiya.
$ git fetch origin refs/pull/958/head
From https://github.com/libgit2/libgit2
* branch refs/pull/958/head -> FETCH_HEAD
Ito ay nagsasabi sa Git, “Kumonekta sa remote na origin
, at i-download ang ref na pinangalanang refs/pull/958/head
.”
Masayang sinusunod ng Git, at nagda-download ng lahat na kinakailangan mo sa pagbuo ng ref na iyon, at naglalagay ng isang pointer sa commit na gusto mo sa ilalim ng .git/FETCH_HEAD
.
Maaari mong sundan iyon ng git merge FETCH_HEAD
sa branch na gusto mong suriin, ngunit ang mensahe ng merge commit ay magiging mukhang kakaiba.
Gayundin, kung sinusuri mo ang maraming mga kahilingan na pull, ito ay nakakapagod.
Mayroon ding paraan upang ma-fetch ang lahat na mga kahilangan na pull, at nagsisigurado na ang mga ito ay laging bago sa tuwing ikaw ay kumukonekta sa remote.
Buksan ang .git/config
sa iyong paboritong editor, at hanapin ang remote na origin
.
Dapat magiging magmukhang ganito:
[remote "origin"]
url = https://github.com/libgit2/libgit2
fetch = +refs/heads/*:refs/remotes/origin/*
Ang linyang iyon na nagsisimula sa fetch =
ay isang “refspec.”
Ito’y isang paraan ng pagmamapa ng mga pangalan sa remote sa mga pangalan sa iyong lokal na direktoryo na .git
.
Ang partikular na ito ay nagsasabi sa Git, "ang mga bagay sa remote na nasa ilalim ng refs/heads
ay dapat mapunta sa aking lokal na repositoryo sa ilalim ng refs/remotes/origin
."
Maaari mong mabago ang seksiyon na ito upang magdagdag ng iba pang refspec:
[remote "origin"]
url = https://github.com/libgit2/libgit2.git
fetch = +refs/heads/*:refs/remotes/origin/*
fetch = +refs/pull/*/head:refs/remotes/origin/pr/*
Ang linyang iyon ay nagsasabi sa Git, “Lahat ng mga ref na nagmumukhang refs/pull/123/head
ay dapat nakaimbak nang lokal kagaya ng refs/remotes/origin/pr/123
.”
Ngayon, kung ikaw ay nag-save ng file na iyon, at gumawa ng isang git fetch
:
$ git fetch
# …
* [new ref] refs/pull/1/head -> origin/pr/1
* [new ref] refs/pull/2/head -> origin/pr/2
* [new ref] refs/pull/4/head -> origin/pr/4
# …
Ngayon lahat ng mga kahilingan na pull na naka-remote ay kinakatawan nang lokal na may mga ref na kumilos tulad ng pagsubaybay sa mga branch; ang mga ito ay read-only, at ito ay na-update kapag gumawa ka ng isang fetch. Ginagawang napakadali nitong magsubok ng code mula sa isang kahilingan na pull ng pa-lokal:
$ git checkout pr/2
Nag-check out ng mga file: 100% (3769/3769), tapos na.
Branch pr/2 nag-set up upang sumaybay sa remote branch pr/2 mula sa origin.
Pinalit sa isang bagong branch na 'pr/2'
Tatandaan ng nakamatang-agila sa inyo ang head
sa huli ng remote na bahagi ng refspec.
Mayroon ding ref na refs/pull/#/merge
sa panig ng GitHub , na kumakatawan sa commit na magiging resulta kung i-push mo ang pindutan na “merge” sa site.
Ito ay nagpapahintulot sa iyo na suriin ang merge bago pindutin ang pindutan.
Mga Kahilingan na Pull sa mga Kahilingan na Pull
Hindi ka lamang magbubukas ng mga Kahilingan na Pull na naka-target sa prinsipal o branch na master
, maaari ka talagang magbukas ng isang Kahilingan na Pull na nagta-target sa anumang branch sa network.
Sa katunayan, maaari ka ring mag-target sa ibang Kahilingan na Pull.
Kung nakikita mo ang isang Kahilingan na Pull na gumagalaw sa tamang direksyon at mayroon kang ideya para sa isang pagbabago na nakadepende dito o hindi ka sigurado na magandang ideya, o wala ka lamang access sa pag-push sa branch ng target, maaari kang magbukas ng isang Kahilingan na Pull na direkta dito.
Kapag ikaw ay pumunta upang bumukas ng isang Kahilingan na Pull, may isang kahon sa itaas ng pahina na tumutukoy kung aling branch ang hinihingan mo na maka-pull at kung saan hinihiling mo na mag-pull. Kung pinindot mo ang “Edit” na pindutan sa kanan ng kahon na iyon, maaari kang magbago hindi lamang sa mga branch kundi rin sa kung anong fork.
Dito maaari kang medyo madaling magtukoy upang pagsamahin ang iyong bagong branch sa ibang Kahilingan na Pull o ibang fork ng proyekto.
Mga Pagbanggit at mga Abiso
Mayroon ding magandang built in na sistema ng mga abiso ang GitHub na magagamit kapag ikaw ay may mga tanong o kailangan na katugunan mula sa tiyak na mga indibidwal o koponan.
Sa anumang komento maaari mong simulan sa pagtitipa ng karakter na @
at ito ay magsisimula sa awtomatikong matapos kasabay ng mga pangalan at username ng tao na mga tagatulong o nag-aambag sa proyekto.
Maaari ka ring magbanggit ng isang gumagamit na wala sa dropdown, ngunit kadalasang maaaring mapabilis ng autocompleter.
Sa sandaling magpaskil ka ng komento sa isang pagbanggit ng user, aabisuhan ang user na iyon. Nangangahulugan ito na ito ay maaaring maging isang tunay na epektibong paraan ng paghawak ng mga tao sa mga pag-uusap sa halip na paggawa ng mga ito ng poll. Kadalasan sa mga Kahilingan na Pull sa mga tao sa GitHub ay magpu-pull ng iba pang mga tao sa kanilang mga koponan o sa kanilang kompanya upang magsuri ng isang Isyu o Kahilingan na Pull.
Kung may isang tao ang nakuhang nabanggit sa isang Kahilingan na Pull o Isyu, sila ay magiging “naka-subscribe” nito at patuloy na makakakuha ng mga abiso sa anumang oras na nangyayari ang aktibidad nito. Ma-subscribe ka rin sa isang bagay kung binuksan mo ito, kung nanonood ka sa repositoryo o kung ikaw ay nagkomento ka sa isang bagay. Kung hindi mo na nais na makatanggap ng mga abiso, may isang pindutan na “Unsubscribe” sa pahina na maaari mong i-click upang ihinto ang pagtanggap ng mga pagbabago nito.
Ang Pahina ng mga Abiso
Kapag kami ay nagbanggit ng mga “abiso” na may kinalaman sa GitHub, ibig naming sabihin ang isang tiyak na paraan na sinisikap ng GitHub na makipag-ugnay sa iyo kapag nangyayari ang mga kaganapan at may ilang iba’t-ibang mga paraan na maaari mong isaayos ang mga ito. Kung pupunta sa sa tab na “Sentro ng Abiso” mula sa pahina ng settings, makikita mo ang ilan sa mga opsyon na mayroon ka.
May dalawang pagpipilian na makakakuha ka ng mga abiso sa “Email” at sa “Web” at maaari kang pumili sa alinman, wala o pareho para sa kapag aktibong kang lumahok sa mga bagay at para sa aktibidad sa mga repositoryo na iyong pinapanood.
Mga Abiso ng Web
Ang mga Abiso ng Web ay umiiral lamang sa GitHub at maaari mo itong suriin sa GitHub lamang. Kung pinili mo ang opsyon na ito sa iyong kagustuhan at isang abiso ay na-trigger para iyo, makikita mo ang isang maliit na asul na tuldok sa iyong icon ng mga abiso sa itaas ng iyong screen gaya ng nakikita sa Sentro ng Abiso..
Kung nag-click ka doon, makikita mo ang isang listahan ng lahat ng mga aytem na ikaw ay naabisuhan, nakagrupo sa pamamagitan ng proyekto. Maaari kang mag-filter sa mga abiso ng partikular na proyekto sa pamamagitan ng pag-click sa pangalan nito sa kanang sidebar. Maaari mo ring kilalanin ang abiso sa pamamagitan ng pag-click sa checkmark icon na kasunod sa anumang abiso, o kilalanin ang lahat ng mga abiso sa isang proyekto sa pamamagitan ng pag-click sa checkmark na nasa itaas ng grupo. Mayroon din isang pindutan na mute kasunod sa bawat checkmark na maaari mong i-click upang hindi makatanggap ng anumang mga abiso sa aytem na iyon.
Lahat ng mga kasangkapan na ito ay kapaki-pakinabang sa pangangasiwa ng malaking bilang ng mga abiso. Karamihan sa mga makapangyarihang gumagamit ng GitHub ay nag-off lamang ng mga abiso sa email sa kabuuan at namamahala ng kanilang mga abiso sa pamamagitan ng screen na ito.
Mga Abiso sa Email
Ang mga abiso sa Email ay ang ibang paraan na mapangasiwaan mo ang mga abiso sa GitHub. Kung ini-off mo ito makakakuha ka ng mga email sa bawat abiso. Nakikita natin ang mga halimbawa nito sa Mga komento naipadala bilang mga abiso sa email at Abiso sa email ng isang bagong Kahilingan na Pull.. Ang mga email ay ma-thread din nang mabuti, na maganda kung ika’y gumagamit ng isang kliyente ng pag-thread ng email.
Mayroon ding isang makatarungang dami ng metadata na naka-embed sa mga header ng mga email na ipinadala sa iyo ng GitHub, na maaaring maging kapaki-pakinabang para sa pag-set up ng mga pasadyang filter at patakaran.
Halimbawa, kung titingnan natin ang aktwal na mga header ng email na pinadala kay Tony sa email na ipinapakita sa Abiso sa email ng isang bagong Kahilingan na Pull., makikita natin ang mga sumusunod kabilang sa naipadalang impormasyon:
Para: tonychacon/fade <fade@noreply.github.com>
ID-ng-Mensahe: <tonychacon/fade/pull/1@github.com>
Paksa: [fade] Maghintay ng mas matagal upang makita ang mas mahusay na epekto ng pag-dim (#1)
X-GitHub-Tumatanggap: tonychacon
ID-ng-Listahan: tonychacon/fade <fade.tonychacon.github.com>
Listahan-ng-Archive: https://github.com/tonychacon/fade
Listahan-ng-Paskil: <mailto:reply+i-4XXX@reply.github.com>
Listahan-ng-Unsubscribe: <mailto:unsub+i-XXX@reply.github.com>,...
X-GitHub-Address-ng-Tumatanggap: tchacon@example.com
Mayroong ilang mga kawili-wiling bagay dito.
Kung gusto mong i-highlight o i-rutang muli ang mga email sa partikular na proyektong ito o kahit ang Kahilingan na Pull, ang impormasyon sa ID-ng-Mensahe
ay nagbibigay sa iyo ng lahat ng datos sa format na <user>/<project>/<type>/<id>
.
Kung ito isang isyu, bilang halimbawa, ang patlang na <uri>
sana ay naging mga “isyu” sa halip na “pull”.
Ang mga patlang na Listahan-ng-Paskil
at Listahan-ng-Unsubscribe
ay nangangahulugan na kung mayroon kang kliyente ng mail na umiintindi sa mga iyon, madali mong mapaskil sa listahan o “Unsubscribe” mula sa thread.
Iyon ay mahalagang kapareho a pag-click sa pindutan na “mute” sa bersyon sa web ng abiso o “Unsubscribe” sa pahina mismo ng Isyu o Kahilingan na Pull.
Makabuluhan ding tandaan na kung pareho kang mayroong mga abiso sa email at web na pinagana at nabasa mo ang bersyon sa email ng abiso, ang bersyon sa web ay mamarkahan bilang nabasa pati na rin kung ikaw ay mayroon mga larawan na pinayagan sa iyong kliyente ng mail.
Mga Espesyal na File
Mayroong ilang mga espesyal na file na mapapansin ng GitHub kung naroon sila sa iyong repositoryo.
README
Ang una ay ang file na README
, na maaaring maging halos sa anumang format na nakikilala ng GitHub bilang prosa.
Halimbawa, maaari itong maging README
, README.md
, README.asciidoc
, atbp.
Kung nakikita ng GitHub ang isang file ng README sa iyong source, ito ay magbibigay nito sa pahina ng paglapag ng proyekto.
Marami sa mga kopona ang gumagamit sa file na ito upang hawakan ang lahat ng may kaugnay na impormasyon ng proyekto para sa isang tao na maaaring bago sa repositoryo o proyekto. Kasama sa pangkalahatang ito ang mga bagay na tulad nito:
-
Para saan ang proyektong ito
-
Paano isaayos at i-install ito
-
Isang halimbawa ng kung paano ito gamitin o makuha itong patakbuhin
-
Ang lisensya na ibinibigay sa ilalim ng proyekto
-
Paano mag-ambag dito
Dahil ang GitHub ay magre-render ng file na ito, maaari mong i-embed ang mga larawan o mga link sa mga ito para sa dagdag na kadalian ng pag-unawa.
PAG-AAMBAG
Ang iba pang espesyal na file na kinikilala ng GitHub ay ang file na PAG-AAMBAG
.
Kung mayroon kang file na pinangalanang PAG-AAMBAG
na may anumang palugit ng file, ipapakita ng GitHub ang Pagbubukas ng isang Kahilingan na Pull kapag umiiral ang isang file na PAG-AAMBAG. kapag sinuman ay nagsisimula sa pagbubukas ng isang Kahilingan na Pull.
Ang ideya dito ay maaari mong tukuyin ang mga partikular na bagay na gusto mo o ayaw mo sa isang Kahilingan na Pull na ipinadala sa iyong proyekto. Sa ganitong paraan maaaring basahin ng mga tao ang mga patnubay bago buksan ang Kahilingan na Pull.
Pangangasiwa sa Proyekto
Sa pangkalahatan ay hindi maraming mga bagay na pang-administratibo na magagawa mo sa isang proyekto, ngunit may ilang mga bagay na maaaring maging interesado.
Pagbabago sa Default Branch
Kung gumagamit ka ng isang branch maliban sa “master” bilang default branch na gusto mong doon magbukas ng Kahilingan na Pull ang mga tao o makikita bilang default, maaari mong baguhin iyon sa pahina ng settings ng iyong repositoryo sa ilalim ng tab na ‘Mga Opsyon’'.
Baguhin lamang ang default na branch sa dropdown at iyon ang magiging default para sa lahat ng mga pangunahing pagpapatakbo mula doon, kabilang kung aling branch ang naka-check out bilang default kapag may nag-clone sa repositoryo.
Paglilipat ng isang Proyekto
Kung nais mong maglipat ng isang proyekto sa ibang gumagamit o isang organisasyon sa GitHub, mayroong opsyon na ‘Paglipat ng Pagmamay-ari’' sa ilalim ng parehong tab na “Mga Opsyon” ng pahina ng settings ng iyong repositoryo na nagpapahintulot sa iyong gawin ito.
Ito ay makakatulong kung ikaw ay lilisan sa isang proyekto at may gustong pumalit nito, o kung lumalaki na ang iyong proyekto at gusto na ilipat ito sa isang organisasyon.
Hindi lamang inililipat nito ang repositoryo kasama ang lahat ng mga tagamasid at mga star sa ibang lugar, itinatakda din nito ang isang pag-redirect mula sa iyong URL sa bagong lugar. I-redirect din nito ang mga pag-clone at pagkuha mula sa Git, hindi lamang mga kahilingan sa web.