Git 🌙
Chapters ▾ 2nd Edition

2.2 Git асослари - Ўзгаришларни омборга ёзиш

Ўзгаришларни омборга ёзиш

Шундай қилиб сизда Git нинг ҳақиқий омбори ва қандайдир лойиҳа учун ишчи файллар нусҳаси мавжуд. Сиз лойиҳа билан ишлаш давомида керакли жойда сақлаш пайтида бир қанча ўзгаришлар ва ушбу ўзгаришларни ҳолатини “суръат” (snapshots)га олиб фиксирлашингиз керак.

Эсда тутинг ишчи каталогигингиздаги ҳар бир файл икки ҳолатдан бирида: талқин кузатуви остида ёки кузатилмаётган ҳолатда. Кузатилаётган файллар – бу лойиҳанинг охирги формадаги ҳолати файллари (snapshot). Улар ўзгартирилмаган, ўзгартирилган ёки жўнатиш учун тайёрланган(staged) бўлиши мумкин. Кузатилмайдиган файллар бу ишчи каталогингиздаги кузатилаётган файлларга кирмайдиган қолган барча файллардир. Қачон сиз биринчи бор омборни клондаштирсангиз, барча файллар кузатилаётган ва ўзгартирилмаган бўлади, чунки сиз уларни эндигина сақланувчи омбордан олдингиз (checked them out) ва ҳеч нимани ўзгартирганингиз йўқ.

Сиз файлларни таҳрирлашингиз биланоқ Git уларни ўзгаотирилганлар деб қарай бошлайди. Чунки сиз охирги жўнатилгандан кейин яна ўзгартириш киритган ҳисобланаябсиз. Сиз ушбу ўзгаришларни индекслайсиз(stage) ва кейин барча индекланган ўзгаришларни фиксирлайсиз, шу тарзда жараён такрорланади. Бу жараённинг тасвири қуйида келтирилган:

Сизнинг файлларингизни иш жараёнидаги ҳолатларининг цикл ҳолати.
Figure 8. Сизнинг файлларингизни иш жараёнидаги ҳолатларининг цикл ҳолати.

Файлларингиз ҳолатини аниқлаш

Қайси файл қанақа ҳолатда эканлигини аниқлаш учун асосий ускуна – git status. Агар сиз клонлаштириш сўнг дарров ушбу командани ишлатсангиз қуйидаги кабиларни кўришингиз мумкин:

$ git status
On branch master
nothing to commit, working directory clean

Бу сизни каталогингиз тоза эканлигидан бошқача қилиб айтганда эса каталогда кузатилаётган ўзгартирилган файллар йўқ эканлигидан дарак беради. Git шунингдек кузатилмаётган файлларни ҳам топа олгани йўқ, акс ҳолда улар акс этган бўларди. Ва ниҳоят, команда сиз айни вақтда қайси ирмоқ (branch) да эканлигингизни ҳам кўрсатади. Хозирча бу ирмоқ доим “master” - одатий тарзда қабул қилинган, бу бўлимда бу муҳим эмас. Навбатдаги Git да тармоқланиш бўлимда ирмоқ ва мурожатлар ҳақида батафсилроқ гапириб берилади.

Тасаввур қилайлик сиз лойиҳангизга янги файл қўшдингиз, оддий README файл. Агар ушбу файл олдин бўлмаган бўлса ва сиз git status ни бажарсангиз кузатилмаётган файл ҳақидаги қуйидаги маълумотни кўришингиз мумкин:

$ echo 'My Project' > README
$ git status
On branch master
Untracked files:
  (use "git add <file>..." to include in what will be committed)

    README

nothing added to commit but untracked files present (use "git add" to track)

Сиз янги README файл кузатилмаётган эканлигини уни “ntracked files” бўлимидаги (секциясидаги) рўйҳатдан кўриб билишингиз мумкин. Одатда кузатилмаётган файл тарзида Git аввалги ҳолатда тасдиқланганлар ичида топа олмаган файлларни назарда тутади. Git га уларни сизни коммит(тасдиқларингизга)ларингизга қўшиш кераклиги ҳақидаги буйруқни бермаганингизча қўшмайди. Бу сизни тасодифан генерация қилинган иккилик файлларини ёки сиз хоҳламаган файлларни омборга қўшилиб кетишининг олдини олади. Сиз README файлини қўшишни хоҳлаябсизми келинг унда буни амалга оширамиз.

Янги файлларни кузатиш

Янги файлни кузатишни бошлаш учун (талқинлар кузатуви остига олиш учун) git add командаси ишлатилади. README файлини кузатишни бошлаш учун қуйидагини бажаришингиз керак:

$ git add README

Агар сиз яна status командасини берсангиз README файл кузатилаётган ва индексланганлигини кўришингиз мумкин:

$ git status
On branch master
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

    new file:   README

Файлни индексланганлар рўйҳатида эканлигини уни “Changes to be committed” бўлимидаги (секциясидаги) рўйҳатда кўриб билишингиз мумкин. Агар сиз ушбу вақтда жўнатиш (коммит) буйруғини берсангиз, у ҳолда git add командаси ёрдамида қўшилган файл талқини ҳолатлар тарихи суръатига қўшилади. Сизни эсингизда бўлса керак, аввалги бўлимларда git init командасини бажаргандан кейин git add (files) командасини бажарган эдингиз. Ушбу буйруқ каталогингиздаги файлларни талқинлар кузатуви остига олиш мақсадида берилган эди. git add команда параметр сифатида файл ёки каталог йўлини қабул қилади ва агар у каталог бўлса рекурсив усулда ундаги барча файлларни индекслаб чиқади.

Ўзгартирилган файлларни индекслаш

Келинг талқинлар кузатуви отида бўлган файлга ўзгартириш киритамиз. Агар сиз кузатилаётган файл “CONTRIBUTING.md” ни ўзгартирсангиз сўнг status командасини ишлатсангиз у ҳолда натижа тахминан қуйидагича бўлади:

$ git status
On branch master
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

    new file:   README

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

    modified:   CONTRIBUTING.md

Файл “CONTRIBUTING.md” “Changed but not updated” - бўлими (секцияси) ичида ётибди, бу эса ишчи каталогдаги файл ўзгартирилганлигини лекин ҳалигача индексланмаганлигини билдиради. Уни индекслаш учун git add (бу кўп функцияли команда талқинларни кузатуви остига янги файлларни қўшишни ва шунинг билан биргаликда бошқа мақсадларда масалан ўзгартирилган файлларни омбордаги билан бирлаштириш вақтида келиб чиққан тафовут (конфликт) ларда қайси файлни қўшиш кераклигини кўрсатишда ишлатилади) командасини бажариш керак. “CONTRIBUTING.md” файлини индекслаш учун git add командасини бажарамиз, сўнг git status командасини берамиз:

$ git add CONTRIBUTING.md
$ git status
On branch master
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

    new file:   README
    modified:   CONTRIBUTING.md

Энди иккала файл ҳам индексланган ва улар навбатдаги жўнатиш(коммит) учун тайёр. Фараз қилайлик сиз шу онда CONTRIBUTING.md файл учун киритиладиган битта катта бўлмаган ўзгартиришни эслаб қолдингиз ва уни фиксирлашдан олдин амалга оширмоқчисиз. Сиз файлни очасиз ўзгартирш киритиб сақлаб ёпасиз ва гўёки ҳаммаси жўнатишга тайёрдай. Лекин, келинг git status командаси ёрдамида ростдан ҳам шундаймикан текшириб кўрамиз:

$ vim CONTRIBUTING.md
$ git status
On branch master
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

    new file:   README
    modified:   CONTRIBUTING.md

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

    modified:   CONTRIBUTING.md

Нима бўлди? Қизиқ, энди CONTRIBUTING.md файл икки секцияда ҳам индексланган ҳам индексланмаганлар рўйҳатида акс этиб турибди. Бу қандай бўлиши мумкин? Бундай вазият Git нинг файлларни аниқ ҳолатини яъни охирги бор берилган git add командасидаги ҳолатни индекслашини яна бир бор намойиш қилади. Агар сиз хозир юборишни (коммит) амалга оширсангиз, CONTRIBUTING.md файлнинг охирги бор git add командаси ёрдамида қўшилган ўзгартиришлари жўнатилиб git commit вақтидаги ҳолати жўнатилмайди. Сиз git add командасидан кейин ўзгартириш киритган бўлсангиз файлни охирги талқинини индекслаш учун яна git add командасини бажаришингизга тўғри келади:

$ git add CONTRIBUTING.md
$ git status
On branch master
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

    new file:   README
    modified:   CONTRIBUTING.md

Қисқа ҳолат

git status командаси натижаси тўлиқ ҳолатни кўрсатса у яна бошқа маънода ҳам ишлатилиши мумкин. Git яна қисқа ҳолат белисига эга бўлганлиги боис сиз киритган ўзгаришларингизни янада ихчамроқ кўринишда кўришингиз мумкин. Агар сиз git status -s ёки git status --short командасини чақирсангиз сиз янада яхлитланган натижани оласиз.

$ git status -s
 M README
MM Rakefile
A  lib/git.rb
M  lib/simplegit.rb
?? LICENSE.txt

Янги файллар кузатилмаётганлари ?? дан кейин, янги файлларни жўнатишга қўшилганлари A дан кейин, ўзгартирилган файллар M ва хокозо каби келтирилади. Натижа иккита майдонда чиқарилган бўлиб, чап томондаги майдон уни жўнатишга қўшилганлигини ва ўнг томондаги майдон ўзгартирилганлигини билдиради. Масалан, ушбу натижадаги README файлини ҳолатини олсак, у ўзгартирилган аммо жўнатишга тайёрланмаган, lib/simplegit.rb файли эса ҳам ўзгартирилган ҳам жўнатишга қўшилганлигини билдиради. Rakefile файли ўзгартирилган, жўнатишга қўшилган, сўнгра яна ўзгартирилган шу сабабли у жўнатишга қўшилган ва қўшилмаганлигини англатувчи устунлари иккисида ҳам ўзгаришлар бор ҳолатда.

Файлларни ҳисобга олмаслик

Қисман бўлсада сизда автоматик тарзда омборга қўшилишини ва нафақат қўшилишини балким уларни кузатилувчилар рўйҳатида ҳам кўришни истамаган файллар мавжуд бўлади. Бундай файлларга автоматик тарзда генерация қилинадиган файллар киради (турли хил журналлар, дастур йиғилиш натижалари ва ҳок.). Шундай вазиятларда сиз ана шу каби файллар учун яратилган шаблонларни ўз ичига оладиган .gitignore файлни яратишингиз мумкин. Мана .gitignore файл мисол тариқасида келтирилган:

$ cat .gitignore
*.[oa]
*~

Биринчи қатор Git га кодларни йиғиш давомида пайдо бўладиган объектли ёки архивли, “.o” ёки “.a” билан тугайдиган ихтиёрий файлларни ҳисобга олмасликни англатади. Иккинчи қатор тильда (~) билан тугайдиган барча файлларни ҳисобга олмасликни англатади. Бундай файллар кўпгина матнни таҳрирловчи дастурларда масалан Emacs дастурида вақтинчалик яратилган файлларни номлашда ишлатилади. Сиз шунингдек каталогларни (log, tmp ёки pid), автоматик яратиладиган ҳужжатларни ва бошқа турдаги файл ва каталогларни ҳам қўшишингиз мумкин. Яхши амалиётдан маълумки, ишга жиддий киришишдан олдин .gitignore файлини созлаш - омборга у ерда кўришни хоҳламаган файлларни тасодифан қўшилишидан сақлайди.

.gitignore файлида яратилаётган шаблонлар учун қуйидагича қоида қўлланилади:

  • Бўш ва # белги билан бошланувчи сатрлар ҳисобга олинмайди.

  • Стандарт glob шаблонларни қўллаш мумкин.

  • Шаблонни каталогни кўрсатиш мақсадида (/) белги билан тугатиш мумкин.

  • Акс амални билдирувчи ундов(!) белгисини қўллаб шаблонга кирмайдиганлар рўйҳатини олиш мумкин.

Glob шаблонлар бошқарувчи ифодалар тилида ёзилан содда командалар интерпретаторларидан ташкил топган. * белги 0 ёки ундан ортиқ белгига мос келади; [abc] кетма-кетлик қавс ичидаги ихтиёрий белгидан биронтасига (айни мисолда a, b ёки c); сўроқ белгиси (?) битта белгига мос келади; [0-9] интервалдаги ихтиёрий белгига мос келади (ушбу ҳолатда 0 дан 9 гача). Сиз бир гуруҳ каталоглар учун яна иккита юлдузча (asterisk) белгисини ишлатишингиз мумкин; a/**/z эҳтимол a/z, a/b/z, a/b/c/z кабиларга мосликни ўрнатиш учун ишлатилар.

Мана яна .gitignore файлидан мисол:

*.a
# номи .a билан тугайдиган файлларни ҳисобга олмаслик

!lib.a
# Лекин lib.a файлини кузатиш керак гарчан биз .a билан тугайдиган
#барча файлларни ҳисобга олмасликни буюрсакда

/TODO
# бош каталогда жойлашган фақат TODO файлни ҳисобга олмаслик бу
# subdir/TODO каби файлларга тааллуқли эмас

build/
# build/ каталогидаги барча файлларни ҳисобга олмаслик

doc/*.txt
# doc/notes.txt файлини ҳисобга олмаслик, лекин doc/server/arch.txt
# файлига бу тааллуқли эмас
Tip

GitHub ўзида сиз лойиҳа яратишни бошлаган вақтингизда сизга ва кўпгина лойиҳалар ёки тилларга мисол бўла оладиган тўлиқ рўйҳатга эга бўлган .gitignore файлга https://github.com/github/gitignore эга.

Индексланган ва индекланмаган файлларни кўриш

Агар git status командаси сизга етарлича маълумот бера олмаса ва сизни қайси файллар ўзгарганлигини билишдан ташқари яна айнан нима ўзгаргани қизиқтирса git diff командасини ишлатишингиз мумкин. Бироз кейинроқ биз git diff командаси ҳақида батафсилроқ маълумот берамиз. Сиз умуман олганда уни иккита саволга жавоб топиш учун ишлатасиз: Нимани мен ўзгартирдим ва индексламадим? Нимани мен индексладим ва қайсиларини фиксирласам бўлади? Агарда git status ушбу саволларга умумлаштирган ҳолатда жавоб берса, git diff командаси бевосита ўзгаришлар (patch) ўзини – қўшилган ва ўчирилган сатрларни кўрсатади.

Айтайлик сиз яна README файлини ўзгартирдингиз ва индексладингиз сўнгра CONTRIBUTING.md файлини ўзгартирдингизу лекин индекламадингиз. Агар сиз git status командасини ишлатсангиз сиз яна қуйидаги каби маълумотларни кўришингиз мумкин бўлади:

$ git status
On branch master
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

    new file:   README

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

    modified:   CONTRIBUTING.md

Нима ўзгартириш киритганингиз ва нимани индексламаганингизни кўришингиз учун git diff командасини аргументсиз киритинг:

$ git diff
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index 3cb747f..e445e28 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -36,6 +36,10 @@ def main
           @commit.parents[0].parents[0].parents[0]
         end

+        run_code(x, 'commits 1') do
+          git.commits.size
+        end
+
         run_code(x, 'commits 2') do
           log = git.commits('master', 15)
           log.size

Ушбу команда сизнинг ишчи каталогингизни индексни ичидаги билан солиштиради. Натижа индексланмаган ўзгаришларни кўрсатади.

Агар сиз нимани индекслаганингизни ва нималар навбатдаги жўнатишга киришини кўришни хоҳласангиз сиз git diff --staged командасини беришингиз мумкин. Ушбу команда сизнинг индексланган ўзгаришларингизни охирги жўнатишга тайёрланганлар билан солиштиради:

$ git diff --staged
diff --git a/README b/README
new file mode 100644
index 0000000..03902a1
--- /dev/null
+++ b/README
@@ -0,0 +1,4 @@
+My Project
+
+ This is my project and it is amazing.
+

Шуни таъкидлаш муҳимки git diff - ўз ўзидан охирги бор жўнатишга тайёрланганлардан кейинги ўзгаришларни кўрсатмайди у фақат индекланмаганларни кўрсатади. Бундай ҳислати уринишларни пучга чиқариши мумкин агарда сиз ҳамма ўзгаришларни индексласангизда ва кейин git diff ҳеч нарса қайтармай турса!

Бошқа мисол: айтайлик сиз CONTRIBUTING.md файлни индексладингиз ва кейин ўзгартирдингиз. git diff ни ишлатиб ушбу файлдаги индексланган ўзгартиришларни ва индексланмаганларни кўришингиз мумкин:

$ git add CONTRIBUTING.md
$ echo '# test line' >> CONTRIBUTING.md
$ git status
On branch master
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

    modified:   CONTRIBUTING.md

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

    modified:   CONTRIBUTING.md

Энди сиз git diff ни ишлатган ҳолда индексланмаган ўзгаришларни кўришингиз мумкин

$ git diff
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index e445e28..86b2f7c 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -127,3 +127,4 @@ end
 main()

 ##pp Grit::GitRuby.cache_client.stats
+# test line

шунингдек индексланганларини ҳам кўришингиз мумкин агарда git diff --cached ни ишлатсангиз:

$ git diff --cached
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index 3cb747f..e445e28 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -36,6 +36,10 @@ def main
          @commit.parents[0].parents[0].parents[0]
        end

+        run_code(x, 'commits 1') do
+          git.commits.size
+        end
+
        run_code(x, 'commits 2') do
          log = git.commits('master', 15)
          log.size
Note
Git Diff ташқи дастгоҳларда

Биз китобда git diff командасини турли хил йўллар билан ишлатилишини кўришни давом этамиз. Ушбу фарқларга қарашни яна бошқа йўллари бор бўлиб, агар сиз график кўринишни хоҳласангиз ташқи дастурни фарқларни кўриш дастурига алмаштиришингиз керак бўлади. Агар сиз git difftool ни git diff нинг ўрнига алмаштирсангиз, сиз ушбу фарқларни Araxis, emerge, vimdiff ва бошқа кўпгина дастурлардаги каби кўринишда кўришингиз мумкин бўлади. git difftool --tool-help командасини чақириб сизнинг тизимингизда қайси биридан фойдаланиш имкони борлигини кўришингиз мумкин.

Ўзгаришларни фиксирлаш

Энди индекс хоҳлаганиздек созланганидан кейин сиз ўзгаришларингизни фиксирлашингиз мумкин. Эслаб қолинг ихтиёрий яратилган ёки ўзгартирилган файллар ва таҳрирлашдан сўнг сиз git add командасини ишлатмаган барча индексланмаган файллар бу фиксирлашга кирмайди. Улар сизни дискингизда ўзгартирлган файллар орасида қолади. Бизнинг ҳолатда сиз охирги бор git status`командасини ишлатган вақтингизда кўрдингизки ҳаммаси индексланган.Бу эса сизни фиксирлашга тайёр эканлигингизни билдиради. (((git commands, status))) Сизни ўзгаришларингизни фиксирлашни энг содда усули бу `git commit командасини териш:

$ git commit

Ушбу команда сиз танлаган матн таҳрирловчисини очади. (Таҳрирловчи тизим ўзгарувчиси $EDITOR билан ўрнатилади. Сиз ўз ёқтирганингизни Иш бошланиши бўлимда кўрсатилганидек git config --global core.editor командаси ёрдамида ўрнатишингиз мумкин бўлсада одатда бу vim ёки emacs бўлади.)

Таҳрирловчида қуйидаги матн намойиш этилган бўлади. (бу Vim нинг ойнасидан мисол):

# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
# On branch master
# Changes to be committed:
#	new file:   README
#	modified:   CONTRIBUTING.md
#
~
~
~
".git/COMMIT_EDITMSG" 9L, 283C

Сиз кўришингиз мумкинки фиксирлашнинг шарҳи одатда git status командаси ишининг натижасининг шарҳларини ва юқоридан битта бўш сатрни ўз ичига олади. Сиз ушбу шарҳларни ўчириб уни ўрнига ўз ҳабарларингизни киритишингиз ёки уларни нимани фиксирлаётганингизни англатиб туриши учун қолдиришингиз мумкин. (Нимани ўзгартирганингизни янада батафсилроқ эсга солиб туриши учун сиз аргумент -v ни git commit командасига беришингиз мумкин. Бу шунга олиб келадики, изоҳда сиз киритган ўзгаришларни фарқи diff ҳам киритилган бўлади. Шу тарзда сиз нималар қилинганини кўришингиз мумкин бўлади.) Қачон сиз таҳрирлаш ойнасидан чиқиб кетар экансиз Git сизнинг фиксирлаганингизни ушбу хабар билан яратади (изоҳлар ва diff ларни чиқаришни ўчирган ҳолда).

Бошқа усул – сиз шарҳингизни командалар сатридан қуйидаги мисолда келтирилганидек commit командаси билан биргаликда –m параметридан сўнг ёзиб киритишингиз мумкин:

$ git commit -m "Story 182: Fix benchmarks for speed"
[master 463dc4f] Story 182: Fix benchmarks for speed
 2 files changed, 2 insertions(+)
 create mode 100644 README

Шундай қилиб сиз ўзингизни биринчи фиксирлашингизни яратдингиз! Сиз кўриб турибсизки фиксирлаш командаси сизга кўп бўлмаган ўз ҳақидаги маълумотни кўрсатди:қайси тармоққа сиз фиксирлашни амалга оширдингиз (master), ушбу фиксирлаш(463dc4f)нинг SHA-1 назорат йиғиндиси қанақа, қанча файлларга ўзгартириш киритилди ва шунингдек ушбу фиксирлашда қўшилган/ўчирилган сатрлар статистикасини.

Эслаб қолинг фиксирлаш сизни индексингизни суръатини сақлаб қолади. Нимани индекламаган бўлсангиз у ишчи каталогда ўзгартирилганлар орасида ётади; сиз яна битта фиксирлашни амалга ошириб ушбу ўзгаришларни омборга қўшишингиз мумкин. Ҳар сафар қачон сиз фиксирлашни амалга ошираркансиз сиз ўз лойиҳангизни суръатини сақлаб қўясиз, ушбу сақлашлар кейинчалик қайта тиклаш ёки хозирги ҳолат билан солиштириш учун хизмат қилади.

Индекслашларни ўтказиб юбориш

Индекслаш сиз хоҳлагандек фиксирлашлар учун анча қулайлик яратсада иш жараёнида сиз кутгандан кўпроқ вақт олиши билан бошқача таъсир кўрсатиши мумкин. Агар сизда индекслаш қадамини ташлаб кетиш хоҳиши бўлса, Git сизга оддий учулни тақдим этади. -a параметрини git commit командасига қўшиш Git ни автоматик тарзда охирги фиксирлашдан кейинги кузатилаётган ҳар бир файлни индекслашга буюради ва сизга git add командасини бермасдан фиксирлаш жараёнини амалга ошириш имконини беради:

$ git status
On branch master
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

    modified:   CONTRIBUTING.md

no changes added to commit (use "git add" and/or "git commit -a")
$ git commit -a -m 'added new benchmarks'
[master 83e38c7] added new benchmarks
 1 file changed, 5 insertions(+), 0 deletions(-)

Шунга эътибор берингки, ушбу ҳолатда сизга “CONTRIBUTING.md” файлини фиксирлашдан олдин git add командасини бериш шарт бўлмади.

Файлларни ўчириш

Git дан файлларни ўчириш учун уни кузатилаётган файллар орасидан (аниқроқ қилиб айтганда сизнинг индексингиздан ўчириш керак) ўчириш сўнг фиксирлашни амалга ошириш зарур. Буни git rm командаси амалга оширади.Ушбу команда файлингизни ишчи каталогингиздан ҳам ўчиради ва сиз уни кейинги сафар “кузатилаётганлар” орасида ҳам кўрмайсиз.

Агар сиз уни оддийгина ишчи каталогидан ўчириб қўя қолсангиз git status бериб биз у (“Ўзгартирилган лекин янгиланмаган” – индексланмаган деб ўқинг) секциясида кўрсатилаётганини кўрамиз:

$ rm grit.gemspec
$ git status
On branch master
Changes not staged for commit:
  (use "git add/rm <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

    deleted:    grit.gemspec

no changes added to commit (use "git add" and/or "git commit -a")

Сўнг агар сиз git rm командасини берсангиз файлни ўчириш индексга тушади:

$ git rm grit.gemspec
rm 'grit.gemspec'
$ git status
On branch master
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

    deleted:    grit.gemspec

Навбатдаги фиксирлашдан сўнг файл йўқ бўлиб кетади ва энди кузатилмайди. Агар сиз файлни ўчиришдан олдин уни ўзгартиришга ва индекслашга ҳам улгурган бўлсангиз у ҳолда –f параметри ёрдамида мажбурий ўчириш командасини беришингиз керак бўлади. Бу хавфсизликни ошириш мақсадида қилинган бўлиб, Git дан қайта тиклаб бўлмайдиган ва ҳалигача ҳолатлар суръатига қўшилмаган файлларни беҳосдан ўчиб кетишидан сақлайди.

Яна бошқа сиз бажаришни хоҳлашингиз мумкин бўлган жараён борки – бу файлни сизни ишчи каталогингизда қолдирган ҳолатда индексдан ўчириш. Бошқа сўзлар билан айтганда сиз сергак Git кузатувидан файлингизни озод қилиб винчестерингизда қолдиришингиз мумкин. Бу асосан файлингизни .gitignore файлига киритишни ёддан чиқарганингизда ва адашиб бир қанча “лог” ёки компиляциялар бир қанча файлларини индекслаб қўйганингизда фойда беради. Буни амалга ошириш учун --cached опцияни ишлатинг:

$ git rm --cached README

git rm командасига файлларни, каталогларни ёки glob-шаблонларни бериш мумкин. Бу сизга қуйидагича командаларни амалга ошириш имконини беради: That means you can do things such as

$ git rm log/\*.log

Note the backslash (\) in front of the *. * дан олдинги тескари слешга(\) эътибор беринг. Бу зарур, чунки Git сиз киритган командаларингиз орасига ўз файллар номи билан ишлаш унсурини ишлатади. Ушбу команда log/ .log кенгайтмали файлларни ўчиради. Ёки сиз бундай қилишингиз мумкин:

$ git rm \*~

Ушбу команда барча номи ~ белгиси билан тугайдиган барча файлларни ўчиради.

Файлларни бошқа жойга кўчириш

Бошқа талқинларни бошқарувчи тизимлар каби Git бевосита файлларнинг кўчирилишини кузатмайди. Агар сиз файлни номини алмаштирсангиз бу ҳақда Git да ҳеч қандай метамаълумот бўлмайди. Бироқ Git файлларни кўчириш жараёнини бўлиб ўтганини аниқлашда етарли даражада ақлли. Биз файлларни кўчиришни аниқлашни бироз кейинроқ кўрамиз. Шу туфайли Git нинг mv командаси бир қанча бошқачароқ кўринишга эга. Агар сиз файл номини алмаштиришни хоҳлаётган бўлсангиз сиз қуйидаги каби йўл тутишингиз мумкин:

$ git mv file_from file_to

ва бу жуда яхши ишлайди. Аслида, агар сиз шунга ўхшаш командани бажариб сўнг ҳолатни қарасангиз, Git ни файл номини ўзгартириш жараёни бўлиб ўтган деб ҳисоблаётганини кўрасиз:

$ git mv README.md README
$ git status
On branch master
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

    renamed:    README.md -> README

Бироқ у қуйидаги командаларни бажарилишига эквивалент:

$ mv README.md README
$ git rm README.md
$ git add README

Git қайта номлаш бўлганлигини яққол бўлмаган ҳолатда аниқлайди ва файлни сиз бу усулда номлайсизми ёки mv командасини ишлатиб номлайсизми муҳим эмас. Ягона фарқ шуки mv – учта команданинг ўрнига битта команда сифатида ишлатилаябди ва бу қулайлик учун яратилган фукция. Муҳими бошқа нарса – файл номини ўзгартириш учун сиз ўзингизга қулай услубингизни қўллашингиз ва сўнг фиксирлашдан олдин add/rm командасини ишлатишингиз мумкин.

scroll-to-top