Ачааллж байна...
Өмнөх хичээлд бид repository-д нүүр хуудас болох README өгсөн. Одоо нүүр хуудасны ард байгаа зүйлсийг цэгцлэх цаг болжээ. Repository-д ямар файл байх ёстой, ямар нь байх ёсгүй вэ? Файлуудыг хэрхэн нэрлэж, фолдерт хэрхэн байрлуулах вэ? Хэрвээ буруу файл аль хэдийн commit хийгдсэн бол яаж арилгах вэ? Энэ хичээл эдгээр асуултуудад хариулна. Бид эхлээд цэгцгүй repository-ийн жишээг хараад, түүнийг алхам алхмаар цэгцтэй болгоно. Дараа нь сурсан зүйлээ зарлагын бүртгэлдээ хэрэглэж, өмнөх сургалтаас мэдэх requirements.txt болон шинэ LICENSE файлыг нэмнэ.
Энэ хичээлд гурван шинэ command сурна. git ls-files нь Git яг ямар файлуудыг хянаж байгааг, өөрөөр хэлбэл GitHub дээр юу байгааг харуулдаг. git rm нь файлыг устгаж, тэр устгалтыг шууд ачааны талбай руу оруулдаг. git mv нь файлын нэрийг сольж, Git-д тэр нь шинэ файл биш, нэр нь солигдсон хуучин файл гэдгийг ойлгуулдаг. Эдгээр нь repository цэвэрлэх ажлын үндсэн хэрэгслүүд юм.
Сайн дэлгүүрийг төсөөлөөрэй. Үйлчлүүлэгчийн харах лангуун дээр зөвхөн худалдаалж буй бараа, эмх цэгцтэй, шошготой байрлана. Хайрцаг, хаягдал, хуучин үнийн шошго, ажилчдын хувийн эд зүйлс бүгд ар талын агуулахад, үйлчлүүлэгчийн нүднээс далд байна. Лангуу цэвэр байх нь дэлгүүрийн эзэн эмх цэгцтэй, итгэж болохуйц хүн гэдгийг илтгэдэг. Харин бараа, хог, хувийн зүйлс холилдсон лангуу хэчнээн сайн бараатай байсан ч үйлчлүүлэгчийг үргээдэг.
Таны GitHub дээрх repository бол дэлгүүрийн лангуу. Тэнд зөвхөн таны "барааны" хэсэг, өөрөөр хэлбэл код, тохиргоо, баримт бичиг байх ёстой. Таны компьютер дээрх фолдер бол агуулах: тэнд venv, түр файлууд, хувийн өгөгдөл, туршилтын ноорог бүгд байж болно. .gitignore бол лангуу ба агуулахын хоорондох хаалга юм. Энэ хичээл таны лангууг цэвэр байлгах дадлын тухай.
Өмнө
Өмнөх сургалтыг дөнгөж дуусгасан нэгэн суралцагч төслөө ямар ч .gitignore-гүйгээр, git add .-ээр GitHub руу илгээсэн гэж бодъё. Түүний repository-д дараах файлууд байна.
expense-tracker/
__pycache__/
report.cpython-313.pyc
storage.cpython-313.pyc
venv/
(мянга мянган файл)
.env
.vscode/
settings.json
Main.py
main_old.py
main_final.py
report.py
storage.py
test.py
test2.py
expenses.json
expenses_backup.json
my real expenses 2026.json
screenshot.png
notes.txtЭнэ жагсаалтыг дэлгүүрийн лангуу гэж хараад мөр бүрийн тухай асуултуудыг тавьцгаая. Юу нь бараа, юу нь хог вэ?
pycache/ ба venv/ бол 2.4 дүгээр хичээлээс таньж байгаа хог: Python-ий түр файлууд болон дахин үүсгэж болох виртуал орчин. Тэд repository-г томруулж, өөр компьютер дээр ашиггүй. .env бол хамгийн ноцтой асуудал: тэнд нууц түлхүүр байж болох бөгөөд энэ repository public бол тэр түлхүүр аль хэдийн ил гарсан. 2.4 дүгээр хичээлийн дүрмээр тэр түлхүүрийг заавал солих ёстой.
.vscode/ фолдер VS Code-ийн таны компьютер дээрх тохиргоог хадгалдаг. Зарим баг үүнийг санаатайгаар хуваалцдаг ч ихэнх хувийн төсөлд энэ нь зөвхөн танд хамаатай тохиргоо бөгөөд repository-д хэрэггүй.
main_old.py ба main_final.py бол Бүлэг 1-ийн “final_v2_REAL” асуудлын яг жишээ. Энэ хүн Git ашиглаж байгаа хэрнээ хуучин хувилбаруудаа гараар хуулбарлан хадгалсаар байна. Git-ийн түүх бол хуучин хувилбаруудын жинхэнэ гэр: git log болон git diff ямар ч хуучин хувилбарыг харуулж чадна. Тиймээс эдгээр хуулбар файлууд илүүц бөгөөд аль нь жинхэнэ программ болохыг төөрөгдүүлдэг. Мөн Main.py том үсгээр эхэлсэн нь Python-ий заншлаас зөрж байна: Python файлын нэрийг жижиг үсгээр, үгсийг доогуур зураасаар холбож бичдэг.
test.py ба test2.py бол ихэвчлэн хурдан туршилт хийхэд үүсгэсэн ноорог файлууд. Тэдгээрийн нэр юу ч хэлэхгүй бөгөөд Түвшин 3-т сурах жинхэнэ тестүүдтэй андуурагдах эрсдэлтэй.
expenses_backup.json нь бас нэг гар хуулбар. “my real expenses 2026.json” нь хоёр асуудалтай: нэрэндээ зай агуулж байгаа тул command бичихэд хүндрэлтэй, хамгийн гол нь нэрээсээ харахад хувийн жинхэнэ мэдээлэл агуулж байна. screenshot.png болон notes.txt нь эзнийхээ хувийн тэмдэглэл, программд огт хамаагүй.
Дараа
Одоо ижил төслийг цэгцтэй болгосон хувилбарыг харъя.
expense-tracker/
data/
expenses.json
.gitignore
LICENSE
README.md
main.py
report.py
requirements.txt
storage.pyЯлгаа маш тод. Нийт найман файл, тус бүр нь тодорхой зорилготой. Код нь гурван файлд, бүгд жижиг үсгээр нэрлэгдсэн. Өгөгдөл data/ фолдерт, зөвхөн жишээ өгөгдөлтэй ганц файл. Төслийн үндсэн фолдерт дөрвөн "мета" файл байна: README.md уншигчдад зориулагдсан, .gitignore Git-д зориулагдсан, requirements.txt шаардлагатай package-уудыг, LICENSE хэрэглэх эрхийг тодорхойлдог.
Хог хаашаа явсан бэ? Ихэнх нь устаагүй, зүгээр л лангуунаас агуулах руу шилжсэн. venv, pycache, .env, .vscode .gitignore-д нэмэгдсэн тул эзний компьютер дээр хэвээр байгаа ч repository-д харагдахгүй. Хувийн өгөгдлийн файл мөн .gitignore-д орсон. Хуучин хувилбарын хуулбарууд болон ноорог файлууд бүрмөсөн устсан, учир нь тэдгээрийн үнэ цэнтэй хэсэг Git-ийн түүхэнд аль хэдийн бий. Хувийн тэмдэглэл, зураг эзнийхээ өөр фолдер руу зөөгдсөн.
Энэ жишээнээс аль ч төсөлд хэрэглэж болох шалгах жагсаалт гарч ирж байна. Repository бүрийг энэ асуултуудаар шалгаарай.
Нэгдүгээрт, автоматаар үүсдэг зүйл байна уу? pycache, venv, .pyc файлууд, log файлууд. Тэдгээр нь .gitignore-д байх ёстой. Хоёрдугаарт, нууц эсвэл хувийн мэдээлэл байна уу? .env, нууц үг, хувийн өгөгдөл. Тэдгээр нь repository-д хэзээ ч байх ёсгүй. Гуравдугаарт, гар хуулбар байна уу? old, backup, final, v2 гэсэн нэртэй файлууд. Git-ийн түүх тэдгээрийг орлодог тул устгана. Дөрөвдүгээрт, нэр нь юу ч хэлэхгүй файл байна уу? test2.py, untitled.py, asdf.txt. Нэрийг нь утгатай болгох эсвэл устгана. Тавдугаарт, нэрнүүд нэг хэв маягтай юу? Python файлууд жижиг үсгээр, үгс доогуур зураасаар, зайгүй. Зургадугаарт, үндсэн файлууд байна уу? README.md, .gitignore, шаардлагатай бол requirements.txt, LICENSE.
Фолдерын бүтцийн тухай нэг шударга зөвлөгөө: жижиг төсөлд хэт олон фолдер хэрэггүй. Манай зарлагын бүртгэл шиг цөөн файлтай төсөлд кодыг үндсэн фолдерт, өгөгдлийг data/ фолдерт байлгах нь хангалттай бөгөөд ойлгомжтой. Түвшин 3-т бид тест бичихдээ tests/ фолдер нэмнэ. Том төслүүд кодоо тусдаа package фолдерт байрлуулдаг ч энэ нь төсөл томорч, хэрэгцээ гарахад л хэрэгтэй алхам. Бүтэц төслийн хэмжээнд тохирох ёстой, урьдчилан төвөгтэй болгох шаардлагагүй.
Одоо repository цэвэрлэх Git-ийн хэрэгслүүдийг практикт туршъя. Зарлагын бүртгэлдээ илүүц зүйл байхгүй тул бид Түвшин 1-ийн git-dadlaga фолдер дээр туршина. Тэр нь дадлагын фолдер тул эвдэхээс айх хэрэггүй. VS Code-д git-dadlaga фолдероо нээнэ үү.
Git юу хянаж байгааг харах: git ls-files
Command:
git ls-filesГаралт:
.env.example
.gitignore
angilal.py
data/notes.txt
tsalin.py
zarlaga.py“ls-files” нь "файлуудыг жагсаах" гэсэн утгатай бөгөөд энэ command Git-ийн хянаж буй бүх файлыг харуулдаг. Ердийн ls-ээс ялгаатай нь энд venv, pycache, .env харагдахгүй, учир нь тэдгээр нь хянагддаггүй. Өөрөөр хэлбэл энэ жагсаалт бол таны лангуу: хэрвээ энэ repository GitHub дээр байсан бол яг эдгээр файлууд л тэнд харагдах байсан. Repository цэвэрлэхийн өмнө энэ жагсаалтыг уншиж, мөр бүрийг дээрх шалгах жагсаалтаар шалгах нь хамгийн сайн эхлэл. git status юу өөрчлөгдсөнийг хэлдэг бол git ls-files юу хадгалагдаж байгааг хэлдэг.
Файлын нэр солих: git mv
tsalin.py-ийн нэрийг илүү ойлгомжтой salary.py болгоё.
Command:
git mv tsalin.py salary.py
git statusГаралт:
On branch main
Changes to be committed:
(use "git restore --staged <file>..." to unstage)
renamed: tsalin.py -> salary.py“git mv” нь “move” буюу "зөөх, нэр солих" гэсэн утгатай. Энэ command хоёр зүйлийг нэг дор хийсэн: компьютер дээр файлын нэрийг сольсон, мөн тэр өөрчлөлтийг шууд ачааны талбай руу оруулсан. Status-д “renamed: tsalin.py -> salary.py” буюу "нэр солигдсон" гэж харагдаж байна. Git энэ нь хуучин файл устаж шинэ файл үүссэн биш, нэг файлын нэр солигдсон гэдгийг ойлгожээ. Энэ нь чухал, учир нь файлын бүх түүх шинэ нэр рүү шилждэг.
Хэрвээ та VS Code-ийн Explorer-оор нэр сольсон бол Git эхлээд үүнийг “tsalin.py устсан, salary.py шинэ untracked файл” гэж харна. Хоёуланг нь git add-ээр ачааны талбай руу оруулбал Git агуулга нь ижил гэдгийг таньж, мөн “renamed” гэж харуулна. Тиймээс аль ч арга ажилладаг, git mv зүгээр л нэг алхмаар хийдэг.
Файл устгах: git rm
data/notes.txt нь хувийн тэмдэглэл бөгөөд repository-д хэрэггүй гэж үзье.
Command:
git rm data/notes.txt
git statusГаралт:
rm 'data/notes.txt'
On branch main
Changes to be committed:
(use "git restore --staged <file>..." to unstage)
deleted: data/notes.txt
renamed: tsalin.py -> salary.py“git rm” нь “remove” буюу "хасах" гэсэн утгатай. Эхний мөр “rm ‘data/notes.txt’” нь Git тэр файлыг устгасныг баталж байна. git mv-тэй адил энэ command ч хоёр зүйлийг нэг дор хийсэн: файлыг компьютероос устгасан, мөн устгалтыг ачааны талбай руу оруулсан. Status-д “deleted:” гэж харагдаж байна. VS Code-ийн Explorer-д data фолдер бүрмөсөн алга болсон байх болно, учир нь тэр дотор өөр файл үлдээгүй, Git хоосон фолдерыг хянадаггүй гэдгийг 2.1 дүгээр хичээлээс санаж байгаа.
git rm болон 2.4 дүгээр хичээлийн git rm --cached-ийн ялгааг тодорхой санаарай. git rm файлыг Git-ээс ч, таны компьютероос ч устгадаг. git rm --cached файлыг зөвхөн Git-ийн хяналтаас хасаж, таны компьютер дээр үлдээдэг. Хог, хуучин хуулбар зэрэг огт хэрэггүй файлуудад git rm, харин танд хэрэгтэй ч repository-д байх ёсгүй файлуудад, жишээ нь санамсаргүй commit хийсэн .env-д git rm --cached ашиглана. Мөн устгасан файл ч Git-ийн түүхэнд үлддэг: хэрэгтэй болбол хуучин commit-оос сэргээж болно.
Command:
git commit -m "Rename salary script and remove notes"Гаралт:
[main 0f7a3c5] Rename salary script and remove notes
2 files changed, 3 deletions(-)
delete mode 100644 data/notes.txt
rename tsalin.py => salary.py (100%)Сүүлийн хоёр мөр шинэ. “delete mode” нь файл устгагдсаныг, “rename tsalin.py => salary.py (100%)” нь нэр солигдсоныг заана. Хаалтан доторх “100%” нь шинэ файл хуучинтайгаа агуулгаараа 100% ижил гэсэн утгатай: зөвхөн нэр өөрчлөгдсөн. Хэрвээ нэр солихын зэрэгцээ агуулгыг нь бага зэрэг өөрчилсөн бол энэ тоо бага байх байсан.
Одоо зарлагын бүртгэл рүүгээ буцаж, шалгах жагсаалтыг хэрэглэе. Гэрийн компьютерийн expense-tracker фолдероо VS Code-д нээж, эхлээд pull хийнэ үү.
Command:
git pull
git ls-filesГаралт:
Already up to date.
.gitignore
README.md
data/expenses.json
formatting.py
main.py
report.py
storage.pydata/expenses.json-ийг .gitignore-д нэмсэн бол тэр жагсаалтад харагдахгүй. Жагсаалтыг шалгах жагсаалтаар уншъя: автоматаар үүсдэг зүйл алга, нууц мэдээлэл алга, гар хуулбар алга, нэрнүүд ойлгомжтой, нэг хэв маягтай. Түвшин 1-ээс хойш бид энэ төслийг зөв дадлаар хөтөлсөн тул лангуу аль хэдийн цэвэр байна. Дутуу байгаа нь шалгах жагсаалтын сүүлийн асуултын хоёр файл: requirements.txt ба LICENSE.
requirements.txt
Өмнөх сургалтаас санаж байгаачлан requirements.txt нь программд шаардлагатай гадны package-уудын жагсаалт юм. Тэр файл байвал таны repository-г clone хийсэн хүн шинэ venv үүсгээд pip install -r requirements.txt гэсэн ганц command-аар бүх package-ийг суулгана. Venv-ийг .gitignore-д нэмж, repository-д оруулдаггүйн шалтгаан нь яг энэ: package-уудын жагсаалт хангалттай, package-ууд өөрсдөө хэрэггүй.
Таны программ ямар package ашиглаж байгааг шалгая. Эхлээд venv-ээ идэвхжүүлнэ.
Command:
.\venv\Scripts\Activate.ps1
pip freezeГаралт:
(venv) PS C:\Users\Bat\expense-tracker>Venv идэвхжсэн тул terminal-ын мөрийн эхэнд “(venv)” гарч ирсэн. pip freeze нь venv-д суусан бүх package-ийг жагсаадаг бөгөөд энд юу ч хэвлэсэнгүй. Манай жишээ программ зөвхөн Python-ий стандарт сангийн json модулийг ашигладаг тул гадны package огт хэрэггүй. Хэрвээ таны программ package ашигладаг бол энд “requests==2.32.3” гэх мэт мөрүүд харагдана.
Package хэрэггүй ч requirements.txt файлыг үүсгэх нь сайн дадал. Энэ нь "энэ төсөл шаардлагаа аль хэдийн тодорхойлсон" гэдгийг уншигчид болон хэрэгслүүдэд мэдэгддэг. Мөн Түвшин 3-т бид pytest суулгахад энэ файл шууд хэрэг болно. VS Code-д requirements.txt нэртэй шинэ файл үүсгэж дараах мөрийг бичнэ үү.
# No external packages yet“#”-ээр эхэлсэн мөрийг pip тайлбар гэж үздэг тул энэ файл бүрэн хүчинтэй requirements файл. Хэрвээ таны программ package ашигладаг бол файлыг гараар бичихийн оронд дараах command-аар үүсгэнэ үү.
Command:
pip freeze | Out-File -Encoding utf8 requirements.txtЭнэ command-ын тухай Түгээмэл алдаанууд хэсэгт нэг чухал тайлбар бий.
LICENSE
LICENSE файлын тухай нэг шударга тайлбар өгье. Хэрвээ таны repository-д лиценз байхгүй бол таны код автоматаар зохиогчийн эрхээр хамгаалагдана: хүмүүс түүнийг GitHub дээр харж, уншиж болох ч хуулийн хувьд түүнийг хуулж, өөрчилж, өөрсдийн төсөлд ашиглах эрхгүй. Хэрвээ та бусдыг таны кодыг чөлөөтэй ашиглахыг зөвшөөрч байгаа бол лиценз нэмэх хэрэгтэй. Хамгийн түгээмэл, энгийн нь MIT лиценз бөгөөд энэ нь "хэн ч энэ кодыг юу ч хийхэд ашиглаж болно, гагцхүү зохиогчийн нэр болон лицензийн текстийг хадгална, кодын алдааны төлөө зохиогч хариуцлага хүлээхгүй" гэсэн утгатай. Энэ бол хуулийн зөвлөгөө биш, зөвхөн ерөнхий ойлголт. Арилжааны эсвэл эмзэг төсөлд лиценз сонгохдоо нарийвчлан судлах шаардлагатай. Сургалтын төсөлд MIT бол хамгийн түгээмэл сонголт.
GitHub лиценз нэмэхийг маш хялбар болгосон. Browser дээр repository хуудсаа нээж, файлуудын жагсаалтын дээр “Add file” товчийг дараад “Create new file” сонгоно уу. Файлын нэрийн талбарт LICENSE гэж бичихэд баруун талд “Choose a license template” буюу "лицензийн загвар сонгох" товч гарч ирнэ. Түүнийг дарж зүүн талын жагсаалтаас “MIT License” сонгоно уу. GitHub таны нэр болон оныг автоматаар бөглөсөн лицензийн текстийг харуулна. “Review and submit” дараад, дараа нь commit хийх товчийг дарж хадгална уу.
[Зураг: файлын нэрэнд LICENSE бичихэд гарч ирэх “Choose a license template” товч]
[Зураг: MIT License сонгосон загварын хуудас]
Одоо нэг чухал зүйлийг анзаараарай: та GitHub дээр шууд commit хийсэн. 4.4 дүгээр хичээлийн дүрмээр гэрийн компьютер одоо хоцорсон байна. Тиймээс дараагийн ажлынхаа өмнө заавал pull хийнэ. Энэ бол 4.4 дүгээр хичээлийн дадлын бодит хэрэглээ.
Command:
git pullГаралт (сүүлийн мөрүүд):
Updating 7c4e9a2..a91d5f6
Fast-forward
LICENSE | 21 +++++++++++++++++++++
1 file changed, 21 insertions(+)
create mode 100644 LICENSELICENSE файл таны компьютерт ирлээ.
README-г шинэчилж, бүгдийг илгээх
README-ийн төгсгөлд лицензийн тухай богино хэсэг нэмэх нь заншил. README.md-г нээж, төгсгөлд нь дараахыг нэмнэ үү.
markdown
## License
MIT. See the `LICENSE` file for details.Command:
git add requirements.txt README.md
git commit -m "Add requirements file and license section"
git pushГаралт (эхний мөрүүд):
[main 3e6b8d1] Add requirements file and license section
2 files changed, 5 insertions(+)
create mode 100644 requirements.txtGitHub хуудсаа дахин ачаалбал файлуудын жагсаалтад LICENSE болон requirements.txt нэмэгдсэн байна. Мөн баруун талын тайлбар хэсэгт GitHub лицензийг таньж “MIT license” гэсэн тэмдэг харуулна. Таны repository одоо мэргэжлийн төслийн бүх үндсэн файлтай боллоо.
Хүсвэл өмнөх сургалтын бусад төслүүдээ, жишээ нь цаг агаарын программ эсвэл номын сангийн системээ, 3.4 дүгээр хичээлийн "Нэмэлт боломжууд" хэсэгт Git-д оруулсан бол тэдгээрт git ls-files-ээр шалгах жагсаалтыг хэрэглэж үзээрэй. Гар хуулбар, утгагүй нэртэй файл, хог байна уу? Олдвол git rm болон git mv-ээр цэвэрлээд commit хийгээрэй. Тусдаа төсөл бүрийг цэвэрлэх нь дадлыг улам бататгана.
requirements.txt-ийг Git хоёртын файл гэж харах. Хэрвээ та pip freeze > requirements.txt гэж “>” тэмдгээр файл үүсгэсэн бол дараа нь git diff хийхэд дараах мессеж гарч болно.
diff --git a/requirements.txt b/requirements.txt
Binary files a/requirements.txt and b/requirements.txt differ“Binary files differ” нь "хоёртын файлууд ялгаатай" гэсэн утгатай: Git энэ файлыг текст биш, зураг шиг хоёртын файл гэж үзэж байна. Шалтгаан нь Windows-ийн анхдагч PowerShell “>” тэмдгээр файл бичихдээ UTF-16 гэдэг кодчилол хэрэглэдэг бөгөөд Git тэр кодчилолыг текст гэж танихгүй. Тиймээс бид дээр Out-File -Encoding utf8 ашигласан, энэ нь файлыг Git-ийн ойлгодог UTF-8 кодчилолоор бичнэ. Хэрвээ файл аль хэдийн буруу кодчилолтой бол дээрх command-аар дахин үүсгээд commit хийнэ үү. VS Code-ийн доод мөрөнд файлын кодчилол харагддаг тул “UTF-16 LE” гэж байвал энэ асуудал байна гэсэн үг.
Venv идэвхжүүлэх үед алдаа гарах. Хэрвээ .\venv\Scripts\Activate.ps1 бичихэд “running scripts is disabled on this system” буюу "энэ системд скрипт ажиллуулах хориотой" гэсэн утгатай улаан алдаа гарвал энэ нь Windows-ийн хамгаалалтын тохиргоо. Өмнөх сургалтын venv-ийн хичээлд энэ асуудлыг шийдсэн бөгөөд шийдэл нь Set-ExecutionPolicy -Scope CurrentUser RemoteSigned command юм. Энэ тохиргоо зөвхөн таны хэрэглэгчид хамаарна.
git rm хийсэн файлаа буцааж авах. Хэрвээ та git rm-ээр буруу файл устгасан бөгөөд хараахан commit хийгээгүй бол 2.5 дугаар хичээлийн хэрэгслүүдээр буцаана. Эхлээд git restore --staged <файл>-аар устгалтыг ачааны талбайгаас гаргаж, дараа нь git restore <файл>-аар файлыг сүүлийн commit-оос сэргээнэ. Хэрвээ аль хэдийн commit хийсэн бол файл өмнөх commit-ын түүхэнд байсаар байгаа тул сэргээх боломжтой ч энэ нь энэ сургалтын хүрээнээс гадуурх арга.
Хэрэгтэй файлаа git rm-ээр устгах. git rm --cached-ийн оронд git rm бичвэл файл компьютероос тань ч устна. Хэрвээ танд тэр файл хэрэгтэй, зөвхөн repository-д байх ёсгүй байсан бол дээрх аргаар сэргээгээд, энэ удаад git rm --cached ашиглаж, файлыг .gitignore-д нэмнэ үү. Command бичихийн өмнө "энэ файл надад хэрэгтэй юу" гэж асуух нь хоёрын аль нэгийг зөв сонгоход тусална.
GitHub дээр LICENSE нэмсний дараа push татгалзагдах. Хэрвээ та GitHub дээр LICENSE үүсгэсний дараа pull хийхээ мартаж, шууд local дээр commit хийгээд push хийвэл 4.4 дүгээр хичээлийн “fetch first” мессеж гарна. Шийдэл нь мөн адил: git pull, дараа нь git push. GitHub-ийн вэб хуудсаар хийсэн commit бол өөр компьютер дээр хийсэн commit-тэй яг адилхан.
Repository бол дэлгүүрийн лангуу: тэнд зөвхөн код, тохиргоо, баримт бичиг байх ёстой, бусад нь .gitignore-ийн ард агуулахад үлдэнэ. Цэвэр repository-д автоматаар үүсдэг зүйл, нууц болон хувийн мэдээлэл, гар хуулбар, утгагүй нэртэй файл байхгүй, нэрнүүд нэг хэв маягтай, үндсэн файлууд бий. Жижиг төсөлд энгийн бүтэц хангалттай. git ls-files Git-ийн хянаж буй, өөрөөр хэлбэл GitHub дээр харагдах файлуудыг жагсаадаг. git mv хуучин шинэ файлын нэрийг сольж, түүхийг хадгалдаг. git rm файл файлыг устгаж, устгалтыг ачааны талбайд оруулдаг, харин git rm --cached зөвхөн хяналтаас хасдаг. requirements.txt шаардлагатай package-уудыг жагсаадаг бөгөөд Windows дээр Out-File -Encoding utf8 ашиглаж үүсгэнэ. LICENSE байхгүй бол код зохиогчийн эрхээр хамгаалагдана, MIT бол түгээмэл чөлөөт лиценз бөгөөд GitHub-ийн загвараар нэмэхэд хялбар. GitHub дээр шууд commit хийсний дараа local дээрээ заавал pull хийнэ.
Дараагийн хичээлд бид terminal-аас browser руу шилжиж, GitHub-ийн вэб интерфэйсээр аялна. Commit-ын түүхийг browser-оор харах, файл бүрийн мөр бүрийг хэн хэзээ бичсэнийг харуулдаг blame, мөн төслийн хувилбаруудыг тэмдэглэх release-ийн тухай танилцана.
Бүртгэлтэй болсноор энэ сургалтын бүх хичээлд хандах эрх авна.