Git 🌙
Chapters ▾ 2nd Edition

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.

``Fork'' düyməsi
Figure 89. “Fork” düyməsi

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.

  1. Layihəni fork et.

  2. master-dən mövzu branch-ı yarat.

  3. Layihəni yaxşılaşdırmaq üçün bəzi commit-lər verin.

  4. Bu branch-ı GitHub layihənizə push edin.

  5. Github-da Pull Request-i açın.

  6. Müzakirə edin və commit etməyə davam edin.

  7. Layihə sahibi Pull Request-i birləşdirir və ya bağlayır.

  8. 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.

Töhfə vermək istədiymiz layihə
Figure 90. Töhfə vermək istədiymiz layihə

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
  1. Layihənin fork-nu local olaraq klonlayın.

  2. Açıqlayıcı mövzu branch-ı yaradın.

  3. Kod dəyişikliyimizi edin.

  4. Dəyişiklikin yaxşı olduğunu yoxlayın.

  5. Dəyişikliklərimizi mövzu branch-na commit edin.

  6. 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.

Pull Request düyməsi
Figure 91. Pull Request düyməsi

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.

Pull Request yaratma səhifəsi
Figure 92. Pull Request yaratma səhifəsi

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.

PR xətt şərhi
Figure 93. Pull Request-də müəyyən bir kod xəttinə şərh verin

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:

E-poçt bildirişləri
Figure 94. E-poçt bildirişləri olaraq göndərilən şərhlər

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.

PR müzakirə səhifəsi
Figure 95. Pull Request müzakirə səhifəsi

İ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.

PR final
Figure 96. Pull Request final

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 master branch-na Pull Request aça bilərsiniz. Forking-ə ehtiyac yoxdur.

Ə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.

PR birləşmə uğursuzluğu
Figure 97. Pull Request təmiz birləşmir

Ə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
  1. Orijinal depoya upstream adı verilən bir remote kimi əlavə edin.

  2. Ən yeni işi remote fetch edin.

  3. Həmin deponun əsas branch-nı mövzu branch-na birləşdirin.

  4. Baş verən konflikti həll edin.

  5. 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.

PR düzəldi
Figure 98. Pull Request indi təmiz birləşir

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 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.

PR references
Figure 99. Cross references in a Pull Request

When we submit this pull request, we’ll see all of that rendered like Pull Request-də göstərilən arayışlar.

PR istinadlar göstərilib
Figure 100. 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.

PR bağlıdır
Figure 101. Qapalı Pull Request-i qrafikində yeni Pull Request ilə yenidən əlaqələndirin

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.

Markdown nümunəsi
Figure 102. Yazılı və göstərildiyi kimi GitHub Flavored Markdown nümunəsi

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 code

Pull 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.

Nümunə Tapşırıq Siyahısı
Figure 103. Bir Markdown şərhində göstərilən tapşırıq siyahıları

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.

Tapşırıq Siyahısı Nümunəsi
Figure 104. Pull Request siyahısında tapşırıq siyahısı xülasəsi

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.

Hasarlanmış kod təqdim edildi
Figure 105. Hasarlanmış kod nümunəsi göstərildi

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.

Sitat gətirmək
Figure 106. Sitat gətirməyə nümunə

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.

Emoji autocompleter
Figure 107. Əməliyyatda emoji autocompleter

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.

Emoji
Figure 108. Heavy emoji commenting

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 drag və drop etmək
Figure 109. Şəkilləri yükləmək və avtomatik yerləşdirmək üçün drag və drop edin

Şə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)
  1. Əgər başqa branch-dasınızsa, master-ə qayıdın.

  2. https://github.com/progit/progit2.git-dən dəyişiklikləri fetch edin və onları master-ə birləşdirin.

  3. master branch-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)
  1. Mənbə deposunu əlavə edin və ona bir ad verin. Budur, onu progit adlandırmağı seçdim..

  2. progit remote-undan fetch etmək üçün master branch-nızı qurun.

  3. Defolt deponu origin olaraq təyin edin.

Bunu etdikdən sonra iş axını daha asan olur:

$ git checkout master (1)
$ git pull (2)
$ git push (3)
  1. Əgər başqa branch-dasınızsa, master-ə qayıdın.

  2. progit-dən dəyişiklikləri fetch edin və dəyişiklikləri master-ə birləşdirin.

  3. master branch-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.

scroll-to-top