Git bilan ishlashni boshlash: yangi boshlanuvchilar uchun batafsil qo'llanma

Kirish o'rniga

Salom bo'lajak Katta dasturiy ta'minot muhandisi. Bugun biz versiyani boshqarish tizimi, ya'ni Git haqida gaplashamiz (ingliz tili grammatikasidan ko'rinib turganidek, JIT emas, GIT deb o'qing). Ha, ha, men Mercurial, SVN ham borligini bilaman... Lekin to'g'risini aytaylik: ularning vaqti allaqachon o'tib ketgan va men sizning qimmatli vaqtingizni ularga sarflamayman. Bizning zamonamizda Gitni bilish muhimligini tushunishingiz uchun men buni aytaman: bu haqda ma'lumotsiz/tushunmasdan, dasturlashda hech qanday ishingiz yo'q. Ammo go'zallik shundaki, doimiy ishlash uchun siz barcha buyruq va imkoniyatlarni boshingizda saqlashingiz shart emas. Siz sodir bo'layotgan hamma narsani tushunishga yordam beradigan buyruqlar to'plamini bilishingiz kerak.

Git asoslari

Git bizning kodimiz uchun taqsimlangan versiya boshqaruv tizimidir. Nega bizga kerak? Taqsimlangan jamoalar qandaydir ishni boshqarish tizimiga muhtoj. Vaqt o'tishi bilan sodir bo'lgan o'zgarishlarni kuzatish kerak. Ya'ni, bosqichma-bosqich biz qaysi fayllar va qanday o'zgarganligini ko'ramiz. Bu, ayniqsa, bitta vazifa doirasida bajarilgan ishlarni tahlil qilganda juda muhim: bu orqaga qaytish imkonini beradi. Vaziyatni tasavvur qilaylik: ishlaydigan kod bor edi, unda hamma narsa yaxshi edi, lekin biz nimanidir yaxshilashga qaror qildik, uni bu erda o'zgartiring, u erda uni o'zgartiring. Hammasi yaxshi edi, lekin bu yaxshilanish funksionallikning yarmini buzdi va ishlashni imkonsiz qildi. Va undan keyin nima? Gita bo'lmasa, soatlab o'tirish va hamma narsa dastlab qanday bo'lganini eslash kerak edi. Shunday qilib, biz faqat majburiyatga qaytamiz va tamom. Yoki bir vaqtning o'zida ikkita dasturchi o'z kodini o'zgartirsa nima bo'ladi? Gitsiz bu shunday ko'rinadi: ular kodni asl nusxadan ko'chirib olishdi va kerakli narsani qilishdi. Vaqt keladi va ikkalasi ham o'z o'zgarishlarini asosiy jildga qo'shishni xohlaydi. Va bu vaziyatda nima qilish kerak?.. Men bu ishni bajarish vaqtini taxmin qilishga ham jur'at etmayman. Agar siz Git-dan foydalansangiz, bunday muammolar umuman bo'lmaydi.

Git o'rnatilmoqda

Keling, Git-ni kompyuteringizga o'rnatamiz. Men har bir kishi turli xil operatsion tizimga ega ekanligini tushunaman, shuning uchun men bir nechta holatlarni tasvirlashga harakat qilaman.

Windows uchun o'rnatish

Odatdagidek, exe faylini yuklab olishingiz va uni ishga tushirishingiz kerak. Bu erda hamma narsa oddiy: birinchi Google havolasini bosing , o'rnating va hammasi. Ish uchun biz ular taqdim etgan bash konsolidan foydalanamiz. Windows da ishlash uchun siz Git Bash dasturini ishga tushirishingiz kerak. Boshlash menyusida bu shunday ko'rinadi: Va bu allaqachon siz ishlashingiz mumkin bo'lgan konsol. Gitni har safar ochish uchun loyiha bilan papkaga o'tmaslik uchun papkani sichqonchaning o'ng tugmasi bilan bosib, bizga kerak bo'lgan yo'l bilan konsolni ochishingiz mumkin:

Linux uchun o'rnatish

Odatda git allaqachon o'rnatilgan va Linux distributivlariga kiritilgan, chunki u dastlab Linux yadrosini ishlab chiqish uchun yozilgan vositadir. Ammo u mavjud bo'lmagan holatlar mavjud. Buni tekshirish uchun siz terminalni ochishingiz va quyidagilarni yozishingiz kerak: git --version. Agar aniq javob bo'lsa, hech narsa o'rnatishga hojat yo'q. Terminalni oching va o'rnating. Men Ubuntu'da ishlayman, shuning uchun sizga nima yozishni ayta olaman: sudo apt-get install git. Va shunday: endi siz Git-dan istalgan terminalda foydalanishingiz mumkin.

MacOS-da o'rnatish

Bu erda ham avval siz Git allaqachon mavjudligini tekshirishingiz kerak (yuqoriga qarang, Linuxda bo'lgani kabi). Agar yo'q bo'lsa, eng oson yo'li so'nggi versiyani yuklab olishdir . Agar XCode o'rnatilgan bo'lsa, Git albatta avtomatik ravishda o'rnatiladi.

Gitni sozlash

Gitda ish bajariladigan foydalanuvchi sozlamalari mavjud. Bu oqilona va zaruriy narsa, chunki majburiyat yaratilganda, Git aynan shu ma'lumotni Muallif maydoni uchun oladi. Barcha loyihalar uchun foydalanuvchi nomi va parolni o'rnatish uchun siz quyidagi buyruqlarni kiritishingiz kerak:

git config --global user.name ”Ivan Ivanov”
git config --global user.email ivan.ivanov@gmail.com

Agar ma'lum bir loyiha uchun muallifni o'zgartirish zarurati bo'lsa (masalan, shaxsiy loyiha uchun), siz --globalni o'chirib tashlashingiz mumkin va bu ishlaydi:

git config user.name ”Ivan Ivanov”
git config user.email ivan.ivanov@gmail.com

Bir oz nazariya ...

Mavzuda qolish uchun xabaringizga bir nechta yangi so'z va harakatlar qo'shish tavsiya etiladi... Aks holda gaplashadigan hech narsa bo'lmaydi. Albatta, bu ba'zi jargon va ingliz tilining nusxasi, shuning uchun men ingliz tilidagi ma'nolarni qo'shaman. Qanday so'zlar va harakatlar?

• git ombori;
• majburiyat (majburiyat);
• filial;
• birlashtirish;
• ziddiyatlar;
• Torting;
• Durang;
• qanday qilib ba'zi fayllarni e'tiborsiz qoldirish mumkin (.gitignore).

Va hokazo.

Gitdagi shtatlar

Gitada tushunish va eslash kerak bo'lgan bir nechta holatlar mavjud:

• kuzatilmagan;
• o'zgartirilgan;
• tayyorlangan (bosqichli);
• qilgan.

Bu nima degani?

Bu bizning kodimizdagi fayllar joylashgan shtatlardir. Ya'ni, ularning hayot yo'li odatda shunday ko'rinadi:

1. Yaratilgan va omborga qo'shilmagan fayl kuzatilmagan holatda bo'ladi.
2. Biz Git omboriga allaqachon qo'shilgan fayllarga o'zgartirishlar kiritamiz - ular o'zgartirilgan holatda.
3. Biz o'zgartirgan fayllardan faqat o'zimizga kerak bo'lganlarini (yoki barchasini) tanlaymiz (masalan, bizga kompilyatsiya qilingan sinflar kerak emas) va bu o'zgarishlar bilan sinflar bosqichli holatga tushadi.
4. Bosqichli holatdan tayyorlangan fayllardan majburiyat yaratiladi va Git omboriga o'tadi. Shundan so'ng, bosqichli holat bo'sh. Ammo o'zgartirilganda hali ham biror narsa bo'lishi mumkin.

Bu shunday ko'rinadi (rasmiy hujjatdagi rasm, shuning uchun unga ishonishingiz mumkin)):

Majburiyat nima

Versiya boshqaruvidagi asosiy ob'ekt majburiyatdir. U o'sha majburiyatdan keyingi barcha o'zgarishlarni o'z ichiga oladi. Majburiyatlar bir-biriga bog'langan ro'yxat kabi bog'langan. Ya'ni: Birinchi majburiyat bor. Ikkinchi majburiyat yaratilganda, u (ikkinchi) birinchisidan keyin kelishini biladi. Va shu tarzda siz ma'lumotni kuzatishingiz mumkin. Majburiyat shuningdek metadata deb ataladigan o'z ma'lumotlariga ega:

• uni topishingiz mumkin bo'lgan noyob identifikator;
• uni yaratgan topshiriq muallifining ismi;
• tuzilgan sana;
• ushbu majburiyat davomida nima qilinganligini tavsiflovchi sharh.

Bu shunday ko'rinadi:

Filial nima

Filial majburiyatga ko'rsatgichdir. Majburiyat o'zidan oldin qaysi majburiyat kelganligini bilganligi sababli, filial majburiyatga ishora qilganda, avvalgilarining hammasi ham unga ishora qiladi. Shunga asoslanib, shuni aytishimiz mumkinki, xuddi shu majburiyatni ko'rsatadigan ko'plab filiallar bo'lishi mumkin. Ish filiallarda sodir bo'ladi, shuning uchun yangi topshiriq yaratilganda, filial o'z ko'rsatgichini yangi topshiriqga o'tkazadi.

Git bilan ishlashni boshlash

Siz faqat mahalliy ombor yoki masofaviy ombor bilan ishlashingiz mumkin. Kerakli buyruqlarni ishlab chiqish uchun siz faqat mahalliy ombordan foydalanishingiz mumkin. U barcha ma'lumotlarni faqat .git jildidagi loyihada mahalliy sifatida saqlaydi. Agar biz masofaviy axborot vositalari haqida gapiradigan bo'lsak, unda barcha ma'lumotlar uzoq serverda saqlanadi: loyihaning faqat nusxasi mahalliy sifatida saqlanadi, unga o'zgartirishlar masofaviy omborga yuborilishi mumkin (git push). Bu erda va keyin biz konsolda git bilan ishlashni muhokama qilamiz. Albatta, siz ba'zi grafik echimlardan foydalanishingiz mumkin (masalan, Intellij IDEA da), lekin avval siz qanday buyruqlar sodir bo'layotganini va ular nimani anglatishini aniqlashingiz kerak.

Mahalliy omborda Git bilan ishlash

Keyinchalik, maqolani o'qiyotganingizda qilgan barcha amallarni bajarishingizni maslahat beraman. Bu materialni tushunish va saqlashni yaxshilaydi. Shunday qilib, yaxshi ishtaha :) Mahalliy omborni yaratish uchun siz quyidagilarni yozishingiz kerak:

git init

Bu konsol joylashgan joyda .git papkasini yaratadi. .git - bu Git ombori haqidagi barcha ma'lumotlarni saqlaydigan papka. Uni yo'q qilishning hojati yo'q;) Keyinchalik, fayllar ushbu loyihaga qo'shiladi va ularning holati "Kuzatilmagan" bo'ladi. Joriy ish holatini ko'rish uchun yozing:

git status

Biz usta filialdamiz va biz boshqasiga o'tmagunimizcha, hamma narsa shunday bo'lib qoladi. Shunday qilib, qaysi fayllar o'zgartirilganligini, lekin bosqichli holatga hali qo'shilmaganligini ko'rishingiz mumkin. Ularni bosqichli holatga qo'shish uchun siz git add yozishingiz kerak. Bu erda bir nechta variant bo'lishi mumkin, masalan:

• git add -A - bosqichli holatdan barcha fayllarni qo'shish;
• git qo'shing. — ushbu jilddagi barcha fayllarni va barcha ichki fayllarni qo'shing. Asosan avvalgisiga o'xshash;
• git add <filename> - faqat ma'lum bir faylni qo'shadi. Bu erda siz ba'zi bir naqshga muvofiq qo'shish uchun oddiy iboralardan foydalanishingiz mumkin. Masalan, git add *.java: bu faqat java kengaytmali fayllarni qo'shish kerakligini bildiradi.

Birinchi ikkita variant oddiy ekanligi aniq, ammo qo'shimchalar bilan u yanada qiziqarli bo'ladi, shuning uchun biz yozamiz:

git add *.txt

Vaziyatni tekshirish uchun biz allaqachon bilgan buyruqdan foydalanamiz:

git status

Bundan biz muntazam ifodaning to'g'ri ishlaganini ko'rishimiz mumkin va hozir test_resource.txt bosqichli holatda. Va nihoyat, oxirgi bosqich (mahalliy ombor bilan, masofaviy bilan yana bittasi bo'ladi;)) - topshiring va yangi majburiyat yarating:

git commit -m “all txt files were added to the project”

Keyinchalik, filialning topshirish tarixiga qarash uchun ajoyib buyruq mavjud. Keling, undan foydalanamiz:

git log

Bu erda siz bizning birinchi majburiyatimiz biz uzatgan matn bilan paydo bo'lganini allaqachon ko'rishingiz mumkin. Shuni tushunish juda muhimki, biz o'tkazgan matn ushbu majburiyat davomida nima qilinganligini iloji boricha aniq belgilashi kerak. Bu kelajakda ko'p marta yordam beradi. Hali uxlamagan qiziquvchan o'quvchi aytishi mumkin: GitTest.java fayliga nima bo'ldi? Endi biz bilib olamiz, buning uchun foydalaning:

git status

Ko'rib turganimizdek, u kuzatilmagan holatda qolmoqda va qanotlarda kutmoqda. Yoki, ehtimol, biz uni loyihaga umuman qo'shishni xohlamaymizmi? Ba'zan shunday bo'ladi. Keyinchalik, uni yanada qiziqarli qilish uchun test_resource.txt matn faylimizni o'zgartirishga harakat qilaylik. Keling, u erga bir oz matn qo'shamiz va holatni tekshiramiz:

git status

Bu erda siz ikki holat o'rtasidagi farqni aniq ko'rishingiz mumkin - kuzatilmagan va o'zgartirilgan. GitTest.java kuzatilmagan holatda va test_resource.txt o'zgartirilgan holatda. Endi o'zgartirilgan holatda allaqachon fayllar mavjud bo'lsa, biz ularga kiritilgan o'zgarishlarni ko'rib chiqishimiz mumkin. Buni buyruq yordamida amalga oshirish mumkin:

git diff

Ya'ni, matn faylimizga salom dunyo!-ni qo'shganimni shu yerda aniq ko'rishingiz mumkin. Matn fayliga o'zgartirishlar qo'shing va quyidagilarni bajaring:

git add test_resource.txt
git commit -m “added hello word! to test_resource.txt”

Barcha majburiyatlarni ko'rish uchun yozing:

git log

Ko'rib turganingizdek, allaqachon ikkita majburiyat mavjud. Xuddi shu tarzda biz GitTest.java ni qo'shamiz. Endi izohlar yo'q, faqat buyruqlar:

git add GitTest.java
git commit -m “added GitTest.java”
git status

.gitignore bilan ishlash

Biz faqat manba kodini saqlashni xohlayotganimiz va omborda boshqa hech narsa yo'qligi aniq. Yana nima bo'lishi mumkin? Eng kamida, ishlab chiqish muhitini yaratadigan kompilyatsiya qilingan sinflar va/yoki fayllar. Git ularni e'tiborsiz qoldirishi uchun maxsus fayl yaratilishi kerak. Biz buni qilamiz: loyihaning ildizida .gitignore deb nomlangan fayl yaratamiz va bu faylda har bir satr e'tiborga olinmaydigan naqsh bo'ladi. Ushbu misolda git ignore quyidagicha ko'rinadi:

```
*.class
target/
*.iml
.idea/
```

Keling, hozir qaraylik:

• birinchi qator - .class kengaytmali barcha fayllarni e'tiborsiz qoldirish;
• ikkinchi qator - maqsadli papkani va uning tarkibidagi hamma narsani e'tiborsiz qoldirish;
• uchinchi qator - .iml kengaytmali barcha fayllarni e'tiborsiz qoldirish;
• To'rtinchi qator - .idea jildiga e'tibor bermaslik.

Keling, buni misol bilan sinab ko'raylik. Bu qanday ishlashini ko'rish uchun loyihaga kompilyatsiya qilingan GitTest.class sinfini qo'shing va loyiha holatini ko'ring:

git status

Shubhasiz, biz tasodifan (agar biz git add -A dan foydalansak) loyihaga kompilyatsiya qilingan sinfni qo'shishni xohlamaymiz. Buni amalga oshirish uchun .gitignore faylini yarating va avval tavsiflangan barcha narsalarni qo'shing: Endi loyihaga git ignore-ni yangi majburiyat bilan qo'shamiz:

git add .gitignore
git commit -m “added .gitignore file”

Va endi haqiqat lahzasi: bizda kuzatilmagan holatda tuzilgan GitTest.class klassi bor, biz uni Git omboriga qo'shishni xohlamadik. Bu erda git ignore ishlashi kerak:

git status

Hammasi aniq) Git ignore +1)

Filiallar va boshqalar bilan ishlash

Albatta, bitta filialda ishlash bir kishi uchun noqulay va jamoada bir nechta odam bo'lsa, imkonsizdir. Buning uchun filial mavjud. Yuqorida aytganimdek, filial shunchaki majburiyatlar uchun harakatlanuvchi ko'rsatgichdir. Ushbu qismda biz turli sohalarda ishlashni ko'rib chiqamiz: o'zgarishlarni bir filialdan boshqasiga qanday birlashtirish, qanday nizolar paydo bo'lishi mumkinligi va boshqalar. Ombordagi barcha filiallar ro'yxatini ko'rish va qaysi birida ekanligingizni tushunish uchun quyidagilarni yozishingiz kerak:

git branch -a

Ko'rib turganingizdek, bizda faqat bitta asosiy shoxcha bor va uning oldidagi yulduzcha biz uning ustida ekanligimizni bildiradi. Aytgancha, qaysi filialda ekanligimizni bilish uchun biz status tekshiruvidan ham foydalanishimiz mumkin (git status). Keyinchalik, filiallarni yaratishning bir nechta variantlari mavjud (ehtimol ko'proq bor, men ulardan foydalanaman):

• biz ishlayotgan filial asosida yangi filial yaratish (99% hollarda);
• muayyan majburiyat asosida filial yaratish (1%).

Muayyan majburiyat asosida filial yarating

Biz yagona majburiyat identifikatoriga tayanamiz. Uni topish uchun biz yozamiz:

git log

Men majburiyatni "salom dunyo qo'shildi ..." izohi bilan ta'kidladim. U noyob identifikatorga ega - "6c44e53d06228f888f2f454d3cb8c1c976dd73f8". Men ushbu majburiyatdan boshlab rivojlanish bo'limi yaratmoqchiman. Buning uchun men yozaman:

git checkout -b development 6c44e53d06228f888f2f454d3cb8c1c976dd73f8

Asosiy filialdan faqat birinchi ikkita topshiriqni o'z ichiga olgan filial yaratiladi. Buni sinab koʻrish uchun avvalo boshqa filialga oʻtganimizga ishonch hosil qilamiz va undagi majburiyatlar sonini koʻrib chiqamiz:

git status
git log

Va bu haqiqat: bizda ikkita majburiyat borligi ma'lum bo'ldi. Aytgancha, qiziq bir nuqta: bu filialda hali .gitignore fayli yo'q, shuning uchun bizning kompilyatsiya qilingan faylimiz (GitTest.class) endi kuzatilmagan holatda ta'kidlangan. Endi biz filiallarimizni yozish orqali qayta ko'rib chiqishimiz mumkin:

git branch -a

Ko'rinib turibdiki, ikkita tarmoq bor - usta va rivojlanish - va biz hozir rivojlanishdamiz.

Joriy filial asosida filial yarating

Filial yaratishning ikkinchi usuli - boshqasiga qurish. Men asosiy filialga asoslangan filial yaratmoqchiman, shuning uchun birinchi navbatda unga o'tishim kerak, keyingi qadam esa yangisini yaratishdir. Keling, qaraylik:

• git checkout master - asosiy filialga o'ting;
• git status - u masterda yoki yo'qligini tekshiring.

Bu yerda siz asosiy filialga o‘tganimizni ko‘rishingiz mumkin, git ignore bu yerda allaqachon ishlamoqda va kompilyatsiya qilingan sinf endi kuzatilmagan ko‘rinmaydi. Endi biz asosiy filial asosida yangi filial yaratamiz:

git checkout -b feature/update-txt-files

Agar siz ushbu filial master bilan bir xil bo'lmasligiga shubhangiz bo'lsa, buni git log yozish va barcha majburiyatlarni ko'rib chiqish orqali osongina tekshirishingiz mumkin. Ulardan to'rttasi bo'lishi kerak.

Mojarolarni hal qiling

Mojaro nima ekanligini tushunishdan oldin, biz bir filialni boshqasiga birlashtirish (birlashtirish) haqida gapirishimiz kerak. Bu rasmda bir filial boshqasiga birlashganda jarayonni ko'rsatishi mumkin: Ya'ni, asosiy filial mavjud. Bir nuqtada, undan ikkinchi darajali yaratiladi, unda o'zgarishlar yuz beradi. Ish tugagach, siz bir filialni boshqasiga birlashtirishingiz kerak. Men turli xil xususiyatlarni tasvirlamayman: men ushbu maqola doirasida faqat tushunishni aytmoqchiman va agar kerak bo'lsa, tafsilotlarni o'zingiz bilib olasiz. Shunday qilib, bizning misolimizda biz xususiyat/update-txt-files filialini yaratdik. Filial nomida yozilganidek, matnni yangilaymiz. Endi siz ushbu masala bo'yicha yangi majburiyat yaratishingiz kerak:

git add *.txt 
git commit -m “updated txt files”
git log

Endi, agar biz xususiyat/update-txt-files filialini master-ga birlashtirmoqchi bo'lsak, master-ga o'tishimiz va git merge feature/update-txt-files yozishimiz kerak:

git checkout master
git merge feature/update-txt-files
git log

Natijada, endi asosiy filialda xususiyat/update-txt-fayllariga qo'shilgan majburiyat ham mavjud. Ushbu funksiya qo'shilgan, shuning uchun siz xususiyat filialini o'chirishingiz mumkin. Buning uchun biz yozamiz:

git branch -D feature/update-txt-files

Hozircha bu aniq, to'g'rimi? Vaziyatni murakkablashtiramiz: endi txt faylini yana o'zgartirishimiz kerak, deylik. Ammo endi bu fayl ham sehrgarda o'zgartiriladi. Ya'ni, u parallel ravishda o'zgaradi va biz yangi kodni asosiy filialga birlashtirmoqchi bo'lgan vaziyatda Git nima qilish kerakligini tushunolmaydi. Bor! Biz master asosida yangi filial yaratamiz, text_resource.txt ga o'zgartirish kiritamiz va bu masala bo'yicha majburiyat yaratamiz:

git checkout -b feature/add-header
... делаем изменения в файле

git add *.txt
git commit -m “added header to txt”

Asosiy filialga o'ting va ushbu matn faylini xususiyat bo'limi bilan bir qatorda yangilang:

git checkout master
… обновor test_resource.txt

git add test_resource.txt
git commit -m “added master header to txt”

Va endi eng qiziqarli daqiqa: siz xususiyat/sarlavha qo'shish bo'limidan masterga o'zgarishlarni birlashtirishingiz kerak. Biz asosiy filialdamiz, shuning uchun qilishimiz kerak bo'lgan narsa:

git merge feature/add-header

Ammo test_resource.txt faylida ziddiyat bilan natijaga erishamiz: Va bu erda biz Git ushbu kodni qanday birlashtirishni mustaqil ravishda hal qila olmasligini ko'rishimiz mumkin va biz birinchi navbatda ixtilofni hal qilishimiz kerakligini va shundan keyingina majburiyatni bajarishimiz kerakligini aytadi. OK, keling, konfliktni o'z ichiga olgan faylni matn muharririda ochamiz va ko'rib chiqamiz: Git bu erda nima qilganini tushunish uchun siz qaerda yozganimizni eslab, solishtirishingiz kerak:

1. “<<<<<<< HEAD” va “=======” oʻrtasida asosiy boʻlimda ushbu qatordagi asosiy oʻzgarishlar mavjud.
2. "=======" va ">>>>>>>> xususiyat/sarlavha qo'shish" o'rtasida xususiyat/sarlavha qo'shish bo'limida o'zgarishlar mavjud.

Shunday qilib, Git shuni ko'rsatadiki, bu vaqtda u ushbu faylni qanday birlashtirishni aniqlay olmagan, bu bo'limni turli filiallardan ikki qismga ajratgan va o'zimiz uchun qaror qabul qilishni taklif qilgan. Yaxshi, kuchli iroda bilan men hamma narsani olib tashlashga qaror qildim, faqat sarlavhali so'zni qoldiring: O'zgarishlar holatini ko'rib chiqaylik, tavsif biroz boshqacha bo'ladi. O'zgartirilgan holat bo'lmaydi, lekin birlashtirilmagan. Shunday qilib, biz beshinchi holatni xavfsiz qo'shishimiz mumkin edi ... Lekin bu keraksiz deb o'ylayman, keling:

git status

Biz bu boshqa, g'ayrioddiy holat ekanligiga amin edik. Davom etaylik:

git add *.txt

Tavsifda siz ular faqat git commit yozishni taklif qilishlarini payqadingiz. Biz tinglaymiz va yozamiz:

git commit

Hammasi shu: biz buni shunday qildik - biz konsolda nizoni hal qildik. Albatta, ishlab chiqish muhitlarida buni biroz osonroq qilishingiz mumkin, masalan, Intellij IDEA-da hamma narsa shu qadar yaxshi sozlanganki, unda barcha kerakli amallarni bajarishingiz mumkin. Ammo rivojlanish muhiti kaput ostida juda ko'p narsalarni qiladi va biz ko'pincha u erda nima sodir bo'lganini tushunmaymiz. Va agar tushunish bo'lmasa, muammolar paydo bo'lishi mumkin.

Masofaviy omborlar bilan ishlash

Oxirgi qadam, masofaviy ombor bilan ishlash uchun zarur bo'lgan yana bir nechta buyruqlarni tushunishdir. Yuqorida aytganimdek, masofaviy ombor bu ombor saqlanadigan va uni klonlash mumkin bo'lgan joy. Masofaviy omborlarning qanday turlari mavjud? Ko'p misollar bor:

• GitHub - bu omborlar va hamkorlikdagi rivojlanish uchun eng katta ombor. Men buni oldingi maqolalarda allaqachon tasvirlab berganman. Mening Github hisobimga
  obuna bo'ling . Men o'z ishim davomida o'rgangan yo'nalishlarim bo'yicha o'z ishimni tez-tez namoyish etaman.

• GitLab ochiq manbali veb- asoslangan DevOps hayot aylanishi vositasi bo'lib, u Git uchun o'zining wiki, muammolarni kuzatish tizimi , CI/CD quvurlari va boshqa funktsiyalari bilan kodlar omborini boshqarish tizimini ta'minlaydi . Microsoft GitHub-ni sotib olgani haqidagi xabardan so'ng, ba'zi ishlab chiquvchilar o'zlarining ishlarini GitLab-da takrorlashdi.
  

• BitBucket - bu Mercurial va Git versiyalarini boshqarish tizimlariga asoslangan loyihalarni joylashtirish va hamkorlikda ishlab chiqish uchun veb-xizmat. Bir vaqtlar u GitHub-dan katta afzalliklarga ega edi, chunki u bepul shaxsiy omborlarga ega edi. O'tgan yili GitHub ham ushbu xususiyatni hamma uchun bepul taqdim etdi.

• Va hokazo…

Masofaviy ombor bilan ishlashda qilishingiz kerak bo'lgan birinchi narsa loyihani mahalliy loyihangizga klonlashdir. Buning uchun men mahalliy ishlab chiqqan loyihamizni eksport qildim va endi hamma buni yozish orqali o'zi uchun klonlashi mumkin:

git clone https://github.com/romankh3/git-demo

Endilikda loyihaning to‘liq nusxasi mahalliy miqyosda mavjud. Loyihaning so'nggi nusxasi mahalliy ekanligiga ishonch hosil qilish uchun, ular aytganidek, ma'lumotlarni yozish orqali tashlashingiz kerak:

git pull

Bizning holatda, hozir uzoqdan hech narsa o'zgarmadi, shuning uchun javob: Allaqachon yangilangan. Ammo agar men masofaviy omborda ba'zi o'zgarishlar qilsam, biz ularni tortib olganimizdan keyin mahalliy yangilanadi. Va nihoyat, oxirgi buyruq ma'lumotlarni masofaviy omborga yuborishdir. Mahalliy ravishda biror narsa qilgan bo'lsak va uni masofaviy omborga o'tkazmoqchi bo'lsak, avval mahalliy ravishda yangi majburiyat yaratishimiz kerak. Buni amalga oshirish uchun keling, matn faylimizga yana bir narsani qo'shamiz: Endi bu biz uchun odatiy hol - biz bu masala bo'yicha majburiyat yaratamiz:

git add test_resource.txt
git commit -m “prepated txt for pushing”

Va endi buni masofaviy omborga surish buyrug'i:

git push

Sizga aytmoqchi bo'lganim shu edi. E'tiboringiz uchun rahmat. Mening GitHub akkauntimga obuna bo'ling , u erda men o'qigan va ishda foydalanadigan turli ajoyib misol loyihalarini joylashtiraman.

foydali havolalar

• Git bo'yicha rasmiy hujjat rus tilida . Men uni ma'lumotnoma sifatida tavsiya qilaman.
• Git