-
1. Başlanğıc
- 1.1 Versiyaya Nəzarət Haqqında
- 1.2 Git’in Qısa Hekayəsi
- 1.3 Git Nədir?
- 1.4 Əmr Sətiri
- 1.5 Git’i Quraşdırmaq
- 1.6 İlk Dəfə Git Quraşdırması
- 1.7 Kömək Almaq
- 1.8 Qısa Məzmun
-
2. Git’in Əsasları
-
3. Git’də Branch
- 3.1 Nutshell’də Branch’lar
- 3.2 Sadə Branching və Birləşdirmə
- 3.3 Branch İdarəedilməsi
- 3.4 Branching İş Axınları
- 3.5 Uzaq Branch’lar
- 3.6 Rebasing
- 3.7 Qısa Məzmun
-
4. Server’də Git
- 4.1 Protokollar
- 4.2 Serverdə Git Əldə Etmək
- 4.3 Sizin öz SSH Public Key’nizi yaratmaq
- 4.4 Server qurmaq
- 4.5 Git Daemon
- 4.6 Smart HTTP
- 4.7 GitWeb
- 4.8 GitLab
- 4.9 Üçüncü Tərəf Seçimləri
- 4.10 Qısa Məzmun
-
5. Paylanmış Git
-
6. GitHub
-
7. Git Alətləri
- 7.1 Reviziya Seçimi
- 7.2 Interaktiv Səhnələşdirmə
- 7.3 Stashing və Təmizləmə
- 7.4 İşinizin İmzalanması
- 7.5 Axtarış
- 7.6 Tarixi Yenidən Yazmaq
- 7.7 Reset Demystified
- 7.8 İnkişaf etmiş Birləşmə
- 7.9 Rerere
- 7.10 Git ilə Debugging
- 7.11 Alt Modullar
- 7.12 Bundling
- 7.13 Dəyişdirmək
- 7.14 Etibarlı Yaddaş
- 7.15 Qısa Məzmun
-
8. Git’i Fərdiləşdirmək
- 8.1 Git Konfiqurasiyası
- 8.2 Git Atributları
- 8.3 Git Hook’ları
- 8.4 Git-Enforced Siyasət Nümunəsi
- 8.5 Qısa Məzmun
-
9. Git və Digər Sistemlər
- 9.1 Git Müştəri kimi
- 9.2 Git’ə Miqrasiya
- 9.3 Qısa Məzmun
-
10. Git’in Daxili İşləri
- 10.1 Plumbing və Porcelain
- 10.2 Git Obyektləri
- 10.3 Git Referansları
- 10.4 Packfile’lar
- 10.5 Refspec
- 10.6 Transfer Protokolları
- 10.7 Maintenance və Məlumatların Bərpası
- 10.8 Mühit Dəyişənləri
- 10.9 Qısa Məzmun
-
A1. Appendix A: Digər Mühitlərdə Git
- A1.1 Qrafik interfeyslər
- A1.2 Visual Studio’da Git
- A1.3 Visual Studio Code’da Git
- A1.4 Eclipse’də Git
- A1.5 Sublime Text’də Git
- A1.6 Bash’da Git
- A1.7 Zsh’də Git
- A1.8 PowerShell’də Git
- A1.9 Qısa Məzmun
-
A2. Appendix B: Proqramlara Git Daxil Etmək
- A2.1 Əmr-sətri Git
- A2.2 Libgit2
- A2.3 JGit
- A2.4 go-git
- A2.5 Dulwich
-
A3. Appendix C: Git Əmrləri
- A3.1 Quraşdırma və Konfiqurasiya
- A3.2 Layihələrin Alınması və Yaradılması
- A3.3 Sadə Snapshotting
- A3.4 Branching və Birləşmə
- A3.5 Layihələrin Paylaşılması və Yenilənməsi
- A3.6 Yoxlama və Müqayisə
- A3.7 Debugging
- A3.8 Patching
- A3.9 E-poçt
- A3.10 Xarici Sistemlər
- A3.11 İdarəetmə
- A3.12 Plumbing Əmrləri
6.2 GitHub - Bir Layihəyə Töhfə Vermək
Bir Layihəyə Töhfə Vermək
Hesabımız qurulduğuna görə mövcud bir layihəyə töhfə verməyinizdə faydalı ola biləcək bəzi detalları nəzərdən keçirək.
Forking Layihələr
Push giriş imkanı olmayan bir layihəyə töhfə vermək istəyirsinizsə, layihəni “fork” edə bilərsiniz. Bir layihəni “fork” etdikdə, GitHub tamamilə sizə məxsus olan bir layihənin bir nüsxəsini düzəldəcəkdir; o sizin namespace-nizdə yaşayır və ona push edə bilərsiniz.
|
Note
|
Tarixən, “fork” termini kontekstdə bir qədər mənfi olmuşdur, yəni kimsə açıq bir mənbə layihəsini fərqli bir istiqamətə apardığı, bəzən rəqabətçi bir layihə yaratdığı və iştirakçıları böldüyü anlamına gəlir. GitHub-da, “fork” sadəcə öz namespace-nizdəki eyni layihədir, daha açıq bir şəkildə töhfə verməyin bir yolu olaraq bir layihədə public olaraq dəyişikliklər etməyə imkan verir. |
Bu yolla, layihələr push etmək üçün istifadəçilərin tərəfdaş kimi əlavə edilməsindən narahat olmur. İnsanlar bir layihə fork edə bilər, onu push edə bilər və dəyişiklikləri orijinal depoda geri qaytara biləcəyimiz Pull Request yaradaraq geri qaytara bilər. Bu kod nəzərdən keçirilmiş müzakirə mövzusunu açır və sonra sahibi və töhfəçisi dəyişiklik barədə sahibindən razı qalana qədər əlaqə saxlaya bilər, bu zaman sahibi onu birləşdirə bilər.
Bir layihə fork etmək üçün layihə səhifəsinə daxil olun və səhifənin yuxarı sağındakı “Fork” düyməsini basın.
Bir neçə saniyədən sonra kodun özünün yazıla bilən nüsxəsi ilə yeni layihə səhifənizə aparılacaqsınız.
GitHub Axını
GitHub, Pull Requests mərkəzində, müəyyən bir əməkdaşlıq işinin ətrafında hazırlanmışdır. Bu axın tək paylaşılan bir depo içərisində sıx birləşən bir komanda ilə işləməyinizə və ya qlobal miqyasda bölüşdürülən bir şirkətə və ya onlarla fork vasitəsilə bir layihəyə töhfə verən kənar şəbəkələrə işləməyinizə kömək edir. Bu Git’də Branch ilə əhatə olunmuş Mövzu Branch-ları iş axınına yönəldilmişdir.
Ümumillikdə bu necə işləyir.
-
Layihəni fork et.
-
master-dən mövzu branch-ı yarat. -
Layihəni yaxşılaşdırmaq üçün bəzi commit-lər verin.
-
Bu branch-ı GitHub layihənizə push edin.
-
Github-da Pull Request-i açın.
-
Müzakirə edin və commit etməyə davam edin.
-
Layihə sahibi Pull Request-i birləşdirir və ya bağlayır.
-
Yenilənmiş master-i fork-a sinxronlaşdırın.
Bu əsasən İnteqrasiya-Menecer İş Axınları-da İnteqrasiya Meneceri iş axınıdır, lakin dəyişiklikləri ünsiyyət və nəzərdən keçirmək üçün e-poçtdan istifadə etmək əvəzinə komandalar GitHub-un veb əsaslı vasitələrindən istifadə edirlər.
Bu axını istifadə edərək GitHub’da açıq bir mənbə layihəsinə dəyişiklik təklif etmək nümunəsini nəzərdən keçirək.
Pull Request Yaratmaq
Tony, Arduino ilə proqramlaşdırıla bilən mikrokontrolleri işə salmaq üçün kod axtarır və Github-da https://github.com/schacon/blink-də əla program faylı tapır.
Yeganə problem yanıb-sönmə sürətinin çox sürətli olmasıdır. Düşünürük ki, hər bir vəziyyət dəyişikliyi arasındakı 1-i əvəzinə 3 saniyə gözləmək daha yaxşıdır. Beləliklə, proqramı təkmilləşdirək və təklif olunan dəyişiklik kimi yenidən layihəyə təqdim edək.
Birincisi, layihənin öz nüsxəsini əldə etmək üçün əvvəlcədən qeyd edildiyi kimi Fork düyməsini sıxırıq.
Burada istifadəçi adımız “tonychacon” olduğundan bu layihənin kopyası və onu redaktə edə biləcəyimiz yer https://github.com/tonychacon/blink-dır .
Local şəkildə klonlaşdıracağıq, bir mövzu branch-ı yaradacağıq, kod dəyişikliyini edib nəhayət bu dəyişikliyi yenidən GitHub-a köçürəcəyik.
$ git clone https://github.com/tonychacon/blink (1)
Cloning into 'blink'...
$ cd blink
$ git checkout -b slow-blink (2)
Switched to a new branch 'slow-blink'
$ sed -i '' 's/1000/3000/' blink.ino (macOS) (3)
# If you're on a Linux system, do this instead:
# $ sed -i 's/1000/3000/' blink.ino (3)
$ git diff --word-diff (4)
diff --git a/blink.ino b/blink.ino
index 15b9911..a6cc5a5 100644
--- a/blink.ino
+++ b/blink.ino
@@ -18,7 +18,7 @@ void setup() {
// the loop routine runs over and over again forever:
void loop() {
digitalWrite(led, HIGH); // turn the LED on (HIGH is the voltage level)
[-delay(1000);-]{+delay(3000);+} // wait for a second
digitalWrite(led, LOW); // turn the LED off by making the voltage LOW
[-delay(1000);-]{+delay(3000);+} // wait for a second
}
$ git commit -a -m 'Change delay to 3 seconds' (5)
[slow-blink 5ca509d] Change delay to 3 seconds
1 file changed, 2 insertions(+), 2 deletions(-)
$ git push origin slow-blink (6)
Username for 'https://github.com': tonychacon
Password for 'https://tonychacon@github.com':
Counting objects: 5, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 340 bytes | 0 bytes/s, done.
Total 3 (delta 1), reused 0 (delta 0)
To https://github.com/tonychacon/blink
* [new branch] slow-blink -> slow-blink-
Layihənin fork-nu local olaraq klonlayın.
-
Açıqlayıcı mövzu branch-ı yaradın.
-
Kod dəyişikliyimizi edin.
-
Dəyişiklikin yaxşı olduğunu yoxlayın.
-
Dəyişikliklərimizi mövzu branch-na commit edin.
-
Yeni mövzu branch-mızı GitHub fork-na geri push edin.
İndi GitHub üzərindəki fork-muza qayıtsaq, görərik ki, GitHub-ın yeni bir mövzu branch-nı yuxarıya push etdiyimizi fərq etdiyini və dəyişikliklərimizi yoxlamaq və orijinal layihəyə Pull Request açmaq üçün bizə böyük bir yaşıl düyməni təqdim etdiyini görə bilərik.
Alternativ olaraq, https://github.com/<user>/<project>/branches-da “Branches” səhifəsinə keçərək branch-ınızı tapmaq və oradan yeni Pull Request açmaq olar.
Bu yaşıl düyməni bassaq, Pull Request’ə başlıq və təsvir verməyimizi xahiş edən bir ekran görərik. Buna bir az effort göstərmək demək olar ki, həmişə dəyərlidir, çünki yaxşı bir təsvir orijinal layihənin sahibinə nə etmək istədiyinizi, təklif olunan dəyişikliklərin düzgün olub olmadığını və dəyişikliklərin qəbul edilməsinin orijinal layihəni yaxşılaşdıracağını müəyyən etməyə kömək edir.
Mövzu branch-mızda da master branch-nın (bu vəziyyətdə yalnız bir) “əvvəlində” olan commit-lərin bir hissəsini və layihə sahibi tərəfindən birləşdirilməsi durumunda bu branch əldə edəcəyi bütün dəyişikliklərin vahid fərqliliyini görürük.
Bu ekrandakı Create pull request düyməsini basdığınızda, forked etdiyiniz layihənin sahibi kiməsə dəyişiklik təklif etdiyi barədə bir bildiriş alacaq və bu məlumatların hamısını özündə saxlayan səhifəyə bağlayacaq.
|
Note
|
Töhfə edəcək şəxs dəyişikliyə hazır olduqda bu kimi public layihələr üçün tez-tez istifadə olunur, baxmayaraq ki, bu, inkişaf dövrünün başlanğıcında olan daxili layihələrdə də istifadə olunur. Pull Request açıldıqdan sonra mövzu bölməsinə pushing davam edə bildiyiniz üçün,ümumulikdə tez açılır və prosesin sonunda açılmaq əvəzinə, bir kontekstdə bir komanda şəklində işləməyi təkrarlamaq üçün istifadə olunur. |
Pull Request ilə Təkrarlama
Bu anda, layihə sahibi təklif olunan dəyişikliyə baxa bilər və onu birləşdirə bilər, rədd edə və ya şərh verə bilər. Deyək ki, o fikri bəyənir, amma işığın sönülü qalması üçün biraz daha uzun müddətə üstünlük verir.
GitHub-da Paylanmış Git-də təqdim olunan iş axınlarında e-poçt üzərində və bu söhbətin baş verə biləcəyi yerlərdə bu onlayn rejimdə baş verir. Layihə sahibi vahid fərqi nəzərdən keçirə bilər və sətirlrdən hər hansı birini tıklayaraq rəy yaza bilər.
Təminatçı bu açıqlamanı verdikdən sonra Pull Request-i açan şəxs (və həqiqətən, deponu seyr edən hər kəs) bir bildiriş alacaq. Daha sonra bunu özəlləşdirməyə keçəcəyik, amma e-poçt bildirişləri olsaydı, Tony bu kimi bir e-poçt alacaq:
Hər kəs Pull Request-də ümumi şərhlər buraxa bilər. Pull Request müzakirə səhifəsi-də layihə sahibinin həm kod xəttini şərh etdiyini, həm də müzakirə bölməsində ümumi bir şərh buraxmağını görə bilərik. Kod şərhlərinin də söhbətə gətirildiyini görə bilərsiniz.
İndi töhfəçi dəyişikliklərin qəbul edilməsi üçün nə etməli olduqlarını görə bilər. Xoşbəxtlikdən bu çox sadədir. E-poçt üzərində seriyalarınızı yenidən yuvarlaqlaşdırmaq və poçt siyahısına yenidən göndərmək məcburiyyətində ola bilərsiniz, GitHub ilə mövzu branch-na yenidən qoşulun və avtomatik olaraq Pull Request-i yeniləyin. Pull Request final da köhnə kod şərhinin yenilənmiş Pull Request-də daraldığını görə bilərsiniz, çünki o vaxtdan bəri dəyişdirilmiş bir xətt üzərində hazırlanmışdır.
Mövcud Pull Request commit etməyə bildiriş vermir, buna görə Tony düzəlişlərini push etdikdən sonra layihə sahibinə tələb olunan dəyişikliyi etdiyini bildirmək üçün rəy bildirməyə qərar verir.
Diqqəti cəlb edən bir maraqlı məqam budur ki, bu Pull Request-dəki “Files Changed” sekmesini klikləsəniz, “unified” edilmiş fərqini əldə edəcəksiniz - yəni sizə təqdim ediləcək ümumi məcmu fərq Bu mövzu branch-ı birləşdirildiyi təqdirdə əsas branchdır.
git diff baxımından, bu avtomatik olaraq bu Pull Request-in dayandığı branch üçün avtomatik olaraq git diff master...<branch> göstərir.
Bu növ fərq haqqında daha çox məlumat üçün Nəyin Təqdim Olunduğunu Müəyyənləşdirmək səhifəsinə baxın.
Gördüyünüz digər bir şey, GitHub Pull Request-nin təmiz bir şəkildə birləşdiyini və serverdə birləşmə üçün bir düyməni təmin etdiyini yoxlamaqdır. Bu düymə yalnız depoya yazma imkanınız varsa və mənasız birləşmə mümkündürsə göstərilir. Bu düyməni basarsanız, GitHub birləşmə sürətli ola bilsə də, yenə də birləşmə commit-i yaradacaq deməkdir.
İstəsəniz, branch-ı sadəcə pull down edib local olaraq birləşdirə bilərsiniz.
Bu branch-ı master branch-ına birləşdirsəniz və GitHub’a push etsəniz, Pull Request-i avtomatik olaraq bağlanacaqdır.
Bu GitHub layihələrinin çoxunun istifadə etdiyi əsas iş axınlarıdır. Mövzu branch-ları yaradılır, Pull Request-lər açılır, müzakirə baş verir, bəlkə branch üzərində daha çox iş görülür və nəticədə sorğu ya bağlanır, ya da birləşdirilir.
|
Note
|
Yalnız Forks Deyil
Qeyd etməyiniz vacibdir ki, eyni depo içərisində iki branch arasında Pull Request aça bilərsiniz.
Biri ilə bir xüsusiyyət üzərində işləyirsinizsə və hər ikinizin də layihəyə yazılı giriş imkanınız varsa, bir mövzu branch-nı depoya göndərə bilərsiniz və kodu başlatmaq üçün eyni layihənin |
Ətraflı Pull Request-lər
İndi GitHub-da bir layihəyə töhfə vermək əsaslarını izah etdik. İndi isə onlardan istifadə etməkdə daha effektiv olmağınız üçün Pull Requests ilə bağlı bir neçə maraqlı məsləhət və tövsiyələri nəzərdən keçirək.
Pull Requests Patch-lar kimi
Bir çox layihənin həqiqətən Pull Requests üçün təmiz tətbiq edilməli mükəmməl patch-lar sırası kimi düşünmədiklərini başa düşmək vacibdir, çünki əksər poçt siyahısına əsaslanan layihələr patch seriyalarını düşünür. GitHub layihələrinin əksəriyyəti birləşmə ilə tətbiq olunan vahid bir fərqlə sona çatan təklif olunan dəyişiklik ətrafında iterativ söhbətlər kimi Pull Request branch-ları haqqında düşünür.
Bu vacib bir fərqdir, çünki dəyişiklik ümumiyyətlə kodun mükəmməl olduğu düşünülməmişdən əvvəl təklif olunur, bu da poçt siyahısına əsaslanan patch seriyası töhfələri ilə daha nadirdir. Bu, təmirçilərlə əvvəlcədən söhbət etməyə imkan verir ki, lazımi həll yolu tapmaq daha çox cəmiyyətin efortunu artırsın. Pull Request ilə kod təklif edildikdə və texniki işçilər və ya icma bir dəyişiklik təklif edərsə, patch seriyası ümumiyyətlə yenidən yuvarlanmır, əksinə fərqi branch-a yeni bir commit kimi push edilir, söhbəti kontekstində irəli aparır.
Məsələn, geri qayıdıb yenidən Pull Request final -ə baxsanız, əmanətçinin etdiyi commit-i geri qaytarmadığını və başqa Pull Request göndərmədiyini görəcəksiniz. Bunun əvəzinə yeni commit-lər əlavə etdilər və mövcud branch-a push etdilər. Bu yolla geri dönsəniz və gələcəkdə bu Pull Request-ə baxsanız, qərarların niyə verildiyi kontekstində asanlıqla tapa bilərsiniz. Saytdakı “Merge” düyməsini basaraq Pull Request-ə istinad edən birləşmə əməliyyatı yaradır ki, geri qayıtmaq və lazım olduqda orijinal söhbəti araşdırmaq asandır.
Upstream ilə Dəvam Etmək
Pull Request köhnəlirsə və ya başqa cür təmiz şəkildə birləşmirsə, təmirçi asanlıqla birləşə bilməsi üçün onu düzəltmək istəyəcəksiniz. GitHub bunu sizin üçün sınayacaq və Pull Request-in altındakı birləşmənin mənasız olub-olmadığı barədə sizə bildirəcək.
Əgər Pull Request təmiz birləşmir kimi bir şey görsəniz, branch-ınızı yaşıl rəngə çevirməsini və təmirçi əlavə iş görməməsi üçün düzəltmək istəyəcəksiniz.
Bunu etmək üçün iki əsas seçiminiz var.
Siz ya da branch-nızı hədəf branch-ın hər hansı birinin üstünə qaytara bilərsiniz (normal olaraq forked etdiyiniz depo-nun master branch-ı) və ya hədəf branch-ı branch-nıza birləşdirə bilərsiniz.
GitHub-da developerlərin əksəriyyəti əvvəlki hissədə danışdığımız səbəblərə görə son hissəni etməyi seçəcək. Əhəmiyyətli olan tarix və son birləşmə, buna görə reabilitasiya biraz daha təmiz bir tarixdən daha çox şey almır və bunun əvəzinə çox daha çətin və səhvlərə meyllidir.
Pull Request-nizi birləşdirilə bilmək üçün hədəf branch-na birləşdirmək istəyirsinizsə, orijinal deponu yeni bir uzaqdan əlavə edin, ondan götürün, həmin deponun əsas branch-nı mövzu branch-na birləşdirin, hər hansı bir problemi həll edin və nəhayət geri push edin Pull Request açdığınız eyni branch-a geri göndərin.
Məsələn, deyək ki, əvvəllər istifadə etdiyimiz “tonychacon” nümunəsində, orijinal müəllif Pull Request-ində konflikt yaradan bir dəyişiklik etdi. Gəlin bu addımlardan keçək.
$ git remote add upstream https://github.com/schacon/blink (1)
$ git fetch upstream (2)
remote: Counting objects: 3, done.
remote: Compressing objects: 100% (3/3), done.
Unpacking objects: 100% (3/3), done.
remote: Total 3 (delta 0), reused 0 (delta 0)
From https://github.com/schacon/blink
* [new branch] master -> upstream/master
$ git merge upstream/master (3)
Auto-merging blink.ino
CONFLICT (content): Merge conflict in blink.ino
Automatic merge failed; fix conflicts and then commit the result.
$ vim blink.ino (4)
$ git add blink.ino
$ git commit
[slow-blink 3c8d735] Merge remote-tracking branch 'upstream/master' \
into slower-blink
$ git push origin slow-blink (5)
Counting objects: 6, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (6/6), done.
Writing objects: 100% (6/6), 682 bytes | 0 bytes/s, done.
Total 6 (delta 2), reused 0 (delta 0)
To https://github.com/tonychacon/blink
ef4725c..3c8d735 slower-blink -> slow-blink-
Orijinal depoya
upstreamadı verilən bir remote kimi əlavə edin. -
Ən yeni işi remote fetch edin.
-
Həmin deponun əsas branch-nı mövzu branch-na birləşdirin.
-
Baş verən konflikti həll edin.
-
Eyni mövzu branch-na geri push edin.
Bunu etdikdən sonra Pull Request avtomatik olaraq yenilənir və təmiz birləşdiyini yoxlamaq üçün yenidən yoxlanılır.
Git ilə əlaqəli ən gözəl şeylərdən biri də dəvamlı bunu edə biləcəyinizdir. Çox uzun müddətdir davam edən bir layihəniz varsa, hədəf branch-ından asanlıqla təkrar-təkrar birləşə bilərsiniz və yalnız birləşdiyiniz müddətdən bəri yaranan konfliktləri həll etmək məcburiyyətindəsiniz və bu prosesi çox idarə edə bilərsiniz.
Branch-ı təmizləmək üçün istədiyiniz kimi tamamilə dəyişdirə bilərsiniz, ancaq Pull Request-in artıq açıldığı branch-ı push etməməyiniz tövsiyə olunur. Başqa insanlar onu aşağı pull edib daha çox iş görsələr, Rebasing-in Təhlükələri-də göstərilən məsələlərin hamısına qoşulursunuz. Bunun əvəzinə, yenidən satılan branch-ı GitHub-dakı yeni bir branch-a push edin və köhnəsinə istinad edən yeni bir Pull Request açın, sonra orijinalı bağlayın.
İstinadlar
Növbəti sualınız “How do I reference the old Pull Request?” ola bilər. GitHub-da yaza biləcəyiniz başqa yerlərə istinad etmək üçün bir çox yolun var.
Başqa bir Pull Request-i və ya bir məsələni necə cross-reference edəcəyimizdən başlayaq.
Bütün Pull Request və məsələlərinə nömrələr verilir və onlar layihə çərçivəsində unikaldır.
Məsələn, Pull Request #3 və Issue #3.yoxdur.
Başqa birindən hər hansı bir Pull Request və ya Issue-a istinad etmək istəyirsinizsə, sadəcə hər hansı bir şərhdə və ya təsvirdə #<num> qoya bilərsiniz.
Issue və ya Pull request başqa bir yerdə yaşayırsa, daha konkret ola bilərsiniz; Girdiyiniz deponun bir fork-unda Bir Issue və ya Pull Request-nə müraciət etsəniz, username#<num> yazın və ya başqa bir depoda bir şeyə istinad etmək üçün username/repo#<num> yazın.
Bir nümunəyə baxaq. Əvvəlki misalda branch-ı yenidən düzəltdik, bunun üçün yeni bir pull request yaratdıq və indi köhnə pull request-ni yenisindən istinad etmək istədiyimizi varsayaq. Ayrıca deponun fork-undakı bir məsələyə və tamamilə fərqli bir layihədəki bir məsələyə istinad etmək istəyirik. Təsviri yalnız Cross references in a Pull Request kimi doldura bilərik.
When we submit this pull request, we’ll see all of that rendered like Pull Request-də göstərilən arayışlar.
Diqqət yetirin ki, oraya qoyduğumuz GitHub URL-i yalnız lazım olan məlumatlara qısaldılmışdır.
İndi Tony geri qayıtsa və orijinal Pull Request-i bağlasa, GitHub’ın avtomatik olaraq Pull Request timeline-da bir izləmə hadisəsi yaratdığını görə bilərik. Bu o deməkdir ki, bu Pull Request-i ziyarət edən və qapalı olduğunu görən hər kəs onu əvəz edənə asanlıqla geri qayıda bilər. Bağlantı Qapalı Pull Request-i qrafikində yeni Pull Request ilə yenidən əlaqələndirin kimi bir şeyə bənzəyəcəkdir.
Nömrələrin verilməsindən əlavə, SHA-1 tərəfindən müəyyən bir commit-ə də istinad edə bilərsiniz. Tam 40 simvol SHA-1 göstərməlisiniz, ancaq GitHub bunu bir şərhdə görsə birbaşa commit-ə bağlayacaqdır. Yenə də, məsələlər ilə əlaqəli şəkildə fork-lar və ya digər depolarda olan istinadlara istinad edə bilərsiniz.
GitHub Flavored Markdown
Digər məsələlərlə əlaqələndirmək GitHub-da demək olar ki, hər hansı bir mətn qutusu ilə edə biləcəyiniz maraqlı işlərin başlanğıcıdır. Issue və Pull Request təsvirləri, şərhlər, kod şərhləri və daha çox da “GitHub Flavored Markdown” adlandırılandan istifadə edə bilərsiniz. Markdown düz mətnlə yazmaq kimidir, lakin zəngin şəkildə ifadə olunur.
Markdown istifadə edərək şərhlərin və ya mətnin necə yazılacağına və sonra göstərildiyinə dair bir nümunə üçün Yazılı və göstərildiyi kimi GitHub Flavored Markdown nümunəsi baxın.
Markdownun GitHub özəlliyi əsas Markdown sintaksisindən kənarda edə biləcəyiniz daha çox şey əlavə edir. FaydalıPull Request və ya Issue ilə əlaqədar şərhlər və ya açıqlamalar yaratdıqda bunların hamısı həqiqətən faydalı ola bilər.
Tapşırıq Siyahıları
GitHub-a məxsus Markdown xüsusiyyəti Xüsusilə Pull Requests-də istifadə üçün həqiqətən birinci faydalı Tapşırıqlar Siyahısıdır. Tapşırıq siyahısı işinizi yerinə yetirmək istədiyiniz checkbox siyahısıdır. Onları bir Issue və ya Pull Request salmaq maddənin tamamlanmadığını düşünmədən əvvəl nə etmək istədiyinizi göstərir.
Bu kimi bir tapşırıq siyahısı yarada bilərsiniz:
- [X] Write the code
- [ ] Write all the tests
- [ ] Document the codePull Request və ya Issue təsvirinə daxil etsək, onun Bir Markdown şərhində göstərilən tapşırıq siyahıları kimi göstərildiyini görərik.
Bu tez-tez Pull Requests-də birləşməyə hazır olmamışdan əvvəl branch-da nə etmək istədiyinizi göstərmək üçün istifadə olunur. Əla tərəf odur ki, rəyi yeniləmək üçün checkbox-ları klik edə bilərsiniz - tapşırıqları yoxlamaq üçün birbaşa Markdown-u düzəltməyə ehtiyac yoxdur.
Bundan əlavə, GitHub sizinIssues and Pull Requests-nizdə tapşırıq siyahılarını axtaracaq və onları siyahıya alan səhifələrdə metadata kimi göstərəcəkdir. Məsələn, tapşırıqları olan Pull Request varsa və bütün Pull Request-lərin Baxış səhifəsinə baxsanız, bunun nə qədər yerinə yetirildiyini görə bilərsiniz. Bu, insanların Pull Requests-in alt hissələrə ayrılmasına kömək edir və digər insanlara branch-ın inkişafını izləməyə kömək edir. Bunun bir nümunəsini Pull Request siyahısında tapşırıq siyahısı xülasəsi-də görə bilərsiniz.
Erkən Pull Request-i açdığınızda və xüsusiyyəti həyata keçirməklə inkişafı izləmək üçün istifadə edərkən bunlar olduqca faydalıdır.
Kod Parçaları
Ayrıca şərhlərə kod parçaları əlavə edə bilərsiniz. Bu, branch-ınızda commit kimi yerinə yetirmədən əvvəl etməyə çalışdığınız bir şeyi təqdim etmək üçün Pull Request-in həyata keçirə biləcəyi nümunə kodu əlavə etmək üçün istifadə olunur.
Bir parça parça əlavə etmək üçün onu arxa hissələrdə “hasar” etməlisiniz.
```java
for(int i=0 ; i < 5 ; i++)
{
System.out.println("i is : " + i);
}
```Orada java ilə etdiyimiz kimi bir dil adını əlavə etsəniz, GitHub parçanı vurğulamaq üçün sintaksis etməyə çalışacaqdır. Yuxarıda göstərilən nümunə vəziyyətində Hasarlanmış kod nümunəsi göstərildi kimi göstərməyə son verərdi.
Sitat Gətirmək
Uzun bir şərhin kiçik bir hissəsinə cavab verirsinizsə, digər şərhdən seçilmiş şəkildə > işarəsi ilə sətirləri öncədən çıxara bilərsiniz.
Əslində, bu o qədər yaygın və faydalıdır ki, bunun üçün bir klaviatura qısa yol var.
Bir şərhdə mətni birbaşa qeyd etmək istəsəniz və r düyməsini vursanız, o mətni sizin üçün şərh qutusundan sitat gətirəcəkdir.
Sitatlar bu kimi bir şeyə bənzəyir:
> Whether 'tis Nobler in the mind to suffer
> The Slings and Arrows of outrageous Fortune,
How big are these slings and in particular, these arrows?Göstəriləndən sonra şərh Sitat gətirməyə nümunə kimi görünəcəkdir.
Emoji
Nəhayət, şərhlərdə emoji istifadə edə bilərsiniz. Bu, həqiqətən, bir çox GitHub Issues and Pull Requests gördüyünüz şərhlərdə olduqca geniş istifadə olunur.
Finally, you can also use emoji in your comments.
This is actually used quite extensively in comments you see on many GitHub Issues and Pull Requests.
GitHub’da hətta bir emoji köməkçisi var.
Bir şərh yazırsınızsa və : simvolu ilə başlasanız, bir avtomatik tamamlayıcı axtardığınızı tapmağa kömək edəcəkdir.
Emojilər şərhin hər hansı bir yerində :<name>: şəklini alırlar.
Məsələn, bu kimi bir şey yaza bilərsiniz:
I :eyes: that :bug: and I :cold_sweat:.
:trophy: for :microscope: it.
:+1: and :sparkles: on this :ship:, it's :fire::poop:!
:clap::tada::panda_face:Təqdim edildikdə, Heavy emoji commenting kimi bir şey görünür.
Bu inanılmaz dərəcədə faydalı olduğundan deyil, amma duyğuları çatdırmaq çətin olan bir mühitə əyləncə və duyğu elementi əlavə edir.
|
Note
|
Bu günlərdə emoji simvollarından istifadə edən bir çox veb xidmətləri var. Demək istədiyinizi ifadə edən emoji tapmaq üçün istinad üçün səhifəni burdan tapa bilərsiniz: |
Şəkillər
Bu texniki olaraq GitHub Flavored Markdown deyil, amma olduqca faydalıdır. URL-lərini tapmaq və yerləşdirmək çətin ola biləcək şərhlərə Markdown şəkil bağlantılarını əlavə etməklə GitHub şəkilləri onları daxil etmək üçün mətn sahələrinə drag və drop etməyə imkan verir.
Şəkilləri yükləmək və avtomatik yerləşdirmək üçün drag və drop edin -ə baxsanız, mətn sahəsinin üstündəki kiçik bir “Parsed as Markdown” işarəsini görə bilərsiniz. Bunun üzərinə basaraq GitHub-da Markdown ilə edə biləcəyiniz hər şeyin dolğun bir vərəqini verəcəksiniz.
GitHub Public Depolarınızı Yeniləyin
Bir GitHub deposunu fork etdikdən sonra, depo (sizin "fork") orijinaldan asılı olmayaraq mövcuddur. Xüsusilə, orijinal deponuzda yeni commitlər olduqda, GitHub sizə aşağıdakı kimi bir mesajla məlumat verir:
This branch is 5 commits behind progit:master.Lakin GitHub deponuz GitHub tərəfindən avtomatik olaraq yenilənməyəcəkdir; bu özünüzün etməli olduğunuz bir şeydir. Xoşbəxtlikdən, bunu etmək çox asandır.
Bunu etmək üçün bir konfiqurasiya tələb olunmur.
Məsələn, https://github.com/progit/progit2.git-dən ayrılmısınızsa, bu master branch-nızı bu cür aktuallaşdıra bilərsiniz:
$ git checkout master (1)
$ git pull https://github.com/progit/progit2.git (2)
$ git push origin master (3)-
Əgər başqa branch-dasınızsa,
master-ə qayıdın. -
https://github.com/progit/progit2.git-dən dəyişiklikləri fetch edin və onlarımaster-ə birləşdirin. -
masterbranch-nızıorigin-ə push edin.
Bu işləyir, ancaq URL almaq üçün hər dəfə yazmaq məcburiyyətində qalır. Bu işi bir az konfiqurasiya ilə avtomatlaşdıra bilərsiniz:
$ git remote add progit https://github.com/progit/progit2.git (1)
$ git branch --set-upstream-to=progit/master master (2)
$ git config --local remote.pushDefault origin (3)-
Mənbə deposunu əlavə edin və ona bir ad verin. Budur, onu
progitadlandırmağı seçdim.. -
progitremote-undan fetch etmək üçünmasterbranch-nızı qurun. -
Defolt deponu
originolaraq təyin edin.
Bunu etdikdən sonra iş axını daha asan olur:
$ git checkout master (1)
$ git pull (2)
$ git push (3)-
Əgər başqa branch-dasınızsa,
master-ə qayıdın. -
progit-dən dəyişiklikləri fetch edin və dəyişikliklərimaster-ə birləşdirin. -
masterbranch-nızıorigin-ə push edin.
Bu yanaşma faydalı ola bilər, amma heç bir yararsız yanı yox deyil.
Git səmimi şəkildə bu işi sizin üçün edəcək, ancaq master-ə commit etsəniz,progit-dən pull edin, sonra origin- push etsəniz sizə xəbərdarlıq etməz - bütün bu əməliyyatlar bu quraşdırma ilə etibarlıdır.
