Git ilə işə başlamaq: yeni başlayanlar üçün ətraflı bələdçi

Giriş əvəzinə

Salam gələcək Baş Proqram Mühəndisi. Bu gün versiyaya nəzarət sistemi, yəni Git (ingilis dilinin qrammatikasından göründüyü kimi JIT deyil, GIT kimi oxuyun) haqqında danışacağıq. Bəli, bəli, bilirəm ki, Mercurial, SVN də var... Amma düzünü deyək: onların vaxtı artıq keçib və mən sizin qiymətli vaxtınızı onlara sərf etmək fikrində deyiləm. Dövrümüzdə Git-i bilməyin vacibliyini başa düşməyiniz üçün bunu deyəcəyəm: bunu bilmədən/dərk etmədən proqramlaşdırma ilə heç bir əlaqəniz yoxdur. Ancaq gözəllik ondadır ki, daim işləmək üçün bütün əmrləri və imkanları beyninizdə saxlamaq lazım deyil. Baş verən hər şeyi başa düşməyə kömək edəcək bir sıra əmrləri bilməlisiniz.

Git Əsasları

Git kodumuz üçün paylanmış versiyaya nəzarət sistemidir. Niyə bizə lazımdır? Paylanmış komandalar bir növ iş idarəetmə sisteminə ehtiyac duyurlar. Zamanla baş verən dəyişiklikləri izləmək lazımdır. Yəni addım-addım görürük hansı faylları və necə dəyişib. Bu, bir tapşırıq daxilində nə edildiyini təhlil edərkən xüsusilə vacibdir: bu, geri qayıtmağa imkan verir. Gəlin bir vəziyyəti təsəvvür edək: işləyən kod var idi, orada hər şey yaxşı idi, amma biz nəyisə təkmilləşdirməyə, onu burada cızmaq, orada cızmaq qərarına gəldik. Hər şey yaxşı idi, lakin bu təkmilləşdirmə funksionallığın yarısını pozdu və işləməyi qeyri-mümkün etdi. Beləliklə, növbəti nədir? Gita olmasaydı, saatlarla oturmalı və hər şeyin başlanğıcda necə olduğunu xatırlamalı olardı. Beləliklə, biz öhdəliyə qayıdırıq və budur. Yaxud iki tərtibatçı eyni vaxtda kodu dəyişikliyi edərsə necə? Git olmadan belə görünür: kodu orijinaldan köçürdülər və lazım olanı etdilər. An gəlir və hər ikisi dəyişikliklərini əsas qovluğa əlavə etmək istəyir. Bəs bu vəziyyətdə nə etməliyəm?.. Mən bu işi görmək üçün vaxtı təxmin etməyə belə cəsarət etmirəm. Git istifadə etsəniz, ümumiyyətlə, belə problemlər olmayacaq.

Git quraşdırılması

Git-i kompüterinizə quraşdıraq. Hər kəsin fərqli OS olduğunu başa düşürəm, buna görə də bir neçə hal üçün təsvir etməyə çalışacağam.

Windows üçün quraşdırma

Həmişə olduğu kimi, exe faylını yükləməli və işə salmalısınız. Burada hər şey sadədir: ilk Google linkinə klikləyin , quraşdırın və bu qədər. İş üçün onların təmin etdiyi bash konsolundan istifadə edəcəyik. Windows-da işləmək üçün Git Bash-i işə salmalısınız. Başlanğıc menyusunda belə görünür: Bu, artıq işləyə biləcəyiniz bir konsoldur. Hər dəfə orada git açmaq üçün layihə ilə qovluğa getməmək üçün qovluğu sağ klikləməklə konsolu bizə lazım olan yolu aça bilərsiniz:

Linux üçün quraşdırma

Adətən git artıq quraşdırılıb və Linux paylamalarına daxil edilir, çünki o, əvvəlcə Linux nüvəsini inkişaf etdirmək üçün yazılmış bir vasitədir. Ancaq orada olmayan vəziyyətlər var. Bunu yoxlamaq üçün terminalı açıb yazın: git --version. Aydın cavab varsa, heç bir şey quraşdırmaq lazım deyil. Terminal açın və quraşdırın. Mən Ubuntu üzərində işləyirəm, ona görə də bunun üçün nə yazacağımı deyə bilərəm: sudo apt-get install git. Və budur: indi Git-dən istənilən terminalda istifadə edə bilərsiniz.

macOS-da quraşdırma

Burada da əvvəlcə Git-in mövcud olub-olmadığını yoxlamaq lazımdır (yuxarıya baxın, Linux-da olduğu kimi). Əks halda, ən asan yol ən son versiyanı yükləməkdir . XCode quraşdırılıbsa, Git mütləq avtomatik quraşdırılacaq.

Git quraşdırma

Git-də işin aparılacağı istifadəçi parametri var. Bu ağlabatan və zəruri bir şeydir, çünki öhdəlik yaradıldıqda Git Müəllif sahəsi üçün məhz bu məlumatı alır. Bütün layihələr üçün istifadəçi adı və parol qurmaq üçün aşağıdakı əmrləri daxil etməlisiniz:

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

Müəyyən bir layihə üçün müəllifin dəyişdirilməsinə ehtiyac varsa (məsələn, şəxsi layihə üçün), siz --global-ı silə bilərsiniz və bu işləyəcək:

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

Bir az nəzəriyyə...

Mövzuda qalmaq üçün mesajınıza bir neçə yeni söz və hərəkət əlavə etməyiniz məsləhətdir... Əks halda danışılası bir şey olmayacaq. Əlbəttə ki, bu bir az jarqon və ingilis dilinin surətidir, ona görə də ingilis dilində mənalar əlavə edəcəyəm. Hansı sözlər və hərəkətlər?

• git deposu;
• öhdəçilik etmək (öhdəçilik etmək);
• filial;
• birləşmək;
• münaqişələr;
• çəkmək;
• itələmək;
• bəzi fayllara (.gitignore) məhəl qoymamaq olar.

Və s.

Gitdəki ştatlar

Gitanın başa düşülməsi və yadda saxlanması lazım olan bir neçə vəziyyəti var:

• izlənilməmiş;
• dəyişdirilmiş;
• hazırlanmış (mərhələli);
• törədib.

Bunun mənası nədi?

Bunlar kodumuzdakı faylların yerləşdiyi dövlətlərdir. Yəni onların həyat yolu adətən belə görünür:

1. Yaradılan və depoya əlavə olunmayan fayl izlənilməmiş vəziyyətdə olacaq.
2. Artıq Git repozitoriyasına əlavə edilmiş fayllarda dəyişikliklər edirik - onlar dəyişdirilmiş vəziyyətdədir.
3. Dəyişdirdiyimiz fayllardan yalnız bizə lazım olanları (və ya hamısını) seçirik (məsələn, tərtib edilmiş siniflərə ehtiyacımız yoxdur) və dəyişiklikləri olan bu siniflər mərhələli vəziyyətə düşür.
4. Hazırlanmış fayllardan mərhələli vəziyyətdən öhdəlik yaradılır və Git repozitoriyasına daxil olur. Bundan sonra mərhələli vəziyyət boşdur. Lakin dəyişdirilmiş hələ də bir şey ola bilər.

Bu belə görünür (rəsmi sənəddən şəkil, ona görə də etibar edə bilərsiniz)):

Öhdəlik nədir

Təhlükə versiyaya nəzarətdə əsas obyektdir. Bu öhdəlikdən sonra bütün dəyişiklikləri ehtiva edir. Öhdəliklər tək əlaqəli siyahı kimi bir-biri ilə əlaqələndirilir. Yəni: İlk öhdəlik var. İkinci bir öhdəlik yaradıldıqda, o (ikincisi) birincidən sonra gəldiyini bilir. Və bu yolla siz məlumatları izləyə bilərsiniz. Öhdəliyin həmçinin metadata adlanan öz məlumatı var:

• onu tapa biləcəyiniz unikal öhdəlik identifikatoru;
• onu yaradan öhdəliyin müəllifinin adı;
• öhdəliyin yaranma tarixi;
• bu öhdəlik zamanı nə edildiyini təsvir edən şərh.

Bu belə görünür:

Filial nədir

Filial öhdəlik üçün göstəricidir. Bir öhdəliyin özündən əvvəl hansı öhdəliyin gəldiyini bildiyi üçün filial bir öhdəliyə işarə etdikdə, bütün əvvəlkilər də ona istinad edir. Buna əsaslanaraq deyə bilərik ki, eyni öhdəliyə işarə edən bir çox filial ola bilər. İş filiallarda baş verir, ona görə də yeni öhdəlik yaradılanda filial öz göstəricisini daha yeni öhdəliyə köçürür.

Git ilə işə başlayın

Siz yalnız yerli depo ilə və ya uzaqdan işləyə bilərsiniz. Lazımi əmrləri hazırlamaq üçün yalnız yerli depodan istifadə edə bilərsiniz. O, bütün məlumatları .git qovluğunda layihədə yalnız lokal olaraq saxlayır. Uzaqdan danışsaq, bütün məlumatlar uzaq bir serverdə bir yerdə saxlanılır: layihənin yalnız bir nüsxəsi lokal olaraq saxlanılır, dəyişiklikləri uzaq depoya (git push) göndərmək olar. Burada və daha sonra konsolda git ilə işləməyi müzakirə edəcəyik. Əlbəttə ki, bəzi qrafik həllərdən istifadə edə bilərsiniz (məsələn, Intellij IDEA-da), lakin əvvəlcə hansı əmrlərin baş verdiyini və nə demək olduğunu anlamaq lazımdır.

Yerli depoda Git ilə işləmək

Sonra, məqaləni oxuyarkən etdiyim bütün addımları izləməyi təklif edirəm. Bu, materialı başa düşməyinizi və yadda saxlamağınızı yaxşılaşdıracaq. Yaxşı iştaha :) Yerli repozitoriya yaratmaq üçün aşağıdakıları yazmalısınız:

git init

Bu, konsolun yerləşdiyi yerdə .git qovluğu yaradacaq. .git Git repozitoriyası haqqında bütün məlumatları saxlayan qovluqdur. Onu silməyə ehtiyac yoxdur ;) Sonra bu layihəyə fayllar əlavə olunur və onların statusu İzlənilmir. Cari iş statusunun nə olduğunu görmək üçün yazın:

git status

Biz usta filialdayıq və başqasına keçənə qədər hər şey elə də qalacaq. Bu yolla siz hansı faylların dəyişdirildiyini, lakin mərhələli vəziyyətə hələ əlavə olunmadığını görə bilərsiniz. Onları mərhələli vəziyyətə əlavə etmək üçün git add yazmalısınız. Burada bir neçə variant ola bilər, məsələn:

• git add -A - mərhələli vəziyyətdən bütün faylları əlavə edin;
• git əlavə et. — bu qovluqdakı bütün faylları və bütün daxili faylları əlavə edin. Əvvəlki ilə eynidir;
• git add <filename> - yalnız xüsusi fayl əlavə edir. Burada bəzi nümunəyə uyğun olaraq əlavə etmək üçün müntəzəm ifadələrdən istifadə edə bilərsiniz. Məsələn, git add *.java: bu o deməkdir ki, siz yalnız java uzantılı faylları əlavə etməlisiniz.

İlk iki variantın sadə olduğu aydındır, lakin əlavə ilə daha maraqlı olacaq, ona görə də yazırıq:

git add *.txt

Vəziyyəti yoxlamaq üçün artıq bildiyimiz əmrdən istifadə edirik:

git status

Buradan biz normal ifadənin düzgün işlədiyini görə bilərik və indi test_resource.txt mərhələli vəziyyətdədir. Və nəhayət, son mərhələ (yerli depo ilə, uzaqdan biri ilə daha biri olacaq;)) - öhdəlik götürün və yeni bir öhdəlik yaradın:

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

Sonra, bir filialın tarixçəsinə baxmaq üçün əla bir əmr var. Gəlin istifadə edək:

git log

Burada artıq görə bilərsiniz ki, ilk öhdəliyimiz köçürdüyümüz mətnlə ortaya çıxdı. Anlamaq çox vacibdir ki, keçdiyimiz mətn bu öhdəlik zamanı nə edildiyini mümkün qədər dəqiq müəyyən etməlidir. Bu, gələcəkdə dəfələrlə kömək edəcəkdir. Hələ yuxuya getməmiş maraqlanan oxucu deyə bilər: GitTest.java faylına nə oldu? İndi öyrənəcəyik, bunun üçün istifadə edin:

git status

Gördüyümüz kimi, izlənilməmiş vəziyyətdə qalır və qanadlarda gözləyir. Yoxsa onu ümumiyyətlə layihəyə əlavə etmək istəmirik? Bəzən olur. Sonra onu daha maraqlı etmək üçün test_resource.txt mətn faylımızı dəyişməyə çalışaq. Oraya bir az mətn əlavə edək və statusu yoxlayaq:

git status

Burada iki dövlət arasındakı fərqi aydın görə bilərsiniz - izlənilməmiş və dəyişdirilmiş. GitTest.java izlənilməmiş vəziyyətdədir və test_resource.txt dəyişdirilmiş vəziyyətdədir. Artıq dəyişdirilmiş vəziyyətdə olan fayllar olduğuna görə, onlara edilən dəyişikliklərə baxa bilərik. Bu əmrdən istifadə etməklə edilə bilər:

git diff

Yəni burada aydın görə bilərsiniz ki, bizim mətn faylımıza salam dünya! Mətn faylına dəyişikliklər əlavə edin və yerinə yetirin:

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

Bütün öhdəliklərə baxmaq üçün yazın:

git log

Gördüyünüz kimi, artıq iki öhdəlik var. Eyni şəkildə GitTest.java əlavə edirik. İndi şərh yoxdur, sadəcə əmrlər:

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

.gitignore ilə işləmək

Aydındır ki, biz yalnız mənbə kodunu saxlamaq istəyirik və depoda başqa heç nə istəmirik. Başqa nə ola bilərdi? Ən azı inkişaf mühitləri yaradan tərtib edilmiş siniflər və/yaxud fayllar. Git-in onlara məhəl qoymaması üçün yaradılmalı olan xüsusi bir fayl var. Biz bunu edirik: layihənin kökündə .gitignore adlı fayl yaradırıq və bu faylda hər bir sətir nəzərə alınmayacaq nümunə olacaq. Bu nümunədə git ignore aşağıdakı kimi görünür:

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

İndi baxaq:

• birinci sətir .class uzantılı bütün faylları nəzərə almamaqdır;
• ikinci sətir hədəf qovluğu və onun ehtiva etdiyi hər şeyi nəzərə almamaqdır;
• üçüncü sətir .iml uzantılı bütün fayllara məhəl qoymamaqdır;
• Dördüncü sətir .idea qovluğuna məhəl qoymamaqdır.

Bir nümunə ilə cəhd edək. Bunun necə işlədiyini görmək üçün tərtib edilmiş GitTest.class sinfini layihəyə əlavə edin və layihənin statusuna baxın:

git status

Aydındır ki, biz təsadüfən (git add -A istifadə etsək) layihəyə tərtib edilmiş sinif əlavə etmək istəmirik. Bunu etmək üçün .gitignore faylı yaradın və əvvəllər təsvir edilən hər şeyi əlavə edin: İndi layihəyə yeni öhdəçiliklə git ignore əlavə edək:

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

İndi isə həqiqət anı: Git repozitoriyasına əlavə etmək istəmədiyimiz, izlənilməmiş vəziyyətdə tərtib edilmiş GitTest.class sinifimiz var. Git ignore burada işləməlidir:

git status

Hər şey aydındır) Git ignore +1)

Filiallarla işləmək və s

Təbii ki, bir filialda işləmək bir nəfər üçün əlverişsizdir və komandada birdən çox adam olduqda qeyri-mümkündür. Bunun üçün bir filial var. Daha əvvəl dediyim kimi, filial sadəcə öhdəliklər üçün hərəkət edən göstəricidir. Bu hissədə biz müxtəlif filiallarda işləməyə baxacağıq: dəyişiklikləri bir filialdan digərinə necə birləşdirə bilərik, hansı münaqişələr yarana bilər və s. Anbardakı bütün filialların siyahısını görmək və hansı filialda olduğunuzu anlamaq üçün yazmalısınız:

git branch -a

Görürsünüz ki, bizim yalnız bir usta filialımız var və onun qarşısındakı ulduz işarəsi onun üzərində olduğumuzu bildirir. Yeri gəlmişkən, hansı filialda olduğumuzu öyrənmək üçün status yoxlamasından da (git status) istifadə edə bilərik. Sonra, filial yaratmaq üçün bir neçə variant var (bəlkə də daha çox var, mən bunlardan istifadə edirəm):

• fəaliyyət göstərdiyimiz filial əsasında yeni filial yaratmaq (99% hallarda);
• konkret öhdəlik əsasında filial yaratmaq (1%).

Xüsusi öhdəlik əsasında filial yaradın

Biz unikal öhdəlik identifikatoruna etibar edəcəyik. Onu tapmaq üçün yazırıq:

git log

Mən öhdəliyi “salam dünya əlavə etdi...” şərhi ilə vurğuladım. Onun unikal identifikatoru var - “6c44e53d06228f888f2f454d3cb8c1c976dd73f8”. Mən bu öhdəlikdən başlayaraq inkişaf şöbəsi yaratmaq istəyirəm. Bunun üçün yazacam:

git checkout -b development 6c44e53d06228f888f2f454d3cb8c1c976dd73f8

Əsas filialdan yalnız ilk iki öhdəliyi ehtiva edən filial yaradılır. Bunu yoxlamaq üçün əvvəlcə başqa filiala keçdiyimizə əmin olacağıq və oradakı öhdəliklərin sayına baxacağıq:

git status
git log

Və bu doğrudur: iki öhdəliyimiz olduğu ortaya çıxdı. Yeri gəlmişkən, maraqlı bir məqam: bu filialda hələ .gitignore faylı yoxdur, ona görə də bizim tərtib edilmiş faylımız (GitTest.class) indi izlənilməmiş vəziyyətdə vurğulanır. İndi filiallarımızı yazaraq yenidən nəzərdən keçirə bilərik:

git branch -a

Görünür ki, iki qol var - master və inkişaf - və indi biz inkişaf üzərindəyik.

Cari filiala əsaslanaraq filial yaradın

Filial yaratmağın ikinci yolu başqasının üzərində qurmaqdır. Mən master filialı əsasında filial yaratmaq istəyirəm, ona görə də əvvəlcə ona keçməliyəm, növbəti addım isə yenisini yaratmaqdır. Baxaq:

• git checkout master - master filialına keçin;
• git statusu - master-da olub olmadığını yoxlayın.

Burada siz görə bilərsiniz ki, biz master filialına keçdik, git ignore artıq burada işləyir və tərtib edilmiş sinif artıq izlənilməmiş kimi görünmür. İndi master filial əsasında yeni filial yaradırıq:

git checkout -b feature/update-txt-files

Bu filialın master ilə eyni olmadığına şübhəniz varsa, git log yazaraq və bütün öhdəliklərə baxaraq bunu asanlıqla yoxlaya bilərsiniz. Onlardan dördü olmalıdır.

Münaqişələri həll edin

Münaqişənin nə olduğunu başa düşməzdən əvvəl bir qolu digərinə birləşdirmək (birləşdirmək) haqqında danışmaq lazımdır. Bu şəkil bir budağın digərinə birləşdirildiyi prosesi göstərə bilər: Yəni əsas budaq var. Müəyyən bir məqamda ondan ikinci dərəcəli yaradılır, orada dəyişikliklər baş verir. İş bitdikdən sonra bir filialı digərinə birləşdirməlisiniz. Müxtəlif xüsusiyyətləri təsvir etməyəcəyəm: bu məqalə çərçivəsində yalnız anlayışı çatdırmaq istəyirəm və lazım gələrsə, təfərrüatları özünüz öyrənəcəksiniz. Beləliklə, nümunəmizdə biz xüsusiyyət/update-txt-files filialını yaratdıq. Filialın adına yazıldığı üçün mətni yeniləyəcəyik. İndi bu məsələ üçün yeni bir öhdəlik yaratmalısınız:

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

İndi funksiya/update-txt-files bölməsini master-a birləşdirmək istəyiriksə, master-a keçib git merge feature/update-txt-files yazmalıyıq:

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

Nəticə olaraq, indi master filialında xüsusiyyət/update-txt-fayllarına əlavə edilmiş öhdəlik də var. Bu funksiya əlavə edilib ki, siz xüsusiyyət bölməsini siləsiniz. Bunu etmək üçün yazırıq:

git branch -D feature/update-txt-files

İndiyə qədər aydındır, elə deyilmi? Vəziyyəti mürəkkəbləşdirək: indi deyək ki, txt faylını yenidən dəyişmək lazımdır. Amma indi bu fayl da sehrbazda dəyişdiriləcək. Yəni paralel olaraq dəyişəcək və yeni kodu master filialına birləşdirmək istədiyimiz bir vəziyyətdə Git nə etmək lazım olduğunu başa düşə bilməyəcək. Get! Biz master əsasında yeni filial yaradırıq, text_resource.txt-də dəyişikliklər edirik və bu məsələ üçün öhdəlik yaradırıq:

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

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

Əsas filiala gedin və bu mətn faylını xüsusiyyət bölməsi ilə eyni sətirdə yeniləyin:

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

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

İndi isə ən maraqlı məqam: siz xüsusiyyət/add-header filialından master-a dəyişiklikləri birləşdirməlisiniz. Biz master filialındayıq, ona görə etməmiz lazım olan tək şey yazmaqdır:

git merge feature/add-header

Amma test_resource.txt faylında konfliktlə nəticə əldə edəcəyik: Və burada görə bilərik ki, Git müstəqil olaraq bu kodu necə birləşdirəcəyinə qərar verə bilmir və deyir ki, biz əvvəlcə münaqişəni həll etməliyik və yalnız bundan sonra öhdəlik götürməliyik. Yaxşı, gəlin mətn redaktorunda konfliktin olduğu faylı açaq və baxaq: Git-in burada nə etdiyini başa düşmək üçün harda yazdıqlarımızı xatırlamalı və müqayisə etməlisiniz:

1. “<<<<<<< HEAD” və “=======” arasında əsas budaqda bu sətirdə olan əsas dəyişikliklərdir.
2. “=======” və “>>>>>>> xüsusiyyət/add-header” arasında xüsusiyyət/əlavə başlıq bölməsində dəyişikliklər var.

Beləliklə, Git göstərir ki, bu anda bu faylı necə birləşdirəcəyini tapa bilmədi, bu bölməni müxtəlif filiallardan iki hissəyə ayırdı və özümüz qərar verməyi təklif etdi. Tamam, güclü iradə ilə hər şeyi silmək qərarına gəldim, yalnız başlıq sözü buraxın: Dəyişikliklərin vəziyyətinə baxaq, təsvir bir az fərqli olacaq. Dəyişdirilmiş vəziyyət olmayacaq, lakin Unmged. Beləliklə, təhlükəsiz şəkildə beşinci vəziyyəti əlavə edə bilərik... Amma məncə, bu, lazımsızdır, gəlin baxaq:

git status

Biz bunun fərqli, qeyri-adi bir hal olduğuna əmin idik. Davam edək:

git add *.txt

Təsvirdə görəcəksiniz ki, onlar yalnız git commit yazmağı təklif edirlər. Dinləyirik və yazırıq:

git commit

Və hamısı budur: biz bunu belə etdik - münaqişəni konsolda həll etdik. Əlbəttə ki, inkişaf mühitlərində bunu bir az daha asan edə bilərsiniz, məsələn, Intellij IDEA-da hər şey o qədər yaxşı qurulub ki, orada bütün lazımi hərəkətləri edə bilərsiniz. Ancaq inkişaf mühiti başlıq altında çox şey edir və biz çox vaxt orada nə baş verdiyini başa düşmürük. Anlayış olmadıqda isə problemlər yarana bilər.

Uzaq depolarla işləmək

Son addım uzaq depo ilə işləmək üçün lazım olan daha bir neçə əmri başa düşməkdir. Artıq dediyim kimi, uzaq repozitoriya anbarın saxlandığı və onu klonlaya biləcəyiniz yerdir. Uzaq depoların hansı növləri var? Tonlarca misal var:

• GitHub depolar və birgə inkişaf üçün ən böyük repozitordur. Mən bunu əvvəlki məqalələrdə artıq təsvir etmişəm. Github hesabıma
  abunə olun . İşlədiyim müddətdə öyrəndiyim sahələr üzrə işlərimi orada tez-tez sərgiləyirəm.

• GitLab, öz wiki, problem izləmə sistemi , CI/CD boru kəməri və digər xüsusiyyətləri ilə Git üçün kod anbarının idarəetmə sistemini təmin edən açıq mənbəli veb- əsaslı DevOps həyat dövrü alətidir . Microsoft-un GitHub-u satın alması xəbərindən sonra bəzi tərtibatçılar GitLab-da işlərini təkrarladılar.
  

• BitBucket Mercurial və Git versiya idarəetmə sistemlərinə əsaslanan layihələrin hostinqi və birgə inkişafı üçün veb xidmətidir. Bir vaxtlar GitHub-dan böyük bir üstünlüyü var idi ki, pulsuz şəxsi depolara sahib idi. Keçən il GitHub da bu funksiyanı hər kəsə pulsuz təqdim etdi.

• Və sair…

Uzaqdan bir depo ilə işləyərkən etməli olduğunuz ilk şey layihəni yerli layihəyə klonlaşdırmaqdır. Bunun üçün yerli olaraq hazırladığımız layihəni ixrac etdim və indi hər kəs bunu yazaraq özü üçün klonlaya bilər:

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

İndi yerli olaraq layihənin tam surəti var. Layihənin ən son nüsxəsinin yerli yerləşdiyinə əmin olmaq üçün, necə deyərlər, məlumatları yazaraq atmalısınız:

git pull

Bizim vəziyyətimizdə indi uzaqdan heç nə dəyişməyib, ona görə də cavab belədir: Artıq yenilənib. Ancaq uzaq depoda bəzi dəyişikliklər etsəm, onları çəkdikdən sonra yerli yenilənəcək. Və nəhayət, son əmr məlumatları uzaq depoya köçürməkdir. Yerli olaraq bir şey etdikdə və onu uzaq bir depoya köçürmək istədikdə, əvvəlcə yerli olaraq yeni bir öhdəlik yaratmalıyıq. Bunu etmək üçün mətn faylımıza başqa bir şey əlavə edək: İndi bu, bizim üçün ümumi bir şeydir - biz bu məsələ üçün öhdəlik yaradırıq:

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

İndi bunu uzaq depoya itələmək əmri:

git push

Sənə demək istədiyim bu idi. Diqqətinizə görə təşəkkürlər. GitHub hesabıma abunə olun , burada oxuduğum və işdə istifadə etdiyim müxtəlif gözəl nümunə layihələri dərc edirəm.

faydalı bağlantılar

• Git-də rəsmi sənəd rus dilindədir . Mən onu istinad bələdçisi kimi tövsiyə edirəm.
• Git