-
1. Иш бошланиши
- 1.1 Талқинларни бошқариш ҳақида
- 1.2 Git нинг қисқача тарихи
- 1.3 Git асоси
- 1.4 Командалар сатри
- 1.5 Git ни ўрнатиш
- 1.6 Git да биринчи созлашлар
- 1.7 Қандай ёрдам олиш мумкин?
- 1.8 Хулосалар
-
2. Git асослари
-
3. Git да тармоқланиш
-
4. Git серверда
- 4.1 The Protocols
- 4.2 Getting Git on a Server
- 4.3 Sizning SSH ochiq (public) kalitingizni generatsiyalash
- 4.4 Setting Up the Server
- 4.5 Git Daemon
- 4.6 Smart HTTP
- 4.7 GitWeb
- 4.8 GitLab
- 4.9 Third Party Hosted Options
- 4.10 Хулосалар
-
5. Distributed Git
- 5.1 Distributed Workflows
- 5.2 Contributing to a Project
- 5.3 Maintaining a Project
- 5.4 Summary
-
6. GitHub
-
7. Git Tools
- 7.1 Revision Selection
- 7.2 Interactive Staging
- 7.3 Stashing and Cleaning
- 7.4 Signing Your Work
- 7.5 Searching
- 7.6 Rewriting History
- 7.7 Reset Demystified
- 7.8 Advanced Merging
- 7.9 Rerere
- 7.10 Debugging with Git
- 7.11 Qism modullar (Submodule)
- 7.12 Bundling
- 7.13 Replace
- 7.14 Credential Storage
- 7.15 Summary
-
8. Customizing Git
- 8.1 Git Configuration
- 8.2 Git Attributes
- 8.3 Git Hooks
- 8.4 An Example Git-Enforced Policy
- 8.5 Summary
-
9. Git and Other Systems
- 9.1 Git as a Client
- 9.2 Migrating to Git
- 9.3 Summary
-
10. Git Internals
- 10.1 Plumbing and Porcelain
- 10.2 Git Objects
- 10.3 Git References
- 10.4 Packfiles
- 10.5 The Refspec
- 10.6 Transfer Protocols
- 10.7 Maintenance and Data Recovery
- 10.8 Environment Variables
- 10.9 Summary
-
A1. Appendix A: Git in Other Environments
- A1.1 Graphical Interfaces
- A1.2 Git in Visual Studio
- A1.3 Git in Eclipse
- A1.4 Git in Bash
- A1.5 Git in Zsh
- A1.6 Git in Powershell
- A1.7 Summary
-
A2. Appendix B: Embedding Git in your Applications
- A2.1 Command-line Git
- A2.2 Libgit2
- A2.3 JGit
-
A3. Appendix C: Git Commands
- A3.1 Setup and Config
- A3.2 Getting and Creating Projects
- A3.3 Basic Snapshotting
- A3.4 Branching and Merging
- A3.5 Sharing and Updating Projects
- A3.6 Inspection and Comparison
- A3.7 Debugging
- A3.8 Patching
- A3.9 Email
- A3.10 External Systems
- A3.11 Administration
- A3.12 Plumbing Commands
2.2 Git асослари - Ўзгаришларни омборга ёзиш
Ўзгаришларни омборга ёзиш
Шундай қилиб сизда Git нинг ҳақиқий омбори ва қандайдир лойиҳа учун ишчи файллар нусҳаси мавжуд. Сиз лойиҳа билан ишлаш давомида керакли жойда сақлаш пайтида бир қанча ўзгаришлар ва ушбу ўзгаришларни ҳолатини “суръат” (snapshots)га олиб фиксирлашингиз керак.
Эсда тутинг ишчи каталогигингиздаги ҳар бир файл икки ҳолатдан бирида: талқин кузатуви остида ёки кузатилмаётган ҳолатда. Кузатилаётган файллар – бу лойиҳанинг охирги формадаги ҳолати файллари (snapshot). Улар ўзгартирилмаган, ўзгартирилган ёки жўнатиш учун тайёрланган(staged) бўлиши мумкин. Кузатилмайдиган файллар бу ишчи каталогингиздаги кузатилаётган файлларга кирмайдиган қолган барча файллардир. Қачон сиз биринчи бор омборни клондаштирсангиз, барча файллар кузатилаётган ва ўзгартирилмаган бўлади, чунки сиз уларни эндигина сақланувчи омбордан олдингиз (checked them out) ва ҳеч нимани ўзгартирганингиз йўқ.
Сиз файлларни таҳрирлашингиз биланоқ Git уларни ўзгаотирилганлар деб қарай бошлайди. Чунки сиз охирги жўнатилгандан кейин яна ўзгартириш киритган ҳисобланаябсиз. Сиз ушбу ўзгаришларни индекслайсиз(stage) ва кейин барча индекланган ўзгаришларни фиксирлайсиз, шу тарзда жараён такрорланади. Бу жараённинг тасвири қуйида келтирилган:
![Сизнинг файлларингизни иш жараёнидаги ҳолатларининг цикл ҳолати.](png/lifecycle.png)
Файлларингиз ҳолатини аниқлаш
Қайси файл қанақа ҳолатда эканлигини аниқлаш учун асосий ускуна – 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 ўзида сиз лойиҳа яратишни бошлаган вақтингизда сизга ва кўпгина лойиҳалар ёки тилларга мисол бўла оладиган тўлиқ рўйҳатга эга бўлган |
Индексланган ва индекланмаган файлларни кўриш
Агар 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 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 командасини ишлатишингиз мумкин.