Git bilan tanishuv: rasmiy qo‘llanma

Birinchi uch qismda Git'ni o‘rnatdik, sozladik va birinchi commitni qildik. Endi rasmiy qo‘llanmaning o‘zi — Git jamoasi yozgan kirish matni. Unda siz allaqachon ko‘rgan buyruqlar boshqa tomondan, manba muallifining tilida tushuntiriladi, oxirida esa ikki kishi bir loyihada qanday ishlashi ko‘rsatiladi.

Nomi#

gittutorial — Git bilan tanishtiruvchi qo‘llanma.

Qisqacha ishlatilishi#

git *

Tavsif#

Ushbu qo‘llanma yangi loyihani Git’ga kiritish, unga o‘zgartirishlar kiritish va bu o‘zgartirishlarni boshqa dasturchilar bilan ulashishni tushuntiradi.

Agar siz Git’dan, asosan, loyihani yuklab olish (masalan, uning eng so‘nggi versiyasini sinash) uchun foydalanmoqchi bo‘lsangiz, avval Git foydalanuvchi qo‘llanmasining dastlabki ikki bobini o‘qishingiz ma’qul.

Buyruq hujjatini olish:

man git-log
# yoki
git help log

Ikkinchi usulda o‘zingiz xohlagan qo‘llanma ko‘ruvchisidan foydalanishingiz mumkin; batafsil ma’lumot uchun git-help(1) ga qarang.

Git bilan ishlashdan oldin ismingiz va ochiq elektron pochta manzilingizni tanishtirish yaxshi amaliyotdir:

git config --global user.name "Your Name Comes Here"
git config --global user.email you@yourdomain.example.com

Yangi loyihani kiritish#

Dastlabki ishingiz saqlangan project.tar.gz arxivi bor deb faraz qilamiz. Uni Git versiya nazoratiga quyidagicha qo‘shing:

tar xzf project.tar.gz
cd project
git init

Git javobi:

Initialized empty Git repository in .git/

Ishchi katalog endi Git uchun tayyorlandi; yangi .git katalogi yaratilganini ko‘rishingiz mumkin.

Keyin joriy katalog ostidagi barcha fayllar tarkibining suratini (. joriy katalogni bildiradi) Git’ga bering:

git add .

Bu surat vaqtinchalik tayyorlash maydonida saqlanadi; Git uni index deb ataydi. Indeks tarkibini repozitoriyda doimiy saqlash uchun:

git commit

Git commit xabarini kiritishni so‘raydi. Shu bilan loyihangizning birinchi versiyasi Git’da saqlanadi.

O‘zgartirishlar kiritish#

Bir nechta faylni o‘zgartiring, so‘ng yangilangan tarkibini indeksga qo‘shing:

git add file1 file2 file3

Endi commit qilishga tayyorsiz. Commitga nimalar kirishini ko‘rish uchun:

git diff --cached

--cached bo‘lmasa, git diff siz o‘zgartirgan, ammo hali indeksga qo‘shmagan o‘zgarishlarni ko‘rsatadi. Holatning qisqa xulosasi:

git status
On branch master
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)

        modified:   file1
        modified:   file2
        modified:   file3

Qo‘shimcha tuzatish zarur bo‘lsa, hozir bajaring va yangi o‘zgargan tarkibni yana indeksga qo‘shing. So‘ng:

git commit

Git yana o‘zgarishni tavsiflovchi xabarni so‘raydi va loyihaning yangi versiyasini yozib qo‘yadi.

Oldindan git add ishlatish o‘rniga:

git commit -a

Bu buyruq o‘zgartirilgan (ammo yangi bo‘lmagan) fayllarni avtomatik aniqlaydi, indeksga qo‘shadi va bitta qadamda commit qiladi.

Commit xabarlari haqida#

Majburiy bo‘lmasa-da, commit xabarini o‘zgarishni qisqacha ifodalovchi bitta satr (50 belgidan oshmagan) bilan boshlash, undan keyin bo‘sh satr va batafsil tavsif yozish tavsiya etiladi. Birinchi bo‘sh satrgacha bo‘lgan matn commit sarlavhasi hisoblanadi va Git bo‘ylab ishlatiladi. Masalan, git-format-patch(1) commitni emailga aylantirganda sarlavhani Subject qatorida, qolgan matnni esa xat tanasida ishlatadi.

Git fayllarni emas, tarkibni kuzatadi#

Ko‘p versiya nazorati tizimlarida add buyrug‘i tizimga yangi fayl o‘zgarishlarini kuzatishni boshlashni aytadi. Git’dagi add sodda va kuchliroq: git add ham yangi, ham yaqinda o‘zgartirilgan fayllar uchun ishlatiladi. Har ikki holatda u berilgan fayllarning suratini olib, ularning tarkibini keyingi commit uchun indeksga tayyorlaydi.

Loyiha tarixini ko‘rish#

git log

Har bir bosqichdagi to‘liq farqlarni ko‘rish:

git log -p

Har bir bosqich haqida umumiy tasavvur beruvchi o‘zgarishlar xulosasi:

git log --stat --summary

Branchlarni boshqarish#

Bitta Git repozitoriysi bir nechta rivojlantirish branchini saqlashi mumkin. experimental nomli branch yarating:

git branch experimental
git branch
  experimental
* master

experimental — hozirgina yaratilgan branch, master esa avtomatik yaratilgan standart branch. Yulduzcha joriy branchni ko‘rsatadi. experimental ga o‘tish:

git switch experimental

Endi faylni tahrirlang, o‘zgarishni commit qiling va master ga qayting:

# faylni tahrirlang
git commit -a
git switch master

Kiritgan o‘zgarishingiz endi ko‘rinmayotganini tekshiring: u experimental branchida qilingan, siz esa master ga qaytdingiz.

master branchida boshqa o‘zgarish qilishingiz mumkin:

# faylni tahrirlang
git commit -a

Endi ikki branch ajraldi va har birida boshqa-boshqa o‘zgarish bor. experimental dagi o‘zgarishlarni master ga birlashtirish:

git merge experimental

O‘zgarishlar to‘qnashmasa, ish tugadi. To‘qnashuv bo‘lsa, muammoli fayllarda konflikt belgilari qoladi. Ularni ko‘rish:

git diff

Fayllarni tahrirlab konfliktlarni hal qilgach, birlashtirish natijasini commit qiling:

git commit -a
gitk

gitk hosil bo‘lgan tarixning qulay grafik ko‘rinishini beradi. Endi experimental branchini o‘chirish mumkin:

git branch -d experimental

Bu buyruq experimental dagi o‘zgarishlar allaqachon joriy branchda borligini tekshiradi.

Agar crazy-idea branchidagi ishingizdan voz kechsangiz, uni majburan o‘chirishingiz mumkin:

git branch -D crazy-idea

Branchlar arzon va oson yaratiladi, shu sabab ular yangi g‘oyalarni sinashning yaxshi usulidir.

Git’dan hamkorlikda foydalanish#

Alice /home/alice/project da yangi Git loyihasini boshlagan, shu kompyuterda uy katalogiga ega Bob esa unga hissa qo‘shmoqchi deb faraz qilamiz.

Bob boshlaydi:

# Bob o‘z kompyuterida
git clone /home/alice/project myrepo

Bu Alice repozitoriysining klonini saqlovchi myrepo katalogini yaratadi. Klon asl loyiha bilan teng huquqli bo‘lib, loyiha tarixining o‘z nusxasiga ega.

Bob o‘zgarishlar kiritib, ularni commit qiladi:

# fayllarni tahrirlang
# Bob o‘z kompyuterida
git commit -a
# kerak bo‘lsa takrorlang

Tayyor bo‘lgach, Bob Alice’ga /home/bob/myrepo dan o‘zgarishlarni tortib olishni aytadi:

# Alice o‘z kompyuterida
cd /home/alice/project
git pull /home/bob/myrepo master

Bu Bobning master branchidagi o‘zgarishlarni Alice’ning joriy branchiga birlashtiradi. Alice bu orada o‘z o‘zgarishlarini qilgan bo‘lsa, konfliktlarni qo‘lda tuzatishi mumkin.

pull ikki amalni bajaradi: masofaviy branchdan o‘zgarishlarni oladi (fetch), keyin ularni joriy branchga birlashtiradi (merge).

Odatda Alice pull dan oldin mahalliy o‘zgarishlarini commit qilishi kerak. Bobning ishi tarixlar ajralganidan keyin Alice qilgan ish bilan to‘qnashsa, Alice konfliktni ishchi daraxt va indeks orqali hal qiladi. Commit qilinmagan mahalliy o‘zgarishlar bu jarayonga xalaqit beradi: Git o‘zgarishlarni oladi, ammo birlashtirishni rad etadi; Alice mahalliy o‘zgarishlarini bir yo‘l bilan chetga olishi va yana pull qilishi kerak.

Alice birlashtirmasdan Bobning ishini ko‘rib chiqishi mumkin:

# Alice o‘z kompyuterida
git fetch /home/bob/myrepo master
git log -p HEAD..FETCH_HEAD

Bu amal Alice’da commit qilinmagan o‘zgarishlar bo‘lsa ham xavfsiz. HEAD..FETCH_HEAD — “FETCH_HEAD dan erishish mumkin bo‘lgan hamma narsani ko‘rsat, ammo HEAD dan erishish mumkin bo‘lganlarini chiqarib tashla” degani. Alice o‘zining joriy holatiga (HEAD) olib kelgan tarixni biladi va Bobning hali ko‘rmagan holatini (FETCH_HEAD) tekshiradi.

Tarixlar ajralganidan beri Bob nima qilganini grafikda ko‘rish:

gitk HEAD..FETCH_HEAD

Bu git log dagidek ikki nuqtali oraliq yozuvidir. Ikkala tomon qilgan ishni ko‘rish uchun uch nuqta ishlatiladi:

gitk HEAD...FETCH_HEAD

Bu “ikkalasidan istalgan biri orqali erishiladigan hamma narsani ko‘rsat, ammo ikkalasidan ham erishiladiganlarini chiqarib tashla” degani. Bu oraliq yozuvlari gitk va git log bilan ishlaydi.

Bobning ishini tekshirgach, shoshilinch narsa bo‘lmasa, Alice uni tortib olmasdan ishlashda davom etishi mumkin. Zarur o‘zgarish bo‘lsa, Alice avval tugallanmagan ishini stash qiladi, pull bajaradi va so‘ng ishini hosil bo‘lgan tarix ustiga stash’dan qaytaradi.

Bir xil repozitoriy bilan tez-tez ishlaganda masofaviy repozitoriy uchun qisqa nom yaratish qulay:

# Alice o‘z kompyuterida
git remote add bob /home/bob/myrepo
git fetch bob

To‘liq yo‘ldan farqli ravishda, git remote bilan belgilangan qisqa nom orqali olingan ma’lumot masofaviy kuzatuv branchida — bu holatda bob/master da — saqlanadi:

# Alice o‘z kompyuterida
git log -p master..bob/master

Bu Bob Alice’ning master branchidan ajralganidan beri qilgan barcha o‘zgarishlarini ko‘rsatadi. Ularni tekshirgach, Alice birlashtirishi mumkin:

# Alice o‘z kompyuterida
git merge bob/master

O‘z masofaviy kuzatuv branchidan pull qilish orqali ham birlashtirish mumkin:

# Alice o‘z kompyuterida
git pull . remotes/bob/master

git pull buyruq satrida yana nima berilganidan qat’i nazar, doim joriy branchga birlashtiradi.

Keyin Bob Alice’ning so‘nggi o‘zgarishlari bilan repozitoriysini yangilaydi:

# Bob o‘z kompyuterida
git pull

Bob Alice repozitoriysining yo‘lini berishi shart emas: klonlash vaqtida Git bu manzilni konfiguratsiyada saqlagan:

# Bob o‘z kompyuterida
git config --get remote.origin.url
/home/alice/project

git clone yaratgan to‘liq konfiguratsiya git config -l orqali ko‘rinadi; har bir parametr ma’nosi git-config(1) da tushuntirilgan.

Git Alice’ning master branchi toza nusxasini origin/master nomi bilan ham saqlaydi:

# Bob o‘z kompyuterida
git branch -r
  origin/master

Bob boshqa kompyuterdan ishlasa, SSH orqali klonlash va tortib olish mumkin:

# Bob o‘z kompyuterida
git clone alice.org:/home/alice/project myrepo

Git o‘zining mahalliy protokolidan yoki HTTP’dan ham foydalana oladi; git-pull(1) ga qarang. Git markaziy repozitoriyga turli foydalanuvchilar o‘zgarishlarni push qiladigan CVS’ga o‘xshash rejimda ham ishlaydi; git-push(1) va gitcvs-migration(7) ga qarang.

Tarixni o‘rganish#

Git tarixi o‘zaro bog‘langan commitlar ketma-ketligidir. git log ularni ro‘yxatlaydi. Har bir yozuvning birinchi satri commit nomi — identifikatorini ham beradi:

git log
commit c82a22c39cbc32576f64f5c6b3f24b99ea8149c7
Author: Junio C Hamano <junkio@cox.net>
Date:   Tue May 16 17:18:22 2006 -0700

    merge-base: Clarify the comments on post processing.

Commit tafsilotlarini ko‘rish:

git show c82a22c39cbc32576f64f5c6b3f24b99ea8149c7

Commitga murojaat qilishning boshqa usullari ham bor. Uni yagona aniqlashga yetadigan boshlang‘ich qismdan foydalanish mumkin:

git show c82a22c39c   # nomning dastlabki bir nechta belgisi odatda yetadi
git show HEAD         # joriy branchning eng so‘nggi nuqtasi
git show experimental # "experimental" branchining eng so‘nggi nuqtasi

Har bir commit odatda loyihaning oldingi holatiga ishora qiluvchi bitta parent commitga ega:

git show HEAD^  # HEAD ota commitini ko‘rish
git show HEAD^^ # HEAD bobo commitini ko‘rish
git show HEAD~4 # HEAD dan to‘rt avvalgi commitni ko‘rish

Merge commitlarda bir nechta parent bo‘lishi mumkin:

git show HEAD^1 # HEAD ning birinchi parenti (HEAD^ bilan bir xil)
git show HEAD^2 # HEAD ning ikkinchi parenti

Commitlarga o‘zingiz nom berishingiz ham mumkin:

git tag v2.5 1b2e1d63ff

Shundan keyin 1b2e1d63ff ga v2.5 nomi bilan murojaat qilinadi. Bu nomni boshqalar bilan ulashmoqchi bo‘lsangiz (masalan, reliz versiyasini belgilash uchun), tag obyekti yaratish va ehtimol uni imzolash kerak; git-tag(1) ga qarang.

Commit talab qiladigan har qanday Git buyrug‘i ushbu nomlardan istalganini qabul qiladi:

git diff v2.5 HEAD     # joriy HEAD ni v2.5 bilan solishtirish
git branch stable v2.5 # v2.5 asosida "stable" branchini yaratish
git reset --hard HEAD^ # branch va ishchi katalogni HEAD^ holatiga qaytarish

git grep loyihangizning istalgan versiyasida matn qidiradi:

git grep "hello" v2.5

Bu v2.5 ichidagi barcha hello uchrashuvlarini topadi. Commit nomi berilmasa, joriy katalogdagi Git kuzatayotgan fayllardan qidiradi:

git grep "hello"

Ko‘p Git buyruqlari turli usulda ko‘rsatiladigan commitlar to‘plamini ham qabul qiladi:

git log v2.5..v2.6            # v2.5 va v2.6 orasidagi commitlar
git log v2.5..                # v2.5 dan keyingi commitlar
git log --since="2 weeks ago" # so‘nggi ikki haftadagi commitlar
git log v2.5.. Makefile       # v2.5 dan keyin Makefile’ni o‘zgartirgan commitlar

Birinchi commit ikkinchisining ajdodi bo‘lishi shart bo‘lmagan oraliq ham berish mumkin. Masalan, stable va master umumiy commitdan ajralgan bo‘lsa:

git log stable..master

master da bor, ammo stable da yo‘q commitlarni ko‘rsatadi. Aksincha:

git log master..stable

stable da bor, ammo master da yo‘q commitlarni ko‘rsatadi.

git log ning zaif tomoni — commitlarni ro‘yxat ko‘rinishida berishi. Tarixdagi rivojlanish yo‘llari ajralib, keyin yana birlashganda, ularning ro‘yxatdagi tartibi mazmunli bo‘lmasligi mumkin.

Ko‘p ishtirokchili loyihalarda (Linux yadrosi yoki Git’ning o‘zi kabi) merge ko‘p bo‘ladi; gitk tarixni yaxshiroq tasvirlaydi:

gitk --since="2 weeks ago" drivers/

Bu oxirgi ikki hafta ichida drivers katalogidagi fayllarni o‘zgartirgan commitlarni ko‘rish imkonini beradi. gitk shriftini Control tugmasini bosib turib - yoki + ni bosish orqali sozlash mumkin.

Fayl nomini qabul qiladigan buyruqlarning aksariyatida muayyan fayl versiyasini ko‘rsatish uchun uning oldidan commit yozish mumkin:

git diff v2.5:Makefile HEAD:Makefile.in
git show v2.5:Makefile

Keyingi qadamlar#

Ushbu qo‘llanma loyihalaringizda asosiy taqsimlangan versiya nazoratini bajarish uchun yetarli bo‘lishi kerak. Git’ning imkoniyatlarini to‘liq tushunish uchun u asoslangan ikki oddiy g‘oyani bilish zarur:

• Obyektlar ma’lumotlar bazasi — loyiha tarixi, fayllar, kataloglar va commitlarni saqlovchi puxta tizim.

• Indeks fayli — katalog daraxti holatining keshi; commit yaratish, ishchi kataloglarni chiqarib olish va merge jarayonidagi turli daraxtlarni saqlash uchun ishlatiladi.

Qo‘llanmaning ikkinchi qismi obyektlar bazasi, indeks fayli va Git’dan samarali foydalanish uchun zarur boshqa mavzularni tushuntiradi: gittutorial-2(7).

Hozircha davom ettirmasangiz, quyidagilar ham qiziqarli bo‘lishi mumkin:

• git-format-patch(1), git-am(1) — commitlar ketma-ketligini email patchlariga va aksincha aylantiradi; email patchlariga ko‘p tayanadigan Linux yadrosi kabi loyihalarda foydali.

• git-bisect(1) — regressiya paydo bo‘lsa, aybdor aniq commitni tarixdan ikkilik qidiruv orqali topishga yordam beradi. Ko‘p branchli va merge’li murakkab tarixda ham deyarli optimal qidiradi.

• gitworkflows(7) — tavsiya etilgan ish jarayonlari sharhi.

• giteveryday(7) — taxminan 20 ta buyruq bilan kundalik Git ishlari.

• gitcvs-migration(7) — CVS foydalanuvchilari uchun Git.

Shuningdek qarang#

gittutorial-2(7), gitcvs-migration(7), gitcore-tutorial(7), gitglossary(7), git-help(1), gitworkflows(7), giteveryday(7), The Git User’s Manual.

Git to‘plami#

git(1) buyruqlar to‘plamining bir qismi.

Izoh#

1. The Git User’s Manual: git-htmldocs/user-manual.html