-
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.3 GitHub - Bir Layihənin Saxlanılması
Bir Layihənin Saxlanılması
İndi bir layihəyə töhfə verməkdə daha rahat olduğumuz üçün digər tərəfə baxaq: öz layihənizi yaratmaq, saxlamaq və idarə etmək.
Yeni bir Depo Yaratmaq
Layihə kodumuzu bölüşmək üçün yeni bir depo yaradaq.
Vasitə panelinin sağ tərəfindəki “New repository” düyməsinə və ya “Yeni Depo” açılışı-da göründüyü kimi istifadəçi adınızın yanındakı yuxarı alətlər panelindəki {plus}
düyməsindən basaraq başlaya bilərsiniz.
Bu sizi “yeni depo” formasına aparır:
Burada həqiqətən etməli olduğunuz bir şey bir layihə adını təqdim etməkdir; qalan sahələr tamamilə istəyə bağlıdır.
Hələlik, sadəcə “Create Repository” düyməsini vurun və bum - GitHub-da <user>/<project_name>
adlı yeni bir depo var.
Hələ orada kodunuz olmadığından, GitHub sizə yeni Git deposunuyaratmaq və ya mövcud Git layihəsini necə bağlamaq barədə təlimatları göstərəcəkdir. Biz burada işləməyəcəyik; yeniləməyə ehtiyacınız varsa, Git’in Əsasları-ə baxın.
İndi layihəniz GitHub-a ev sahibliyi etdiyindən, layihənizi bölüşmək istədiyiniz şəxsə URL-i verə bilərsiniz.
GitHub’dakı hər bir layihəyə HTTPS üzərindən https://github.com/<user>/<project_name>
və SSH üzərindən git@github.com:<user>/<project_name>
kimi müraciət etmək mümkündür.
Git bu URL-lərin hər ikisindən də fetch və push edə bilər, lakin onlara qoşulan istifadəçinin etimadnaməsinə əsaslanaraq girişlə idarə olunur.
Note
|
HTTPS əsaslı bir URL-i public bir layihə üçün paylaşmağa çox vaxt üstünlük verilir, çünki klonlama üçün istifadəçinin GitHub hesabına sahib olmaq məcburiyyətində deyil. İstifadəçilərə SSH URL-i versəniz, layihənizə daxil olmaq üçün bir hesab və yüklənmiş SSH key-i olmalıdır. HTTPS də layihəni orada görmək üçün brauzerə yapışdıracaqları URL-lə eynidir. |
Əməkdaşlar Əlavə Etmək
Giriş icazəsi vermək istədiyiniz digər insanlarla işləyirsinizsə, onları “əməkdaş” olaraq əlavə etməlisiniz. Ben, Jeff və Louise hamısı GitHub-dakı hesablara daxil olsalar və depolarınıza push etmək imkanı vermək istəsəniz, onları layihənizə əlavə edə bilərsiniz. Bunu etmək onlara “push” girişi verəcəkdir ki, bu da həm layihə, həm də Git depolarına oxumaq və yazmaq imkanı əldə edir.
Sağ tərəfdən çubuğun altındakı `Parametrlər 'bağlantısını klik edin.
Sonra sol tərəfdəki menyudan “Collaborators” seçin. Sonra, qutuya sadəcə bir istifadəçi adı yazın və “Add collaborator.” düyməsini basın. İstədiyiniz hər kəsə giriş vermək istədiyiniz qədər bunu təkrar edə bilərsiniz. Girişi ləğv etmək lazımdırsa, sıralarının sağ tərəfindəki “X” düyməsini basın.
Pull Requests İdarə etmək
İndi içərisində bir kodu olan bir layihəniz və bəlkə də push etmə imkanı olan bir neçə əməkdaşınız var, özünüzü Pull Request-i aldığınız zaman nə edəcəyinizə baxaq.
Pull Request-ləri ya depolarınızın bir fork-undakı bir branch-dan və ya eyni depodakı başqa bir branch-dan gələ bilər. Yeganə fərq, fork içərisində olanlar çox vaxt sizin branch-a basa bilmədiyiniz və sizin tərəfinizə push edə bilməyəcəkləri şəxslər olmalıdır, halbuki daxili Pull Request-ləri ilə ümumiyyətlə hər iki tərəf branch-a daxil ola bilər.
Bu misallar üçün, “tonychacon” olduğunuzu və “fade” adlı yeni Arduino kod layihəsini yaratdığınız barədə düşünək.
E-poçt Bildirişləri
Kimsə gəlir və kodunuza dəyişiklik edir və Pull Request göndərir. Yeni Pull Request barədə sizi xəbərdar edən bir e-poçt almalısınız və bu Yeni Pull Request barədə e-poçt bildirişi kimi bir şey görünməlidir.
Bu e-poçtla əlaqəli bir neçə şey var. Kiçik bir diffstat verəcəkdir - Pull Request-da nə qədər dəyişdiyiniz sənədlərin siyahısı. GitHub üzərindəki Pull Request-ə bir link verir. Ayrıca, əmr sətrindən istifadə edə biləcəyiniz bir neçə URL verir.
git pull <url> patch-1
deyilən xətti görsəniz, bu, uzaq bir branch-a qoşulmanın sadə bir yoldur.
Biz bu işi tez bir zamanda Uzaq Branch’ları Yoxlamaq-də keçdik.
İstəyirsinizsə, bir mövzu branch-ı yarada və həmin branch-a keçə bilərsiniz və sonra Pull Request dəyişikliklərində birləşmək üçün bu əmri işlədə bilərsiniz.
Digər maraqlı URL-lər .diff
və .patch
URL-ləridir, ehtimal ki, Pull Request-nin vahid diff və patch versiyalarını təmin edir.
Texniki olaraq Pull Request işini bu kimi bir şeylə birləşdirə bilərsiniz:
$ curl https://github.com/tonychacon/fade/pull/1.patch | git am
Pull Request üzrə Əməkdaşlıq
GitHub Axını-da bəhs etdiyimiz kimi Pull Request-ni açan şəxslə söhbət edə bilərsiniz. Hər yerdə GitHub Flavored Markdown istifadə edərək kodun müəyyən sətirlərini şərh edə bilərsiniz, bütün commit-ləri şərh edə bilərsiniz və ya Pull Request-in özünə şərh verə bilərsiniz.
Pull Request-nə başqaları hər dəfə rəy verdikdə fəaliyyətin baş verdiyini bildiyiniz üçün e-poçt bildirişləri almağa davam edəcəksiniz. Onların hər birində fəaliyyətin baş verdiyi yerdən Pull Request-ə bir keçid olacaq və siz də Pull Request mövzusuna şərh vermək üçün e-poçta birbaşa cavab verə bilərsiniz.
Kod istədiyiniz yerdə olanda və onu birləşdirmək istədikdə daha əvvəl gördüyünüz git pull <url> <branch>
əmri ilə və ya kodu əlavə edərək local olaraq və ya fork ilə uzaqdan fetch edə, birləşdirə bilərsiniz.
Birləşmə mənasızdırsa, GitHub saytındakı “Merge” düyməsini vura bilərsiniz. Bu sürətli bir irəli daxil olma ehtimalı olsa belə, birləşmə əməliyyatı yaradaraq, “sürətli olmayan irəli” birləşməsini həyata keçirəcəkdir. Bu o deməkdir ki, nə olursa olsun, birləşmə düyməsini vurduğunda, birləşmə əməliyyatı yaradılır. Birləşdirmək düyməsini və Pull Request-in manual birləşməsi üçün təlimatları da gördüyünüz kimi, işarə bağlantısını vurursanız, GitHub bu məlumatların hamısını verir.
Birləşdirmək istəmədiyinizə qərar verdiyiniz təqdirdə yalnız Pull Request-i bağlaya bilərsiniz və bu onu açan şəxsə bildiriləcəkdir.
Pull Request Referləri
Pull Request-lərin bir çoxu ilə məşğul olursunuzsa və bir qrup uzaqdan əlavə etmək və ya hər səfərində bir dəfə pull etmək istəmirsinizsə, GitHub-ın etməynizə sizə imkan verəcək səliqəli bir hiylə var. Bu bir az inkişaf etmiş bir hiylədir və bunun təfərrüatlarını bir az daha Refspec-də araşdıracağıq, bu olduqca faydalı ola bilər.
GitHub, əslində serverdəki pseudo-branch-lar kimi bir depo üçün Pull Request branch-larını reklam edir. Varsayılan olaraq, onları klonladığınız zaman almırsınız, ancaq gizli bir şəkildə var və onlara olduqca asanlıqla daxil ola bilərsiniz.
Bunu nümayiş etdirmək üçün ls-remote
adlı aşağı səviyyəli bir əmrdən (daha çoxPlumbing və Porcelain-də oxuyacağımız bir “plumbing” əmri olaraq xatırlanır.) istifadə edəcəyik.
Bu əmr ümumiyyətlə gündəlik Git əməliyyatlarında istifadə edilmir, lakin serverdə hansı istinadların mövcud olduğunu bizə göstərmək faydalıdır.
Bu əmri əvvəllər istifadə etdiyimiz “yanıb-sönmə” deposuna qarşı işləsək, depodakı bütün branch-ların və etiketlərin və digər istinadların siyahısını alacağıq.
$ git ls-remote https://github.com/schacon/blink
10d539600d86723087810ec636870a504f4fee4d HEAD
10d539600d86723087810ec636870a504f4fee4d refs/heads/master
6a83107c62950be9453aac297bb0193fd743cd6e refs/pull/1/head
afe83c2d1a70674c9505cc1d8b7d380d5e076ed3 refs/pull/1/merge
3c8d735ee16296c242be7a9742ebfbc2665adec1 refs/pull/2/head
15c9f4f80973a2758462ab2066b6ad9fe8dcf03d refs/pull/2/merge
a5a7751a33b7e86c5e9bb07b26001bb17d775d1a refs/pull/4/head
31a45fc257e8433c8d8804e3e848cf61c9d3166c refs/pull/4/merge
Əlbəttə ki, depo içərisindəsinizsə və git ls-remote origin
və ya yoxlamaq istədiyiniz hər hansı bir uzaqdan çalışırsınızsa, bu sizə bənzər bir şey göstərəcəkdir.
Depo GitHub-dadırsa və açılan hər hansı bir Pull Request-ləriniz varsa, refs/pull/
ilə prefiks edilmiş bu istinadları alacaqsınız.
Bunlar əsasən branch-lardır, amma refs/heads/
altında olmadığından onları klonlaşdırdıqda və ya serverdən götürəndə normal qəbul etmirsiniz - fetching prosesi onları normal qəbul etmir.
Pull Request-ə iki müraciət var - /head
nöqtəsində sonu Pull Request branch-dakı sonuncu commit-lə eyni.
Beləliklə, kimsə depoda Pull Request açsa və onların branch-ı bug-fix
adlanırsa və a5a775
əməliyyatını göstərirsə, onda bizim depoda bug-fix
branch-ı olmayacaq (çünki bu onların fork-larıdı), amma biz a5a775
işarəsini verən pull/<pr#>/head
olacaqdır.
Bu o deməkdir ki, uzaqdan bir qrup əlavə etmədən hər Pull Request branch-ını bir dəfəyə asanlıqla pull down edə bilərik.
İndi referansı birbaşa fetching edə bilərsiniz.
$ git fetch origin refs/pull/958/head
From https://github.com/libgit2/libgit2
* branch refs/pull/958/head -> FETCH_HEAD
Bu, Git-ə ‘` origin
remote-a qoşulun və refs/pull/958/head
adlı ref-i yükləyin.’'
Git xoşbəxt şəkildə itaət edir və bu ref düzəltmək üçün lazım olan hər şeyi yükləyir və .git/FETCH_HEAD
altından istədiyiniz commit-ə göstərici qoyur.
Bunu test etmək istədiyiniz bir branch-a git merge FETCH_HEAD
ilə təqib edə bilərsiniz, lakin bu birləşmə mesajı bir az qəribə görünür.
Ayrıca, çox pull request-ləri nəzərdən keçirirsinizsə, bu yorucu olur.
Pull request-lərin hamısını fetch etməyin və uzaqdan əlaqə qurduğunuz zaman onları yeniləməyin bir yolu da var.
Sevdiyiniz redaktorda`.git/config` açın və uzaqdan origin
-i axtarın.
Bu belə görünməlidir:
[remote "origin"]
url = https://github.com/libgit2/libgit2
fetch = +refs/heads/*:refs/remotes/origin/*
fetch =
ilə başlayan xətt “refspec.”-dir.
Bu uzaqdakə adları local .git
qovluğunuzdakı adlarla çəkilməsinin bir yoludur.
Bu, xüsusilə Git-ə "uzaqdan idarə olunanlar refs/heads
altındakı şeylər local depolarımda refs/remotes/origin
altında getməlidir." deyir.
Bu hissəni başqa bir refspec əlavə etmək üçün dəyişdirə bilərsiniz:
[remote "origin"]
url = https://github.com/libgit2/libgit2.git
fetch = +refs/heads/*:refs/remotes/origin/*
fetch = +refs/pull/*/head:refs/remotes/origin/pr/*
Bu son sətir Git’ə ‘` refs/pull/123/head
kimi görünən bütün istinadlar,refs/remotes/origin/pr/123
kimi local olaraq saxlanılmalıdır.’'
İndi həmin faylı yadda saxlasanız, git fetch
edin:
$ git fetch
# …
* [new ref] refs/pull/1/head -> origin/pr/1
* [new ref] refs/pull/2/head -> origin/pr/2
* [new ref] refs/pull/4/head -> origin/pr/4
# …
İndi uzaqdan pull request-lərin hamısı local olaraq, branch-ları izləyən branch-lar kimi təmsil olunur; yalnız oxuyursunuz və fetch etdiyiniz zaman yeniləyirlər. Bu, local bir pull request-də kodu sınamağı asanlaşdırır:
$ git checkout pr/2
Checking out files: 100% (3769/3769), done.
Branch pr/2 set up to track remote branch pr/2 from origin.
Switched to a new branch 'pr/2'
Aranızdakı qartal gözlü, refspecin uzaq hissəsinin sonundakı head
hissəsini qeyd edəcək.
GitHub tərəfində refs/pull/#/merge
ref də var, saytdakı “merge” düyməsini basdığınız zaman nəticəni təmin edəcəkdir.
Bu, düyməni vurmadan əvvəl birləşməni sınamağa imkan verə bilər.
Pull Request-lər üzərindəki Pull Request-lər
Yalnız əsas və ya master
branch-nı hədəf alan Pull Request-ləri deyil, həm də şəbəkədəki istənilən branch-ı hədəf alan Pull Request aça bilərsiniz.
Əslində, başqa bir Pull Request-i də hədəfə ala bilərsiniz.
Əgər düzgün istiqamətdə irəlilədiyini görsəniz və ona bağlı bir dəyişiklik üçün bir fikriniz varsa və ya yaxşı bir fikir olduğuna əmin deyilsinizsə və ya sadəcə hədəf branch-ına push etmək imkanı yoxdursa, birbaşa Pull Request aça bilərsiniz.
Pull Request açdığınız zaman, səhifənin yuxarısında hansı branch-ı pull etmək istədiyinizi və haradan pull etmək istəyinizi göstərən bir qutu var. Həmin qutunun sağındakı “Edit” düyməsini vurursanız, nəinki branch-ları, həm də fork-ları da dəyişdirə bilərsiniz.
Burada yeni branch-ınızı başqa bir Pull Request-ə və ya layihənin başqa bir fork-una birləşdirmək üçün asanlıqla göstərə bilərsiniz.
Mention-lar və Bildirişlər
GitHub ayrıca suallarınız olduqda və ya müəyyən bir şəxs və ya komandanın rəyinə ehtiyac duyduğunuzda yararlana biləcək olduqca gözəl bir bildiriş sisteminə malikdir.
Hər hansı bir şərhdə bir "@" simvolu yazmağa başlaya bilərsiniz və layihə ilə əməkdaşlıq edən və ya töhfə verən insanların adları və istifadəçi adları ilə avtomatik tamamlanmağa başlayacaq.
Ayrıca, bu açılan siyahıda olmayan bir istifadəçini də qeyd edə bilərsiniz, lakin əksər hallarda avtoköçürmə bunu daha sürətli edə bilər.
Bir istifadəçi qeydi ilə bir şərh göndərdikdən sonra bu istifadəçiyə bildiriş veriləcəkdir. Bu o deməkdir ki, bu, insanları sorğu-sual etməkdənsə söhbətə cəlb etməyin həqiqətən effektiv yolu ola bilər. Çox vaxt GitHub’un Pull Requests-də insanlar bir qrupu və ya şirkətindəki bir insanı bir Issue və ya Pull Request-i nəzərdən keçirmək üçün pull edəcəklər.
Kimsə Pull Request və ya Issue barədə məlumat verərsə, ona “subscribed” olacaq və hər hansı bir fəaliyyət baş verdikdə bildiriş almağa davam edəcəkdir. Bir şeyi açmısınızsa, depoya baxırsınızsa və ya bir şeyə şərh verərsinizsə, ona abunə olacaqsınız. Artıq bildiriş almaq istəmirsinizsə, səhifədə yeniləmələri almağı dayandırmaq üçün tıklaya biləcəyiniz “Unsubscribe” düyməsi var.
Bildrişlər Səhifəsi
GitHub ilə əlaqədar burada “bildirişlər” dedikdə GitHub-da hadisələr baş verdikdə sizinlə əlaqə qurmağa çalışdıqlarını və onları konfiqurasiya edə biləcəyiniz bir neçə fərqli yol olduğunu söyləyirik. Parametrlər səhifəsindəki “Notification center” bölməsinə keçsəniz, əlinizdə olan bəzi variantları görə bilərsiniz.
İki seçim, “E-poçt” və “Web” üzərindən bildirişlər almaqdır və işlərdə fəal iştirak etdiyiniz zaman və seyr etdiyiniz depolardakı fəaliyyət üçün ya birini ya da ikisini də seçə bilərsiniz.
Veb bildirişləri
Veb bildirişləri yalnız GitHub-da mövcuddur və onları yalnız GitHub-da yoxlaya bilərsiniz. Tərcihlərinizdə bu seçim seçilibsə və sizin üçün bildiriş tətiklənirsə, Bildiriş mərkəzi da göründüyü kimi ekranınızın yuxarı hissəsindəki bildirişlər nişanınızın üzərində kiçik bir mavi nöqtə görəcəksiniz.
Bunun üzərinə klikləsəniz, layihə üzrə qruplaşdırılmış, sizə bildirilmiş bütün maddələrin siyahısını görəcəksiniz. Sol tərəfdəki çubuğundakı adını tıklayaraq müəyyən bir layihənin bildirişlərinə süzgəcdən keçirə bilərsiniz.
Hər hansı bir bildirişin yanındakı işaret nişanını vuraraq bildirişi qəbul edə bilərsiniz və ya qrupun üst hissəsindəki işarət düyməsini vuraraq bildirişlərin hamısını-ı təsdiq edə bilərsiniz. Bu element haqqında əlavə bildiriş almamaq üçün vura biləcəyiniz hər bir işaretin yanında səssiz bir düymə də var.
Bu vasitələrin hamısı çox sayda bildirişlə işləmək üçün çox faydalıdır. GitHub güc istifadəçilərinin çoxu e-poçt bildirişlərini tamamilə söndürəcək və bütün bildirişlərini bu ekran vasitəsilə idarə edəcəkdir.
E-poçt Bildirişləri
E-poçt bildirişləri GitHub vasitəsilə bildirişləri idarə edə biləcəyiniz başqa bir yoldur. Əgər bu varsa, hər bildiriş üçün e-poçt alacaqsınız. Bunun nümunələrini E-poçt bildirişləri olaraq göndərilən şərhlər və Yeni Pull Request barədə e-poçt bildirişi-də gördük. E-poçtlar da düzgün bir şəkildə yığılar, bu da bir threading e-poçt müştərisi istifadə edirsinizsə yaxşı olur.
Xüsusi filtrlər və qaydaları qurmaq üçün həqiqətən faydalı ola biləcək GitHub’un sizə göndərdiyi e-poçtların başlıqlarına kifayət qədər miqdarda metadataya malikdir.
Məsələn, Tony-ə göndərilən faktiki e-poçt başlıqlarına Yeni Pull Request barədə e-poçt bildirişi-da göstərilən e-poçtda baxsaq, göndərilən məlumatlar arasında aşağıdakıları görəcəyik:
To: tonychacon/fade <fade@noreply.github.com>
Message-ID: <tonychacon/fade/pull/1@github.com>
Subject: [fade] Wait longer to see the dimming effect better (#1)
X-GitHub-Recipient: tonychacon
List-ID: tonychacon/fade <fade.tonychacon.github.com>
List-Archive: https://github.com/tonychacon/fade
List-Post: <mailto:reply+i-4XXX@reply.github.com>
List-Unsubscribe: <mailto:unsub+i-XXX@reply.github.com>,...
X-GitHub-Recipient-Address: tchacon@example.com
Burada bir neçə maraqlı şey var.
Bu layihəyə e-poçtları vurğulamaq və ya yenidən yönəltmək istəyirsinizsə və ya hətta Pull Request etmək istəsəniz, Message-ID
-də olan məlumatlar sizə <user>/<project>/<type>/<id>
-dəki bütün məlumatları verir.
Bu, məsələn, bir problem olsaydı, məsələn, <type>
sahəsi “pull” əvəzinə “issues” olardı.
List-Post
və List-Unsubscribe
sahələri o deməkdir ki, bunları başa düşən bir poçt müştəriniz varsa,asanlıqla siyahıya bir mesaj göndərə və ya mövzudan “Unsubscribe” deməkdir.
Bu, bildirişin veb versiyasındakı “mute” düyməsini basmaqla və ya Issue və ya Pull Request səhifəsindəki “Unsubscribe” düyməsini basmaqla eyni olacaqdır.
Həm e-poçt, həm də veb bildirişləriniz aktivdirsə və bildirişin e-poçt versiyasını oxusanız, poçt müştərinizdə icazə verilən şəkillər varsa veb versiyası da oxunmuş kimi qeyd olunur.
Xüsusi Fayllar
GitHub depolarınızda olduqda fərq edəcəyi bir neçə xüsusi fayl var.
README
Birincisi, GitHub’ın nəsr kimi tanıdığı hər hansı bir formatda ola bilən README 'sənədidir.
Məsələn, `README
, README.md
, README.asciidoc
və s. ola bilər.
GitHub mənbəyinizdə README faylını görürsə, onu layihənin açılış səhifəsində göstərəcəkdir.
Bir çox komanda depo və ya layihə üçün yeni ola biləcək birisi üçün bütün müvafiq layihə məlumatlarını saxlamaq üçün bu faylı istifadə edir. Bura ümumiyyətlə aşağıdakılar daxildir:
-
Layihə nədir
-
Konfiqurasiya və quraşdırılma qaydaları
-
Onu istifadə və ya işlətmək üçün bir nümunə
-
Layihə çərçivəsində təklif olunan lisenziya
-
Buna necə töhfə vermək olar
GitHub bu faylı göstərəcəyi üçün əlavə anlaşma rahatlığı üçün şəkillər və ya bağlantılar yerləşdirə bilərsiniz.
CONTRIBUTING
GitHub’un tanıdığı digər xüsusi fayl CONTRIBUTING
faylıdır.
Hər hansı bir fayl uzantısı ilə CONTRIBUTING
adlı bir faylınız varsa, hər kəs Pull Request açmağa başlayanda GitHub CONTRIBUTING file olduqda Pull Request açmaq
Burada fikir budur ki, istədiyiniz və ya istəmədiyiniz konkret şeyləri proyektinizə göndərilən Pull Request-də göstərə bilərsiniz. Bu yolla insanlar Pull Request-i açmadan əvvəl təlimatları həqiqətən oxuya bilərlər.
Layihə İdarəçiliyi
Ümumiyyətlə bir layihə ilə edə biləcəyiniz bir çox inzibati iş yoxdur, ancaq maraq doğuran bir neçə maddə var.
Default Branch-ı Dəyişdirmək
Standart branch kimi “master” dən başqa bir branch istifadə edirsinizsə, insanların Pull Request-ləri açmasını və ya vrasayılan olaraq görməsini istəyirsinizsə, bunu “Options” bölməsində deponun parametrlər səhifəsində dəyişə bilərsiniz.
Açılan menudan standart branch-ı dəyişdirin və o zamandan etibarən bütün əsas əməliyyatlar üçün, o cümlədən kiminsə deponu klonlaşdırdıqda bu barnch-ın yoxlanılması da daxil olmaqla standart olacaqdır.
Bir Layihəni Köçürmək
Bir layihəni GitHub-dakı başqa bir istifadəçiyə və ya bir təşkilata köçürmək istəyirsinizsə, bunu etməyə imkan verən depo parametrləri səhifənizin eyni “Options” bölməsi altındakı “Transfer ownership” seçimi var.
Bir layihədən imtina edirsinizsə və kimsə onu öz üzərinə götürmək istəyirsə və ya layihəniz böyüyürsə, onu bir təşkilata keçirməyiniz daha faydalıdır.
Bu, təkcə bütün izləyiciləri və ulduzları ilə birlikdə deponu başqa yerə köçürmür, eyni zamanda URL-dən yeni yerə yönləndirmə qurur. Bu, yalnız veb sorğularını deyil, Git-dən klonları və alış-verişi yönləndirəcəkdir.