2.2 Mga Pangunahing Kaalaman sa Git - Pagtatala ng mga Pagbabago sa Repositoryo

Ang pangunahing kasangkapan na iyong ginamit para matukoy kung aling mga file ay sa aling estado ay ang git status na utos. Kung patakbuhin mo ang utos na ito na direkta pagkatapos ng clone, dapat mong makita ang isang bagay na tulad nito:

Nangangahulugan ito na mayroon kang isang malinis na tinatrabahong direktoryo — sa ibang salita, waka sa iyong mga sinusubaybayan na mga file ang nabago. Hindi rin makikita ni Git ang anumang hindi sinusubaybayan na mga file, o sila ay malista dito. Sa wakas, ang utos ay nagsasabi sa iyo na kung saan na branch ikaw ay nandoon at nagsasabi sayo na hindi ito naiiba mula sa parehong branch sa server. Para sa ngayon, ang branch na yan ay laging “master”, kung saan ay default; hindi ka mag-alala dito. Pag-branch ng Git ay magpapatuloy sa mga branch at mga reperensiya sa detalye.

Sabihin natin na ikaw ay nagdagdag ng isang bagong file sa iyong proyekto, isang simpleng README na file. Kung ang file ay hindi umiiral noon, at ikaw ay nagpatakbo ng git status, Iyong makikita ang iyong hindi sinusubaybayan na file na tulad nito:

Makikita mo na ang iyong bagong README na file ay hindi nasubaybayan, dahil ito ay sa ilalim ng “Untracked files” papunta sa iyong katayuan ng output. Ang hindi sinusubaybayan ay talagang ang ibig sabihin nito na ang Git ay nakikita ang isang file na wala sa iyong nakaraang snapshot; Ang Git ay hindi magsisimula kasama ito sa iyong commit na mga snapshot hanggang ikaw ay nagsasabi na gawin ito. Ginagawa ito para ikaw ay hindi aksidenteng makapagsimula na kasama ang nabuong binary na mga file o ibang mga file na hindi mo gustong isama. Gusto mong magsimula na kasama ang README, kaya natin simulan ang pagsubaybay sa file.

Upang magsimula sa pagsubaybay ng isang bagong file , gagamitn mo ang utos na git add. Para umpisahan ang pagsubaybay sa README na file, maaari mo itong patakbuhin:

Kung pinapatakbo mo ang iyong katayuan ng utos uli, makikita mo na ang iyong README na file ay ngano nakasubaybay na at itatanghal upang ma-commit:

Maaari mong sabihin na ito ay itinanghal dahil ito ay sa ilalim ng “Changes to be committed” na heading. Kung ikaw ay mag-commit sa puntong ito, ang bersyon ng file sa oras na pinatakbo ang git add ay kung ano ang magiging makasaysayan na snapshot. Maaari mong isipin na kapag pinatakbo mo ang git init ng maaga, pagkatapos patakbuhin mo ang git add <files> — iyon ang pagsisimula ng pagsubaybay ng mga file sa iyong direktoryo. Ang git add na utos ay kumukuha ng isang pangalan ng path para sa alinman na file o direktoryo; kung ito ay isang direktoryo, ang utos ay nagdagdag ng lahat ng mga file sa direktoryo ng maraming beses.

Baguhin natin ang file na nasubaybayan na. Kung ikaw ay nagbago sa dating sinusubaybayan na file na tinatawag na CONTRIBUTING.md at pagkatapos pinatakbo mo ang iyong git status na utos uli, may makukuha kang isang bagay na tulad nito:

Ang CONTRIBUTING.md na file ay lumilitaw sa ilalim ng seksyon na nakapangalan na “Changes not staged for commit” — na ibig sabihin na ang isang file na sinusubaybayan ay nabago sa tinatrabahong direktoryo pero hindi pa naitanghal. Upang itanghal ito, patakbuhin mo ang git add na utos. git add ay isang multipurpose na utos — ginagamit mo ito upang magsimula sa pagsubaybay ng bagong mga file, upang itanghal ang mga file, at gumawa pa ng ibang mga bagay tulad ng pagmamarka ng merge-conflicted na mga file bilang nalutas. Maaaring makatulong ito na isipin ito na mas higit pa “magdagdag ng tumpak na nilalaman na ito sa susunod na commit” sa halip na “idagdag ang file na ito sa proyekto”. Patakbuhin natin ang git add ngayon upang itanghal ang CONTRIBUTING.md na file, at pagkatapos patakbuhin ang git status muli:

Ang pareho na mga file ay naitanghal at mapupunta sa iyong susunod na commit. Sa puntong ito, ipagpalagay na naaalala mo na isang maliit na pagbago na gusto mong gawin sa CONTRIBUTING.md bago mo i-commit ito. Buksan mo ito uli at gawin ang pagbabago na iyon, at handa kana i-commit. Gayunpaman, patakbuhin natin ang git status ng isa pang pagkakataon:

Ano ba ‘yan? Ngayon ang CONTRIBUTING.md ay nakalista bilang kapwa nakatanghal at hindi nakatanghal. Paano ito naging posible? Ito ay nagsasabi na ang Git ay nagtatanghal ng isang file na eksakto na kung kailan ikaw ay nagpatakbo sa git add na utos. Kung ikaw ay mag-commit ngayon, ang bersyon ng CONTRIBUTING.md tulad noong huling pinatakbo ang git add na utos ay kung paano ito pupunta sa commit, hindi ang bersyon ng file na tulad ng iyong tinatrabahong direktoryo kapag nagpatakbo ka ng git commit. Kung magbago ka ng isang file pagkatapos iyong pinatakbo ang git add, kailangan mong patakbuhin ang git add muli upang itanghal ang pinakabagong bersyon ng file:

Habang ang git status na output ay medyo komprehensibo, ito din ay medyo sali-salita. Ang Git din ay merong isang maliit na status flag para ikaw ay makakita ng iyong mga binago sa isang mas compact na paraan. Kung patakbuhin mo ang git status -s o git status --short makakuha ka ng mas pinadali na output mula sa utos:

Bagong mga file na hindi sinusubaybayan ay merong isang ?? sunod sa kanila, Ang mga bagong files na idinagdag sa pagtatanghal na lugar ay merong A, nabago na mga file ay merong M at iba pa. Mayroong dalawang column sa output - ang kaliwang-kamay na column ay nagpapaliwanag sa katayuan sa pagtatanghal na lugar at ang kanang-kamay na column ay nagpapaliwanag sa katayuan sa tinatrabahong tree. Kaya halimbawa sa output na iyon, ang README na file ay binago sa tinatrabahong direktoryo pero hindi pa natanghal, habang ang lib/simplegit.rb na file ay binago at natanghal. Ang Rakefile ay binago, natanghal at pagkatapos ay binago muli, kaya may mga pagbabago sa mga ito na parehong natanghal at hindi natanghal.

Madalas, magkakaroon ka ng klase ng mga file na hindi mo gusto ang Git na awtomatikong magdagdag o kahit na magpakita sayo bilang hindi sinusubaybayan. Ang mga ito ay pangkalahatang awtomatikong nabuo na mga file tulad ng log na mga file o mga file na ginawa ng iyong tinayong sistema. Sa ganitong mga kaso, maaari kang gumawa ng mga palatandaan ng listahan ng file upang tumugma sa kanilang napangalan na .gitignore. Narito ang isang halimbawa sa .gitignore na file:

Ang unang linya ay nagsasabi ng Git na hindi pansinin ang anumang mga file na nagtatapos sa “.o” o “.a” — na object at archive na mga file na maaari ang produkto ng pag-build ng iyong code. Ang pangalawang linya ay nagsasabi ng Git na hindi pansinin ang lahat ng mga file na kaninong mga pangalan ay nagtatapos na may (~), na ginagamit ng maraming mga tekstong editor tulad ng Emacs upang markahan ang pansamantalang mga file. Maaari mo ring magsama ng log, tmp, o pid na direktoryo; awtomatikong nabuo na dokumentasyon; at iba pa. Pag-set ng isang .gitignore na file para sa iyong bagong repositoryo bago ikaw magsimula ay pangkalahatang isang magandang ideya kaya hindi ka aksidenteng mag-commit ng mga file na hindi mo gusto sa iyong Git na repositoryo.

Ang mga patakaran para sa mga palatandaan na maaari mong ilagay sa .gitignore na file ay ang mga sumusunod:

Ang Glob na mga palatandaan ay katulad ng pinasimpleng regular na mga expression na ginagamitan ng mga shell. Isang asterisk (*) ay tumutugma sa zero o higit pa na mga karakter; [abc] ay tumugma sa anumang karakter sa loob ng mga bracket (sa kasong ito a, b, o c); isang tanong na marka (?) na tumutugma ng isang solo na karakter; at mga bracket na naglalakip ng mga karakter na pinaghiwalay ng isang hyphen ([0-9]) na tumutugma sa anumang karakter sa pagitan nila (sa kasong ito 0 hanggang 9). You can also use two asterisks to match nested directories; a/**/z would match a/z, a/b/z, a/b/c/z, and so on.

Narito ang isa pang halimbawa sa .gitignore na file:

Kung ang git status na utos ay masyadong malabo para sa iyo — kung gusto mong malaman ang eksakto kung ano ang iyong binago, hindi lamang kung aling mga file — maaari mong gamitin ang git diff na utos. Talakayin natin ang git diff sa mas detalyado mamaya, ngunit malamang ikaw ay gagamit nito ng mas madalas para sagutin ang dalawang tanong na ito: Ano ang iyong nabago pero hindi pa natanghal? At ano ang iyong itinanghal na iyong i-commit pa? Kahit na ang git status ay sasagot sa mga tanong na iyon ng pangkalahatan sa pamamagitan ng paglista ng mga pangalan ng file, ang git diff ay nagpapakita sa iyo ng eksaktong mga linya na idinagdag at inalis — ang patch, na tulad nito.

Let’s say you edit and stage the README file again and then edit the CONTRIBUTING.md file without staging it. Kung pinatakbo mo ang iyong git status na utos, makikita mo ulit ang isang bagay na tulad nito:

Para tingnan ang iyong binago pero hindi pa naitanghal, i-type ang git diff na walang ibang mga argumento:

Ang utos na iyon ay inihahambing kung ano ang nasa iyong tinatrabahong direktoryo at kung ano ang nasa iyong itinanghal na lugar. Ang resulta ay nagsasabi sa iyo na ikaw ay nakagawa sa hindi mo pa naitanghal.

Kung gusto mong tingnan ang hindi mo pa naitanghal na mapupunta sa iyong susunod na commit, maaari mong gamitin ang git diff --staged. Ang utos na ito ay naghahambing sa iyong itinanghal na pagbabago sa iyong huling commit:

Ito ay importanteng tandaan na ang git diff na sa sarili niya ay hindi nagpapakita ng lahat ng mga pagbabago na iyong nagawa sa huli mong commit — mga pagbabago lamang na hindi pa rin naitanghal. Kung iyong natanghal ang lahat ng iyong mga binago, ang git diff ay magbibigay sayo nang walang output.

Para sa isa pang halimbawa, kung ikaw ay nagtanghal sa CONTRIBUTING.md na file at pagkatapos ay na-edit ito, maaari mong gamitin ang git diff para tingnan ang mga pagbabago sa file na naitanghal at ang mga pagbabago na hindi pa naitanghal. If our environment looks like this:

Ngayon ay maaari mo nang gamitin ang git diff para tingnan kung ano pa ang hindi naitanghal:

at ang git diff --cached para tingnan kung ano ang iyong naitanghal sa ngayon (--staged and --cached are synonyms):

Ngayon na ang iyong itinanghal na lugar ay nai-setup ayon sa gusto mo, maaari mong i-commit ang iyong mga binago. Tandaan na anuman na hindi pa rin naitanghal — ang anumang mga file na iyong nalikha o nabago na hindi mo pa napatakbo ang git add mula nong iyong na-edit mo sila — hindi ka mapupunta sa pag-commit. Mananatili sila bilang nabago na mga file sa iyong disk. Sa kasong ito, sabihin natin na sa iyong huling beses na iyong pinatakbo ang git status, makikita mo lahat na iyong naitanghal, kaya handa kana i-commit ang iyong mga binago. Ang pinakasimpleng paraan para ma-commit ay mag-type ng git commit:

Ang paggawa nito ay naglulunsad ng iyong editor na napili. (Ito ay nag-set ng iyong shell ng EDITOR na environment variable — kadalasan ay vim o emacs, bagaman maaari mong i-configure ito kung ano ang gusto sa paggamit ng git config --global core.editor na utos tulad na iyong nakita sa Pagsisimula).

Ang editor ay nagpapakita ng mga sumusunod na teksto(halimbawa nito ay ang Vim na screen):

Nakikita mo na ang default na mensahe ng commit ay naglalaman ng pinakabagong output sa git status na utos na nagkomento at isang walang laman na linya sa itaas. Maaari mong alisin ang mga komento na ito at i-type ang iyong mensahe ng commit, o maaari mong iwan ang mga ito doon upang makatulong sayo na tandaan ang iyong mga nai-commit. (Para sa isang mas tahasang paalala kung ano ang iyong nabago, maaari mong ipasa ang -v na opsyon sa git commit. Ang paggawa nito ay naglalagay din ng diff sa iyong nabago sa editor kaya maaari mong tingnan ang eksakto kung ano ang iyong nai-commit.) Kapag lumabas ka sa editor, Ang Git ay lumilikha ng iyong commit na may mensahe sa commit (sa mga komento at diff na nakuha).

Bilang alternatibo, maaari mong i-type ang iyong mensahe sa commit na nasa linya ng commit na utos sa pamamagitan ng pagtukoy nito pagkatapos ng isang -m na flag, tulad nito:

Nalikha mo na ngayon ang iyong unang commit! Maaari mong makita ang commit ay nagbigay sa iyo ng ilang output tungkol sa sarili nito: kung anong branch ang iyong na-commit sa (master), kung ano ang SHA-1 checksum na commit na meron (463dc4f), kung gaano karami ang mga file na nabago, at istatistika tungkol sa mga linya na naidagdag at inalis sa commit.

Tandaan na ang commit ay nagtatala ng snapshot na iyong nai-setup sa iyong itinanghal na lugar. Anuman ang hindi mo naitanghal ay nakaupo pa rin doon na nabago; maaari mong gawin ang isa pang commit para madagdag sa iyong kasaysayan. Sa bawat oras na magsagawa ka ng commit, Nagtatala ka ng isang snapshot sa iyong proyekto na pwede mong ibalik sa o ihambing sa ibang pagkakataon.

Kahit na ito ay maaaring nakamamanghang kapaki-pakinabang para sa paglikha ng mga commit na eksakto sa kung ano ang gusto mo sa kanila, ang staging na lawak ay paminsan-minsan isang kaunting kumplikado kaysa sa kailangan mo sa iyong workflow. Kung gusto mong laktawan ang staging na lawak, ang Git ay nagbibigay na isang simpleng daang tuwiran. Pagdaragdag ng -a na opsyon sa git commit na utos ay awtomatikong ginagawa ng Git ang pag-stage sa bawat file na nasubaybayan na bago ginagawa ang pag-commit, na hinahayaan ka na maglaktaw sa git add na parte:

Pansinin kung paano hindi ka kailangan na magpatakbo ng git add sa CONTRIBUTING.md na file sa kasong ito bago ka mag-commit. Iyan ay dahil ang -a na flag ay nagsasama ng lahat na nabago na mga file. Ito ay maginhawa, ngunit mag-ingat; kung minsan ang flag na ito ay magdudulot sa iyo ng pagsasama ng hindi inaasahang mga pagbabago.

Para mag-alis ng isang file mula sa Git, kailangan mong alisin ito mula sa iyong nasubaybayan na mga file (mas tama, tanggalin ito mula sa iyong staging na lawak) at pagkatapos i-commit. Ang git rm na utos ay ginagawa yan, at inaalis din ang file mula sa iyong tinatrabahong direktoryo para hindi mo makikita ito bilang hindi nasubaybayan na file sa susunod.

Kung alisin mo lamang ang file mula sa iyong tinatrabahong direktoryo, nagpapakita ito sa ilalim ng “Ang mga pagbabago ay hindi na-stage para i-commit” (yan ay, unstaged) lawak ng iyong git status na output:

Pagkatapos, kung ikaw ay nagpatakbo ng git rm, ito ay magsi-stage sa pag-alis ng file:

Sa susunod na ikaw ay mag-commit, ang file ay mawawala at hindi na masubaybayan. Kung ikaw ay nakapagbago ng isang file at idinagdag na ito sa staging na lawak, dapat mong pilitin ang pagtanggal kasama ang -f na opsyon. Ito ay isang tampok na kaligtasan para maiwasan ang aksidenteng pag-alis ng datos na hindi pa naitala sa isang snapshot at hindi na ito makuha muli mula sa Git.

Isa pang kapaki-pakinabang na bagay na gusto mong gawin ay ang pagpanatili ng file sa iyong tinatrabahong tree ngunit alisin ito mula sa iyong staging na lawak. Sa ibang salita, baka gusto mong panatilihin ang file sa iyong hard drive ngunit walang Git na nagsubaybay nito ngayon. Ito ay partikular na magagamit kung ikaw ay nakalimot na magdagdag na kung ano sa iyong .gitignore na file at aksidenteng na-staged ito, tulad ng isang malaking log file o isang bugkos ng .a na naipon na mga file. Para gawin ito, gamitin ang --cached na opsyon:

Maaari mong ipasa ang mga file, mga direktoryo, at ang file-glob na mga palatandaan sa git rm na utos. Ibig sabihin na maaari kang gumawa ng mga bagay na tulad nito:

Tandaan ang backslash (\) na nasa harap sa *. Ito ay kinakailangan dahil ang Git ay gagawang kanyang sariling filename na pagpapalawak bilang karagdagan sa iyong filename expansion sa shell. This command removes all files that have the .log extension in the log/ directory. O, maaari kang gumawa ng isang bagay na tulad nito:

Ang utos na ito ay nag-aalis ng lahat ng mga file na ang mga pangalan ay nagtatapos nang may ~.

Hindi tulad ng maraming iba pang mga sistema ng VCS, ang Git ay hindi malinaw na nagsubaybay ng pagkilos ng file. Kung ikaw ay nagpalit ng pangalan sa Git, walang metadata ay naka-imbak sa Git na nagsasabi na iyong pinalitan ang pangalan ng file. Gayunpaman, ang Git ay medyo matalino sa pag-uunawa na pagkatapos ng katotohanan — haharapin natin ang pag-detect sa paggalaw ng file isang saglit.

Kaya naman ito ay medyo nakakalito na ang Git ay may mv na utos. Kung gusto mong palitan ng pangalan ang isang file sa Git, maaari kang magpatakbo ng isang bagay na tulad nito:

at ito ay gumagana nang maayos. Sa katunayan, kung ikaw ay magpatakbo ng isang bagay na tulad nito at tumingin sa katayuan, iyong makikita na ang Git ay isinaalang-alang ang pagbago ng panglan ng file:

Gayunpaman, ito ay katumbas sa pagpapatakbo ng isang bagay na tulad nito:

Ang Git ay nakatukoy na ito ay isang pagpapahiwatig ng pagpalit ng pangalan, kaya hindi mahalaga na kung ikaw ay nakapalit ng pangalan sa file sa ganun na paraan o kasama ang mv na utos. Ang tanging tunay na kaibahan ay ang git mv ay isang utos sa halip na tatlo — ito ay isang kaginhawaang function. Higit na mahalaga, maaari kang gumamit ng anumang kasangkapan na gusto mo upang magpalit na pangalan sa isang file, at maipasa sa add/rm mamaya, bago ka mag-commit.