Sa buong aklat ipinakilala namin ang dose-dosenang mga kautusan ng Git at sinubukang ipakilala ang mga ito sa pamamagitan ng pagsalaysay, dahan-dahang magdagdag ng maraming mga kautusan sa kuwento. Gayunpaman, ito ay nagbigay sa amin ng mga halimbawa sa paggamit ng mga kautusan na medyo watak-watak sa buong aklat.
Sa apendiks na ito, tayo ay dadaan sa lahat ng mga kautusan ng Git na binanggit natin sa buong aklat, na pinagsama ayon sa paggamit nito. Pag-uusapan natin ang bawat kautusan kung ano sa pangkalahatan ang ginagawa nito at pagkatapos ay ipapakita kung saan sa aklat mahahanap ang paggamit nito.
Mayroong dalawang mga kautusan na madalas ginagamit, mula sa unang mga tawag ng Git hanggang sa karaniwang araw-araw na pag-aayos at sanggunian, ang config at help na mga kautusan.
Ang Git ay may default na paraan sa paggawa ng daan-daang mga bagay. Karamihan ng mga bagay na ito ay maaari kang magpahayag sa Git na gamitin ang default o di kaya gawin ang mga ito sa ibang paraan, o itakda ang iyong mga kagustuhan. Ito ay nagsasangkot ng lahat mula sa pagsasabi sa Git kung ano ang pangalan mo hanggang sa mga partikular na kagustuhan sa kulay ng terminal o kung ano ang iyong ginamit na editor. Maraming mga file ang babasahin at isusulat ng kautusang ito para ikaw ay makatakda ng pangkalahatang halaga o pababa sa partikular na mga repositoryo.
Ang kautusang git config ay ginamit sa halos bawat kabanata ng aklat.
Sa _getting_started.asc ginamit namin ito upang tukuyin ang aming pangalan, email address at napiling editor bago pa namin simulan ang paggamit ng Git.
Sa _git_basics_chapter.asc ipinakita namin kung paano mo magagamit ito upang lumikha ng pinaikling mga kautusan at lumalawak sa mahabang mga pagkakasunud-sunod ng pagpipilian upang hindi mo kailangang i-type ang mga ito nang paulit-ulit.
Sa _git_branching.asc ginamit namin ito upang maging --rebase ang default kapag nagpatakbo ka ng git pull.
Sa _git_tools.asc ginamit namin ito upang mag-set up ng isang default na imbakan para sa iyong mga HTTP password.
Sa _customizing_git.asc ipinakita namin kung paano i-set up mga mantsa at malinis na salaan sa nilalaman na papasok at palabas ng Git.
Sa katapusan, halos ang kabuuan ng [_git_config] ay nilaan para sa kautusan.
Ang kautusan na git help ay ginagamit upang ipakita sa iyo ang lahat ng dokumentasyon na naipadala sa Git tungkol sa anumang kautusan. Habang nagbibigay kami ng kaunting pangkalahatang-ideya sa karamihan sa mga mas sikat na kautusan sa apendiks na ito, para sa buong listahan sa lahat ng mga posibleng pagpipilian at mga flag para sa bawat kautusan, maaari mong laging patakbuhin ang git help <command>.
Ipinakilala namin ang kautusang git help sa [_git_help] at ipinakita sa iyo kung paano gamitin ito upang makahanap ng karagdagang impormasyon tungkol sa git shell sa _git_on_the_server.asc.
Mayroong dalawang mga paraan upang makakuha ng repositoryong Git. Ang isa ay kopyahin ito mula sa isang umiiral na repositoryo sa network o sa ibang lugar at ang pangalawa ay upang lumikha ng isang bagong umiiral na direktoryo.
Para kumuha ng isang direktoryo at maging bagong repositoryong Git sa gayon maaari mong simulan ang bersyon sa pagkontrol nito, maaari mo lamang patakbuhin ang git init.
Una naming ipakilala ito sa _git_basics_chapter.asc, kung saan ipinapakita namin ang paglikha ng isang bagong repositoryo para masimulan mong pagtrabahoan.
Natalakay namin ng maikli tungkol sa kung paano mo palitan ang default na branch mula sa ``master'' sa _git_branching.asc.
Ginagamit namin ang command na ito upang lumikha ng repositoryo na walang laman para sa isang server sa _git_on_the_server.asc.
Sa katapusan, dumako tayo sa ilang mga detalye na kung ano talaga ang ginagawa nito sa likod ng mga eksena sa _git_internals.asc.
Ang git clone na kautusan ay isang bagay na nakabalot sa paligid ng maraming iba pang mga kautusan.
Ito ay nakakalikha ng bagong direktoryo, ito ay papasok sa loob at pinatatakbo ng git init upang gawing walang lamang repositoryong Git, magdagdag ng remote (git remote add) sa URL na ipinasa mo nito (bilang default na pinangalanang origin), pinatatakbo ang git fetch mula riyan sa remote na repositoryo at pagkatapos i-checkout ang pinakabagong ginawa sa iyong gumaganang direktoryo sa pamamagitan ng git checkout.
Ang git clone na kautusan ay ginamit sa dose-dosenang mga dako sa buong libro, ngunit maglilista lang kami ng ilang mga interesanteng mga dako.
Ito ay karaniwang ipinakilala at ipinaliwanag sa _git_basics_chapter.asc, kung saan nagbigay kami ng ilang mga halimbawa.
Sa _git_on_the_server.asc tinitingnan natin sa pamamagitan ng --bare na opsyon upang lumikha ng isang kopya ng repositoryong Git na walang gumaganang direktoryo.
Sa _git_tools.asc ginagamit namin ito upang hindi bigkisin isang nakabigkis na repositoryong Git.
Sa katapusan, sa _git_tools.asc natutunan natin ang --recurse-submodules na opsyon upang gumawa ng pag-kopya ng isang repositoryo kasama ang submodules na bahagyang pinasimple.
Kahit na ito ay ginagamit sa iba pang mga dako ng libro, isa ito sa mga medyo natatangi o kung saan ito ay ginagamit sa bahagyang naiibang mga paraan.
Para sa mga pangunahing proseso ng trabaho sa pag-aayos ng nilalaman at pag-commit nito sa iyong kasaysayan, mayroon lamang ilang mga pangunahing kautusan.
Ang git add na kautusan ay nagdadagdag ng nilalaman mula sa gumaganang direktoryo patungo sa lugar ng pag-stage (o `index'') para sa susunod na pag-commit.
Kapag ang kautusan ng `git commit ay gumana, bilang default tinitingnan lamang nito ang lugar ng pag-stage, kaya ang git add ay ginagamit upang gawing eksakto kung ano ang nais mong anyo sa susunod na pag-commit ng snapshot.
Ang kautusan na ito ay sobrang mahalagang utos sa Git at nabanggit o ginamit ng maraming beses sa aklat na ito. Mabilis naming isasali ang mga dipangkaraniwang mga paggamit nito na maaring makita.
Una naming ipinakilala at ipaliwanag ang git add nang detalyado sa _git_basics_chapter.asc.
Binabanggit namin kung paano gamitin ito upang malutas ang pagsasalungat sa pagsasama sa _git_branching.asc.
Natalakay din namin ang paggamit nito sa pag-stage lamang ng mga tukoy na bahagi ng isang nabagong file sa << _ git_tools # _interactive_staging >>.
Sa panghuli, kokopyahin namin ito sa isang mababang antas sa _git_internals.asc, kaya makakakuha ka ng ideya kung ano ang ginagawa nito sa likod ng mga eksena.
Sa git status na kautusan ipapakita sa iyo ng ang iba’t ibang mga estado ng mga file sa iyong gumaganang direktoryo at sa lugar ng staging.
Alin sa mga file ang binago at unstaged at kung saan ang mga na staged ngunit hindi pa na commit.
Sa normal na anyo nito, ipapakita rin nito sa iyo ang ilang mga pangunahing pahiwatig kung paano maglipat ng mga file sa pagitan ng mga stage.
Una nating na pag-usapang ang status sa << _ git_basics_chapter # _checking_status >>, kapwa ang mga batayan at pinadaling mga form nito.
Habang ginagamit namin ito sa buong libro, halos lahat ng iyong magagawa sa git status na utos ay sakop doon.
Ang kautusang git diff ay ginagamit kapag nais mong makita ang mga pagkakaiba sa pagitan ng dalawang trees.
Ito ay maaaring pagkakaiba sa pagitan ng iyong gumaganang environment at ang iyong staging na lugar (git diff mismo), sa pagitan ng iyong staging na lugar at ang iyong huling commit (git diff --staged), o sa pagitan ng dalawang mga commit (`git diff master branchB `).
Una naming natalakay ang mga pangunahing paggamit ng git diff sa << _ git_basics_chapter # _git_diff_staged >>, kung saan ipinapakita namin kung paano makita kung ano ang mga pagbabago sa staged at kung ano ang hindi pa na staged.
Ginagamit namin ito upang tumingin para sa posibleng mga isyu sa whitespace bago gumawa ng - check na opsyon sa << _ distributed_git # _commit_guidelines >>.
Nakita namin kung paano masuri ang mga pagkakaiba sa pagitan ng mga branch nang mas epektibo sa git diff A … B syntax sa << _ distributed_git # _what_is_introduced >>.
Ginagamit namin ito upang i-filter ang mga pagkakaiba sa whitespace sa -b at kung paano ihambing ang iba’t ibang yugto ng mga magkakasalungat ng mga file gamit ang` --theirs`, --ours at` --base` sa << _ git_tools # _advanced_merging >>.
Sa panghuli, ginagamit namin ito upang epektibong ihambing ang mga pagbabago sa submodule sa --submodule sa << _ git_tools # _starting_submodules >>.
Ang git difftool na kautusan ay naglulunsad lamang ng isang panlabas na kasangkapan upang ipakita sa iyo ang pagkakaiba sa pagitan ng dalawang mga tree kung sakaling gusto mong gumamit ng iba pang bagay kaysa sa built in na git diff na kautusan.
Binanggit lang namin ito sa _git_basics_chapter.asc.
Ang git commit na kautusan ay kumukuha sa lahat ng mga nilalaman ng file na itinanghal sa git add at nagtatala ng isang bagong permanenteng snapshot sa database at pagkatapos ay inililipat ang branch pointer hanggang sa kasalukuyang branch nito.
Unang tinalakay natin ang mga pangunahing kaalaman sa pag-commit sa _git_basics_chapter.asc. Ipinakita din namin kung paano gamitin ang isang -a na flag upang laktawan ang git add na hakbang sa pang-araw-araw na daloy ng trabaho at kung paano gamitin ang -m na flag upang pumasa ng isang mensaheng commit sa command line sa halip ng pagpapatakbo nito sa editor.
Sa _git_basics_chapter.asc tinalakay namin ang paggamit ng --amend na opsyon upang gawing muli ang pinakabagong commit.
Sa _git_branching.asc, pumunta kami sa mas maraming detalye tungkol sa kung ano ang ginagawa ng git at kung bakit ganito niya ginagawa.
Tiningnan namin kung paano mag-sign ng mga commit na cryptographically kasama ang -S na flag sa _git_tools.asc.
Panghuli, tinitingnan natin kung ano ang ginagawa ng git commit sa background at kung paano nito aktwal na ipinatupad sa _git_internals.asc.
Ang utos na git reset ay pangunahing ginagamit upang i-undo ang mga bagay, parang maaari mong sabihin sa pamamagitan ng pandiwa. Ito ay gumagalaw sa paligid ng HEAD pointer at opsyonal na nagbabago sa index o sa lugar ng staging at maaari ring opsyonal na baguhin ang gumaganang direktoryo kung gagamitin mo ang --hard. Ang pangwakas na opsyon ay posibleng magbura sa iyong tinatrabaho kung ginamit nang hindi tama, kaya tiyaking maunawaan mo ito bago gamitin.
Una naming epektibong tinalakay ang pinakasimpleng paggamit ng git reset sa _git_basics_chapter.asc, kung saan ginagamit namin ito upang ma unstage isang file na pinatakbo ang git add.
Pagkatapos ay tinalakay natin ito ng lubos ang detalye sa _git_tools.asc, na nakalaan sa pagpapaliwanag sa utos na ito.
Ginagamit namin ang git reset --hard upang i-abort ang pagsanib sa _git_tools.asc, kung saan ginagamit din namin ang git merge --abort, na kung saan ay isang kaunting pagbabalut para sa git reset command.
Ang git rm command ay ginagamit upang tanggalin ang mga file mula sa lugar ng staging at gumaganang direktoryo para sa Git. Ito ay katulad ng git add subalit ito ay magtatanggal ng isang file para sa susunod na commit.
Tinalakay namin ang utos na git rm ng iilang detalye sa << _ git_basics_chapter # _removing_files >>, kabilang ang paulit-ulit na pag-alis ng mga file at pag-aalis lamang ng mga file mula sa lugar ng staging ngunit iniiwan ang mga ito sa gumaganang direktoryo na may --cached.
Ang tanging iba pang magkakaibang paggamit ng git rm sa aklat ay nasa << _ git_internals # _removing_objects >> kung saan ginagamit namin ng maikli at ipinaliwanag ang --ignore-unmatch kapag nagpapatakbo ng git filter-branch, na kung saan ay pasimpleng hindi nito mag-error-out kapag ang file na sinusubukan naming i-stage ay hindi umiiral.
Maaari itong maging kapaki-pakinabang para sa mga layunin ng pag-script.
Ang utos na git mv ay isang manipis na kaginhawahan na utos upang maglipat ng isang file at pagkatapos ay patakbuhin ang` git add` sa bagong file at git rm sa lumang file.
Binanggit lamang namin nang maikli ang utos na ito sa << _ git_mv >>.
Ang git clean na utos ay ginagamit upang tanggalin ang mga hindi gustong file mula sa iyong gumaganang direktoryo.
Maaaring kabilang dito ang pag-alis ng pansamantalang mga artifact build o pagsamahin ang mga conflict na file.
Tinalakay namin ang karamihang mga pagpipilian at sitwasyon kung saan maaari mong gamitin ang git clean na utos sa << _ git_clean >>.
Iilan lamang ang bilang ng mga utos na karamihang nagpapatupad sa pagsasanib at pagsasama sa Git.
Ang git branch command ay talagang isang tool na naayon sa pamamahala ng branch.
Maaari nitong ilista ang mga branch na mayroon ka, lumikha ng isang bagong branch, tanggalin ang mga branch at palitan ang pangalan ng mga branch.
Karamihan ng _git_branching.asc ay nakatuon sa utos na 'branch` at ginagamit ito sa buong kabanata. Una naming ipinakilala ito sa _git_branching.asc at kami ay dumaan sa karamihan ng iba pang mga tampok nito (listahan at pagtanggal) sa _git_branching.asc.
Sa _git_branching.asc ginagamit namin ang git branch -u na pagpipilian upang mag-set up ng isang branch sa pagsubaybay.
Sa panghuli, tinalakay namin kung ano ang ginagawa nito sa background sa _git_internals.asc.
Ang command na git checkout ay ginagamit upang lumipat ng mga sanga at suriin ang nilalaman sa iyong gumaganang direktoryo.
Una naming nakatagpo ang command sa _git_branching.asc kasama ang command na git branch.
Nakita namin kung paano gamitin ito upang simulan ang pagsubaybay ng mga sanga gamit ang --track flag sa _git_branching.asc.
Ginagamit namin ito upang maipakita muli ang mga magkasalungat na file sa --conflict = diff3 sa _git_tools.asc.
Pumunta kami sa mas detalyadong detalye sa kaugnayan nito sa git reset sa _git_tools.asc.
Sa panghuli, pumunta kami sa ilang detalye ng pagpapatupad sa _git_internals.asc.
Ang tool na git merge ay ginagamit upang pagsamahin ang isa o higit pang mga branch sa branch na iyong sinuri.
Susubukan nito ang kasalukuyang branch sa resulta ng pagsasama.
Ang git merge command ay unang ipinakilala sa _git_branching.asc.
Kahit na ito ay ginagamit sa iba’t ibang mga lugar sa aklat, napakakaunting mga pagkakaiba-iba ng 'merge` command - sa pangkalahatan lamang git pagsamahin <branch> na may pangalan ng solong branch na nais mong pagsamahin.
Tinalakay namin kung paano gumawa ng isang squashed merge (kung saan ang Git ay nagpahiwatig na gumagana ang merge ngunit nagpapanggap lamang ito na tulad ng isang bagong commit na hindi naitala ang kasaysayan ng branch na pinagsasama mo) sa pinakadulo ng _distributed_git.asc.
Maramin din kaming tinalakay tungkol sa proseso ng pagsasama at utos, kabilang ang -Xignore-space-change na ustos at ang` --abort` na flag upang i-abort ang problema sa pag-merge sa _git_tools.asc.
Natutunan namin kung paano i-verify ang mga lagda bago i-merge kung ang iyong proyekto ay gumagamit ng pag-sign na GPG sa _git_tools.asc.
Sa panghuli, natutunan namin ang tungkol sa pagsasama ng Subtree sa _git_tools.asc.
Ang git mergetool utos ay naglulunsad lamang ng isang panlabas na merge helper kung sakaling mayroon kang mga isyu sa isang pagsali sa Git.
Binanggit namin ito nang mabilis sa _git_branching.asc at pumunta sa detalye kung paano ipatupad ang iyong sariling panlabas na tool sa pagsasama sa _customizing_git.asc.
Ang git log na utos ay ginamit upang mapakita ang mga maabot na nakatalang kasaysayang ng proyekto simula sa pinakabagong commit snapshot na pababa. Sa pangkaraniwan ipinapakita lamang nito ang kasaysayan ng kasalukayang branch, subalit maaring magbigay ng kaibahan o kahit maraming mga head or mga branch kung saan maari mong ma traverse. Ito ay madalas nagpapakita din ng mga kaibahan sa pagitan ng dalawa o maraming pang branch sa antas ng commit.
Ang utos na ito ay ginagamit sa halos lahat ng kabanata ng libro para mapakita ang kasaysayan ng proyekto.
Pinakilala namin ang utos at tinalakay ito ng malalim sa _git_basics_chapter.asc.
Doon tiningnan namin sa -p at --stat na opsyon para makuha ang idea kung ano ang pinakilala sa bawat commit at ang --pretty at --oneline na mga opsyon para makita ang kasaysayan na mas maikli, kasama ang iilang petsa at mga opsyon sa pagsasalang ng may-akda.
Sa _git_branching.asc ginamit namin ito kasama ang --decorate na opsyon para madaling mailarawan kung saan ang ating mga branch pointer ay nakalagay at ginamit din namin ang --graph na opsyon para makita kung ano ang hitsura ng mga palayong kasaysayan.
Sa _distributed_git.asc at _git_tools.asc aming tinalakay ang branchA..branchB na syntax para gamitin ang git log na utos para makita kung ano ang kaibahan sa isang katugong branch sa iba pang branch.
Sa _git_tools.asc malawak naming tinalakay ito.
Sa _git_tools.asc at _git_tools.asc tinalakay natin ang branchA…branchB format at ang --left-right na syntax para makita kung ano ang nasa isang branch o sa ibang branch pero hindi sa dalawa.
Sa _git_tools.asc tiningnan din natin kung paano gamitin ang --merge na opsyon para makatulong sa pag-debug ng merge conflict pati na rin ang --cc na opsyon para makita ang pag-merge sa mga conflict na commit sa iyong kasaysayan.
Sa [_git_reflog] ginamit natin ang -g na opsyon para makita ang reflog ng Git sa pamamagitan ng tool na ito imbes sa paggawa ng traversal sa branch.
Sa _git_tools.asc ginamit natin ang -S at -L na mga opsyon para gumawa ng mas pinahusay na mga paghahanap para sa mga anumang pangyayari na pangkasaysayan sa code gaya ng pagtanaw sa kasaysayan ng isang function.
Sa _git_tools.asc nakita natin kung paano gamitin ang --show-signature para magdagdag ng pagpapatibay na string sa bawat commit sa output ng git log nakabase dito kung ito ay wastong pag-sign o hindi.
Ang git stash na utos ay ginamit para pansamantalang mag-imbak sa hindi na commit na trabaho upang luminis ang iyong gumaganang direktoryo na hindi kailangang mag-commit sa di tapos na trabaho sa isang branch.
It ay pangkalahatang tinalakay sa _git_tools.asc.
The git tag command is used to give a permanent bookmark to a specific point in the code history.
Generally this is used for things like releases.
Ang git tag na utos ay ginamit para magbigay ng permanenteng bookmark para sa tiyak na punto sa kasaysayan ng code.
Ang utos na ito ay pinakilala at tinalakay ang detalye sa _git_basics_chapter.asc at ginamit namin ito sa pagsasanay sa _distributed_git.asc.
Tinalakay din namain kung paano gumawa ng naka tag na sign na GPG sa pamamagitan ng --s na flag at pinatunayan ang isa sa pamamagitan ng -v na flag sa _git_tools.asc.
Walang masyadong maraming mga utos sa Git na may access sa network, halos ang lahat ng mga utos ay gumagana sa lokal na database. Kung ikaw ay handa ng ibahagi ang iyong trabaho o mag-pull ng pagbabago galing sa ibang lugar, mayroon kakaunting mga utos na tumatalakay sa malayong mga repositoryo.
Ang git fetch na utos ay nakikipag-usap sa malayong repositoryo at kumukuha ng lahat ng impormasyon na nasa loob ng repositoryo na hindi kasali sa iyong kasalukuyan at iniimbak ito sa iyong lokal na database.
Una naming tiningnan ang utos na ito sa _git_basics_chapter.asc at patuloy nating makikita ang mga halimbawa sa paggamit nito sa _git_branching.asc.
Ginamit din namin ito sa iilang mga halimbawa sa _distributed_git.asc.
Ginamit namin ito para kumuha ng nag-iisang tiyak na sanggunian na nasa labas ng default na lugar sa _github.asc at nakita din natin kung paano kunin ang nanggaling sa bigkis sa _git_tools.asc.
Nagset-up kami ng napakainam na custom refspecs para lang makagawa ng git fetch ng bagay na medyo naiiba kaysa sa sanggunian sa _git_internals.asc.
Ang git pull na utos ay ang pagsasama ng git fetch at git merge na mga utos, kung saan ang Git ay kukuha galing sa remote na iyong itinalaga at pagkatapos ay agarang susubok para ito ay i-merge sa branch na aktibo.
Panandaliang pinakilala namin ito sa _git_basics_chapter.asc at pinakita kung paano mo makikita kung ano ang i-merge kung ito ay pinatakbo mo sa _git_basics_chapter.asc.
Makikita din natin kung paano mo ito magagamit sa pagtulong sa mga mahihirap na pag-rebase sa _git_branching.asc.
Pinakita namin kung paano mo gamitin ito sa pamamagitan ng URL para i-pull ang mga pagbabago sa gamit lamang ng isang paraan sa _distributed_git.asc.
Finally, we very quickly mention that you can use the --verify-signatures option to it in order to verify that commits you are pulling have been GPG signed in _git_tools.asc.
Sa panghuli, panandaliang na banggit namin na pwede mong gamitin ang --verify-signatures na opsyon para lang mapatunayan kung ang mga commit na iyong kinukuha ay mayroong signatura ng GPG sa _git_tools.asc.
Ang git push na utos ay ginamit para makipag-usap sa ibang repositoryo, kuwentahin kung ano ang meron sa lokal na database mo na wala sa remote, at pagkatapos ay i-push ang mga pagkakaiba sa ibang repositoryo.
Ito ay mangangailangan ng access sa pagsulat para sa ibang repositoryo at sa pangkaraniwan ay napatunayan kahit na paano.
Una nating nakita ang git push na utos sa _git_basics_chapter.asc.
Dito natalakay natin ang mga pangunahin ng pag-push sa branch para sa remote na repositoryo.
Sa _git_branching.asc tinalakay natin na mas malalim para sa pag-push ng tiyak na mga branch at sa _git_branching.asc makikita natin paano magset-up ng pagsubaybay ng mga branch para awtomatikong i-push ito.
Sa _git_branching.asc ginamit natin ang --delete na flag para ibura ang branch sa server sa pamamagitan ng git push.
Sa buong _distributed_git.asc makikita natin ang iilang mga halimbawa sa paggamit ng git push para ibahagi ang ginawa sa mga branch sa pamamagitan ng maraming mga remote.
Makikita natin kung paano gamitin ito para ibahagi ang mga tag na ginawa mo sa pamamagitan ng --tags na opsyon sa _git_basics_chapter.asc.
Sa _git_tools.asc ginamit natin ang --recurse-submodules na opsyon para suriin kung ang lahat ng mga submodule na ginawa natin ay naihayag bago pa sa pag-push ng superproject, kung saan ay napakikinabangan sa paggamit ng mga submodule.
Sa _customizing_git.asc pinag-usapan natin ng maikli tungkol sa pre-push na hook, ito ay isang script na pwedeng patakbuhin bago matapos ang pag-push para mapatunayan na ito ay may pahintulot para i-push.
Finally, in _git_internals.asc we look at pushing with a full refspec instead of the general shortcuts that are normally used. This can help you be very specific about what work you wish to share.
Sa panghuli, sa _git_internals.asc tiningnan natin ang pag-push na puno ang refspec imbes sa karaniwang mga shortcut na madalas ginamit.
Ang git remote na utos ay isang pamamahala na tool para sa iyong talaan ng mga remote na repositoryo.
Ito ay nagpapahintulot sa iyo upang i-save ang mga mahahabang URL bilang maiikling mga hawakan, gaya ng `origin'' para hindi mo na kailangang i-type ng paulit-ulit sa lahat ng oras.
Maari kang magkaroon ng iilan sa mga ito at ang `git remote na utos ay ginamit para magdagdag, magbago at magbura sa mga ito.
Ang utos na ito ay tinalakay ng detalye sa _git_basics_chapter.asc, kasali na ang paglista, pagdagdag, pagtanggal at ang pagbabago ng pangalan nila.
Ito ay ginamit din sa halos bawat na kasunod na kabanata sa libro, ngunit lagi sa pamantayan ng git remote add <name> <url> na format.
Ang git archive na utos ay ginamit para gumawa ng archive na file sa tiyak na snapshot ng proyekto.
Ginamit natin ang git archive para gumawa ng isang tarball ng proyekto para sa pagbabahagi sa _distributed_git.asc.
Ang git submodule na utos ay ginamit para pamahalaan ang panlabas na mga repositoryo sa loob ng normal na mga repositoryo.
Ito ay maaring para sa mga library o ibang uri ng nagsalong mga pinagkukunan.
Ang submodule na utos ay merong iilang mga sub-command (add, update, sync, etc) para sa pamamahala ng pinagkukunan ng mga ito.
Ang utos na ito ay nabanggit lamang at lubos na tinalakay sa _git_tools.asc.
Ang git show na utos ay maaring magpapakita ng bagay ng Git sa pamamagitan ng simple at sa paraang nababasa ng tao.
Sa pangkaraniwan ito ay nagagamit mo para mapakita ang impormasyon tungkol sa tag o sa commit.
We first use it to show annotated tag information in _git_basics_chapter.asc. Una nating ginamit ito para ipakita ang impormasyon ng nalagyan ng anotasyon na tag sa _git_basics_chapter.asc.
Pagkalipas medyo ginamit natin ito sa _git_tools.asc para ipakita ang mga commit na may iba’t ibang mga seleksyon ng pagbabago na ating nalutas.
Isa sa mga kawili-wiling mga bagay na pwede nating gawin gamit ang git show ay sa _git_tools.asc para kunin ang mga tukoy na nilalaman ng file sa iba’t ibang mga stage sa panahon ng magkasalungat na merge.
Ang git shortlog na utos ay ginamit para gumawa ng buod sa output ng git log.
Ito ay maraming mga opsyon na magkakapareha sa git log na utos pero imbes na ilista ang lahat ng mga commit ito ay maghahandog ng buod sa mga commit na grupo sa pamamagitan ng may-akda.
Pinakita natin paano gamitin ito para gumawa ng magandang changelog sa _distributed_git.asc.
Ang git describe na utos ay ginamit para kunin ang kahit na anong paglutas sa isang commit at gumagawa ng isang string na nababasa ng tao at hindi ito magbabago.
Ito ay isang paraan para kunin ang paglalarawan ng isang commit na hindi malabo kagaya ng commit na SHA-1 ngunit mas naiintindihan.
Ginamit natin ang git describe sa _distributed_git.asc at
_distributed_git.asc para kumuha ng string para pangalanan ang ating pinakawalang file.
Ang Git ay may iilang mga utos na ginamit para makatulong sa pag-debug sa isyu sa iyong code. Ang lawak nito ay nagsimula sa pag-uunawa kung saan ipinakilala ang isang bagay hanggang sa pag-uunawa kung sino ang nagpakilala nito
Ang `git bisect`na kagamitan ay isang hindi kapani-paniwalang na kapaki-pakinabang na debugging kasangkapan na ginamit upang hanapin kung anong partikular na commit ang unang nagpakilala ng isang bug o problema sa pamamagitan ng paggawa ng isang awtomatikong paghahanap sa binary.
Ito ay buong tinalakay sa _git_tools.asc at nabanggit lamang sa seksyon na iyon.
Ang git blame na utos ay nag-annotate ng mga linya sa anumang file kung saan ang commit ay siyang huling nagpakilala sa pagbabago sa bawat linya ng file at kung sino ang may-akda sa commit.
Ito ay kapaki-pakinabang upang mahanap ang tao na pwedeng hingan ng karagdagang impormasyon tungkol sa isang partikular na seksyon ng iyong code.
Ito ay tinalakay sa _git_tools.asc at binanggit lamang sa seksyon na iyon.
Ang git grep na utos ay makakatulong sa iyo na makahanap ng anumang string o regular na pagpapahayag sa alinmang mga file sa iyong source code, kahit sa mas lumang mga bersyon ng iyong proyekto.
Ito ay tinalakay sa [_git_grep] at binanggit lamang sa seksyon na iyon.
Ang ilang mga utos sa Git ay nakasentro sa konsepto ng pag-iisip ng mga commit sa mga tuntunin ng mga pagbabago na ipinakilala nila, na tila ang serye ng commit ay isang serye ng mga patch.
Ang mga utos na ito ay tumutulong sa iyo na pamahalaan ang iyong mga branch sa ganitong paraan.
Ang git cherry-pick na utos ay ginagamit upang gawin ang pagbabago na ipinakilala sa isang solong Git na commit at subukan na muling ipakilala ito bilang isang bagong commit sa kasalukuyang branch.
Maaari itong maging kapaki-pakinabang upang gumamit lamang ng isa o dalawang mga commit mula sa isang branch na paisa-isa sa halip na pagsasama sa branch na kukuha sa lahat ng mga pagbabago.
Ang Cherry picking ay inilarawan at ipinakita sa _distributed_git.asc.
Ang git rebase na utos ay karaniwang isang awtomatikong cherry-pick.
Tinutukoy nito ang isang serye ng mga commit at pagkatapos ay i-cherry-pick ang mga ito nang isa-isa sa parehong pagkakasunud-sunod sa iba pang lugar.
Ang pag-rebase nito ay tinalakay ang detalye sa _git_branching.asc, kabilang ang pagtalakay sa mga collaborative na isyu na kasangkot ang mga pag-rebase sa mga branch na pampubliko na.
Ginagamit namin ito sa pagsasagawa sa isang halimbawa ng paghahati ng iyong kasaysayan sa dalawang magkahiwalay na mga repositoryo sa _git_tools.asc, ginagamit din ang --onto na flag.
Tinalakay namin ang isang pagsalungat sa merge sa panahon ng pag-rebase sa _git_tools.asc.
Ginagamit din namin ito sa isang interactive na pag-script sa mode sa pamamagitan ng -i na opsyon sa _git_tools.asc.
Ang git revert na utos ay sa totoo lang ay isang kabaliktaran ng git cherry-pick.
Lumilikha ito ng isang bagong commit na nalalapat ang eksaktong kabaligtaran ng pagbabago na ipinakilala sa commit na iyong tina-target, sa makatuwid ang pagbawi o pagbabalik nito.
Ginamit namin ito sa _git_tools.asc para ibalik ang pagsanib ng commit.
Maraming mga proyekto ng Git, kasali na ang Git mismo, ay ganap na pinananatili ng mga lista ng liham. Ang Git ay may ilang mga kasangkapan na binuo sa loob nito na tumutulong gawing mas madali ang prosesong ito, mula sa pagbuo ng mga patch na maaari mong madaling i-email hanggang sa paglalapat ng mga patch mula sa isang email box.
Ang git apply na utos command nilalapat ang patch na nilikha gamit ang git diff o kahit na GNU diff na utos.
Ito ay katulad ng kung ano ang patch na utos na maaaring gawin sa ilang maliliit na pagkakaiba.
Ipinakikita namin ang paggamit nito at ang mga pangyayari kung saan maaari mong gawin ito sa _distributed_git.asc.
Ang git am na utos ay ginamit para ilagay ang mga patch mula sa inbox ng email, partikular na ang isang naka-format na mbox.
Ito ay kapaki-pakinabang sa pagtanggap ng mga patch sa email at ilapat ang mga ito ng madali sa iyong proyekto.
Tinalakay namin ang paggamit at workflow ng git am sa [_git_am] kabilang ang paggamit ng --resolved, -i at -3 na mga opsyon.
Mayroon ding iilang mga hook na maaari mong gamitin upang makatulong sa workflow sa paligid ng git am at sila ay tinalakay sa _customizing_git.asc.
Ginagamit din namin ito upang ilapat ang patch na naka-format sa mga pagbabago sa GitHub Pull Request sa _github.asc.
Ang git format-patch na utos ay ginamit para makagawa ng mga serye ng mga patch sa format ng mbox na maaari mong gamitin upang ipadala sa isang mailing list na naka-format ng maayos.
Tinalakay namin ito sa isang halimbawa ng pagbibigay ng kontribusyon sa isang proyekto gamit ang git format-patch na kasangkapan sa _distributed_git.asc.
Ang git imap-send na utos ay nag-upload ng mailbox na nabuo sa pamamagitan ng git format-patch sa isang folder ng mga draft ng IMAP.
Tinalakay namin ang isang halimbawa ng pagbibigay ng kontribusyon sa isang proyekto sa pamamagitan ng pagpapadala ng mga patch gamit ang git imap-send na kasangkapan sa _distributed_git.asc.
Ang git send-email na utos ay ginamit para magpadala ng mga patch kung saan ay nabuo sa pamamagitan ng git format-patch sa email.
Tinalakay namin ang isang halimbawa ng pag-ambag sa isang proyekto sa pamamagitan ng mga patch gamit ang git send-email na kasangkapan sa _distributed_git.asc.
Ang git request-pull na utos ay simpleng ginagamit upang bumuo ng isang halimbawa ng nilalaman ng mensahe upang mag-email sa isang tao.
Kung meron kang isang branch na nasa pampublikong server at nais na ipaalam sa isang tao kung paano isama ang mga pagbabagong iyon na hindi na magpadala ng mga patch sa email, maaari mong patakbuhin ang utos na ito at ipadala ang output sa taong gusto mong kunin ang mga pagbabago.
Pinakita namin kung paano gamitin ang git request-pull para makabuo ng pull na mensahe sa _distributed_git.asc.
Ang Git ay may ilang mga utos upang maisama ang iba pang mga sistema ng pagkontrol sa bersyon.
Ang git svn na utos ay ginagamit upang makipag-ugnayan sa sistema ng pagkontrol sa bersyon ng Subversion bilang isang kliyente.
Ang ibig sabihin nito ay maaari mong gamitin ang Git upang mag-check out mula at mag-commit patungo sa isang server ng Subversion.
Ang utos na ito ay malalim na tinalakay sa [_git_svn].
Para sa ibang sistema sa pagkontrol ng bersyon o pag-import mula sa halos anumang format, pwede mong gamitin ang git fast-import para mabilis na imapa ang iba pang mga format sa Git na maaaring madaling irekord.
Ang utos na ito ay tinalakay ng malalim sa _git_and_other_systems.asc.
Kung ikaw ay nangangasiwa ng isang repositoryo ng Git o kailangang ayusin ang isang bagay sa isang malaking paraan, ang Git ay nagbibigay ng iilang mga administratibong mga utos upang matulungan ka.
Ang git gc na utos ay nagpapatakbo ng ``garbage collection'' sa iyong repositoryo, nag-aalis ng hindi kinakailangang mga file sa iyong database at nag-iimpake ng mga natitirang mga file sa isang mas mahusay na format
Ang utos na ito ay karaniwang tumatakbo sa background para sa iyo, subalit maaari mong manu-manong patakbuhin ito kung nais mo. Tinalakay namin ang mga halimbawa nito sa [_git_gc].
Ang git fsck na utos ay ginamit upang suriin ang panloob na database para sa mga problema o hindi pagkakaayon.
Mabilis na ginamit lamang namin ito nang isang beses sa _git_internals.asc upang maghanap ng mga nakalawit na bagay.
Ang git reflog na utos ay napupunta sa isang log kung saan ang lahat ng mga ulo ng iyong mga branch ay naging sa iyong pagtrabaho para makahanap ng mga commit na maaari mong nawala sa pamamagitan ng muling pagsusulat ng mga kasaysayan.
Tinalakay namin ang utos na ito sa [_git_reflog], kung saan ipinapakita namin ang normal na paggamit at kung paano gamitin ang git log -g para matanaw ang parehong impormasyon ng git log na output.
Tinalakay din namin ang isang praktikal na halimbawa ng pagbawi ng naturang nawalang branch sa _git_internals.asc.
Ang git filter-branch na utos ay ginagamit upang muling isulat ang mga naglo-load na mga commit ayon sa ilang mga pattern, tulad ng saanmang pag-alis ng isang file o pag-filter na pababa sa buong repository sa isang solong subdirectory para sa pagkuha ng isang proyekto.
Sa _git_tools.asc ipinapaliwanag namin ang utos at tinuklas ang maraming iba’t ibang mga opsyon kagaya ng --commit-filter, --subdirectory-filter at --tree-filter.
Sa _git_and_other_systems.asc at _git_and_other_systems.asc ginagamit namin ito upang ayusin ang na-import na mga panlabas na repositoryo.
Mayroon ding mga iilang mga mas mababang antas ng mga pagtutuberong utos na aming natagpoan sa aklat.
Ang unang nakatagpo natin ay ang ls-remote sa _github.asc na ginagamit namin upang tingnan ang mga hilaw na sanggunian sa server.
Ginagamit namin ang ls-files sa _git_tools.asc, _git_tools.asc at _git_tools.asc para makakuha ng mas maraming mga hilaw na anyo sa kung ano ang hitsura ng iyong staging.
Nabanggit din namin ang rev-parse sa _git_tools.asc upang kumuha ng halos anumang string at gawin itong isang bagay na SHA-1.
Gayunpaman, ang karamihan sa mga mababang antas ng pagtutuberong mga utos ay tinalakay namin sa _git_internals.asc, na kung saan ay higit pa o mas mababa pa sa kung saan nakatutok ang isang kabanata. Sinubukan naming maiwasan ang paggamit ng mga ito sa karamihan ng buong aklat.