-
1. Başlangıç
- 1.1 Sürüm Denetimi
- 1.2 Git’in Kısa Tarihçesi
- 1.3 Git Nedir?
- 1.4 Komut Satırı
- 1.5 Git’i Yüklemek
- 1.6 Git’i İlk Defa Kurmak
- 1.7 Yardım Almak
- 1.8 Özet
-
2. Git Temelleri
-
3. Git Dalları
- 3.1 Dallar
- 3.2 Kısaca Dallandırma ve Birleştirme Temelleri
- 3.3 Dal Yönetimi
- 3.4 İş Akışı Dallandırması
- 3.5 Uzak Dallar
- 3.6 Yeniden Temelleme (rebase)
- 3.7 Özet
-
4. Bir Sunucuda Git Kurma
- 4.1 İletişim Kuralları (Protocols)
- 4.2 Bir Sunucuda Git Kurma
- 4.3 SSH Ortak Anahtarınızı Oluşturma
- 4.4 Sunucu Kurma
- 4.5 Git Cini (Daemon)
- 4.6 Akıllı HTTP
- 4.7 GitWeb
- 4.8 GitLab
- 4.9 Üçüncü Taraf Barındırma (Hosting) Seçenekleri
- 4.10 Özet
-
5. Dağıtık Git
- 5.1 Dağıtık İş Akışları
- 5.2 Projenin Gelişiminde Rol Almak
- 5.3 Bir Projeyi Yürütme
- 5.4 Özet
-
6. GitHub
- 6.1 Bir Projeye Katkıda Bulunmak
- 6.2 Proje Bakımı
- 6.3 Kurumsal Yönetim
- 6.4 GitHub’ı otomatikleştirme
- 6.5 Özet
-
7. Git Araçları
- 7.1 Düzeltme Seçimi
- 7.2 Etkileşimli İzlemleme (Staging)
- 7.3 Saklama ve Silme
- 7.4 Çalışmanızı İmzalama
- 7.5 Arama
- 7.6 Geçmişi Yeniden Yazma
- 7.7 Reset Komutunun Gizemleri
- 7.8 İleri Seviye Birleştirme
- 7.9 Rerere
- 7.10 Git’le Hata Ayıklama
- 7.11 Alt Modüller
- 7.12 Demetleme (Bundling)
- 7.13 Git Nesnesini Değiştirme
- 7.14 Kimlik Bilgisi Depolama
- 7.15 Özet
-
8. Git’i Özelleştirmek
- 8.1 Git Yapılandırması
- 8.2 Git Nitelikleri
- 8.3 Git Kancaları (Hooks)
- 8.4 Bir Örnek: Mecburi Git Politikası
- 8.5 Özet
-
9. Git ve Diğer Sistemler
- 9.1 İstemci Olarak Git
- 9.2 Git’e Geçiş
- 9.3 Özet
-
10. Dahili Git Ögeleri
- 10.1 Tesisat ve Döşeme (Plumbing ve Porcelain)
- 10.2 Git Nesneleri
- 10.3 Git Referansları
- 10.4 Packfiles
- 10.5 Refspec
- 10.6 Transfer Protokolleri
- 10.7 Bakım ve Veri Kurtarma
- 10.8 Ortam Değişkenleri
- 10.9 Özet
-
A1. Ek bölüm A: Diğer Ortamlarda Git
- A1.1 Görsel Arayüzler
- A1.2 Visual Studio ile Git
- A1.3 Visual Studio Code ile Git
- A1.4 Eclipse ile Git
- A1.5 Sublime Text ile Git
- A1.6 Bash ile Git
- A1.7 Zsh ile Git
- A1.8 PowerShell ile Git
- A1.9 Özet
-
A2. Ek bölüm B: Git’i Uygulamalarınıza Gömmek
- A2.1 Git Komut Satırı
- A2.2 Libgit2
- A2.3 JGit
- A2.4 go-git
- A2.5 Dulwich
-
A3. Ek bölüm C: Git Komutları
- A3.1 Kurulum ve Yapılandırma Komutları
- A3.2 Proje Oluşturma Komutları
- A3.3 Kısaca Poz (Snapshot) Alma
- A3.4 Dallandırma ve Birleştirme Komutları
- A3.5 Projeleri Paylaşma ve Güncelleme Komutları
- A3.6 İnceleme ve Karşılaştırma Komutları
- A3.7 Hata Ayıklama (Debugging) Komutları
- A3.8 Yamalama (Patching)
- A3.9 E-Posta Komutları
- A3.10 Harici Sistemler
- A3.11 Yönetim
- A3.12 Tesisat (Plumbing) Komutları
6.2 GitHub - Proje Bakımı
Proje Bakımı
Artık bir projeye katkıda bulunmaya alıştığımıza göre, şimdi işin diğer tarafına bakalım: kendi projenizi oluşturma, bakma ve yönetme.
Yeni Bir Repo Oluşturma
Projemizin kodunu paylaşmak için yeni bir repo oluşturalım.
Bunun için, panonun sağ tarafında bulunan ``New repository`` (Yeni Repo) düğmesine veya ``New repository`` (yeni repo) açılır-listesi.'da göründüğü gibi kullanıcı adınızın yanındaki üst araç çubuğundaki {plus}
düğmesine tıklayarak başlayın.
-
``Your repositories`` (repolarınız) bölümü. image::images/newrepo.png[``Your repositories`` (repolarınız) bölümü.]
Bu sizi “new repository” (yeni repo) formuna ulaştırır:
Burada yapmanız gereken tek şey bir proje adı yazmak; diğer alanlar tamamen isteğe bağlıdır.
Şimdilik sadece ``Create Repository`` (Repo Oluştur) düğmesine tıklayın, ve anında GitHub’da <kullanıcı_adı>/<proje_adı>
adında yeni bir repoya sahipsiniz.
Henüz kodunuz olmadığı için, GitHub size tamamen yeni bir Git reposu nasıl oluşturacağınızı veya mevcut bir Git projesini nasıl bağlayacağınızı gösterecektir. Burada bunun üzerinde daha fazla durmayacağımız için, daha fazla bilgiye ihtiyacınız varsa, Git Temelleri bölümüne göz atabilirsiniz.
Projeniz GitHub’da yayınlandığı için, projenizi paylaşmak istediğiniz herkese URL’yi verebilirsiniz.
GitHub’daki her proje, HTTPS üzerinden https://github.com/<kullanıcı-adı>/<proje-adı>
olarak ve SSH üzerinden git@github.com:<kullanıcı-adı>/<proje-adı>
olarak erişilebilir.
Git, bu URL’lerden her ikisine de erişebilir ve verilen kullanıcı kimlik bilgilerine göre erişim kontrolü sağlanır.
Not
|
Kullanıcıların projeyi kopyalamak için bir GitHub hesabına ihtiyaç duymamalarından dolayı, herkese açık bir projeyi paylaşmak için HTTPS tabanlı URL’yi tercih etmek genellikle daha iyidir. Eğer kullanıcılara SSH URL’si verirseniz, projenize erişmek için bir hesap ve yüklenmiş bir SSH anahtarına ihtiyaç duyacaklardır. HTTPS URL’si tam olarak, kullanıcıların projeyi bir tarayıcıda görüntülemek için yapıştıracakları aynı URL’dir. |
Çalışma Arkadaşı (Ortak) Eklemek
Başkalarıyla birlikte çalışıyorsanız ve onlara katkı erişimi vermek istiyorsanız; onları "Çalışma Arkadaşı" olarak eklemeniz gerekir. Ben, Jeff ve Louise GitHub hesabı oluşturduysa ve onlara repo erişimi vermek istiyorsanız, onları projenize ekleyebilirsiniz. Bunu yapmak, onlara "itme" erişimi verecek; yani projeye ve Git reposuna, hem okuma hem de yazma erişimine sahip olacaklardır.
Sağ kenarın altındaki ``Settings`` (ayarlar) linkine tıklayın.
Sol taraftaki menüden ``Collaborators`` 'ı seçin. Ardından, kutuya eklemek istediğiniz kullanıcının adını yazın ve "Add collaborator" (çalışma arkadaşı ekle) düğmesine tıklayın. Bu işlemi dilediğiniz kadar yineleyerek, istediğiniz herkese erişim verebilirsiniz. Erişimi iptal etmeniz gerekiyorsa, sadece isimlerinin bulunduğu sırasının sağ tarafındaki "X"e tıklayın.
Birleştirme İsteklerini (PR: Pull Requests) Yönetmek
Şimdi kod içeren bir projeniz ve hatta birkaç çalışma arkadaşınızın da itme erişimi olduğu bir projeniz olduğuna göre, bir Birleştirme İsteği aldığınızda ne yapmanız gerektiğini görelim.
Birleştirme İstekleri ya repo çatalınızdaki bir dalda ya da aynı repodaki başka bir daldan gelebilir. Tek fark, çatallarda olanlar genellikle sizin dalınıza itme yapamaz ve siz de onlarınkine. Dahili Birleştirme İstekleri genellikle her iki tarafın da dala erişim sağlayabilmesi durumudur.
Bu örnekler için, varsayalım ki sizin adınız ``tonychacon`` ve ``fade`` adında yeni bir Arduino kodu projesi oluşturdunuz.
E-Posta Bildirimleri
Birisi kodunuza bir değişiklik yapar ve size bir Birleştirme İsteği (Pull Request) gönderir. Yeni Birleştirme İsteği hakkında sizi bilgilendiren bir e-posta almalısınız ve bu e-posta genellikle Yeni bir birleştirme isteğinin e-posta bildirimi. gibi bir şeydir.
Bu e-postada dikkat edilmesi gereken birkaç şey vardır: Küçük bir "diffstat" bulunur: Birleştirme İsteği’nde değişen dosyaların ve bu değişikliklerin miktarının bir listesi. GitHub’daki Birleştirme İsteği’ne bir bağlantı verir. Ayrıca, komut satırından kullanabileceğiniz birkaç URL sağlar.
git pull <url> patch-1
satırına dikkat edin; bu uzak bir dalı eklemeye gerek kalmadan, uzak bir dalı birleştirmenin basit bir yoludur.
Uzak Dallara Geçmek bölümünde bunun hakkında kısaca konuştuk.
İsterseniz bir konu dalı oluşturup, değişiklikleri birleştirmek için bu komutu çalıştırabilirsiniz.
Diğer ilginç URL’ler .diff
ve .patch
URL’leridir. Tahmin edebileceğiniz gibi, birleştirme isteğinin, birleştirilmiş diff ve yama sürümlerini sağlar.
Birleştirme isteği çalışmasını, teknik olarak şöyle birleştirebilirsiniz:
$ curl https://github.com/tonychacon/fade/pull/1.patch | git am
Birleştirme İsteği Yoluyla İşbirliği
GitHub Akışı bölümünden hatırlayacağınız üzere birleştirme isteği açan kişiyle artık bir konuşma başlatabilirsiniz. GitHub soslu Markdown’ı her yerde kullanarak isteğiniz kod satırlarına yorum yazabilir, katkının veya birleştirme isteğinin tamamına yorum apabilirsiniz.
Birileri birleştirme isteği üzerine yorum yaptıkça e-posta bildirimleri almaya devam edersiniz, böylece etkinliğin canlı olduğunu bilirsiniz. Her biri etkinliğin gerçekleştiği birleştirme isteğine giden bir bağlantıya sahip olacaktır ve ayrıca siz doğrudan e-postaya yanıt vererek birleştirme isteği konu başlığına yorum yapabileceksiniz.
Kodu beğendiğiniz ve birleştirmek istediğinizde, artık kodu yerelinize çekip birleştirebilirsiniz.
Bunun için ya önceden gördüğümüz git pull <url> <branch>
sözdizimini kullanabilirsiniz ya da çatalı bir uzak sunucu olarak ekleyerek çekip birleştirebilirsiniz.
Eğer birleştirme basitse, GitHub sitesindeki ``Merge`` (Birleştir) düğmesine basarak da işlemi gerçekleştirebilirsiniz. Bir "ileri sarma" (fast-forward) birleştirmesi mümkün olsa bile "ileri sarma" olmayan bir birleştirme işlemi yapar ve bir birleştirme katkısı işler. Bu, her durumda birleştirme düğmesine her basıldığında, bir birleştirme katkısı işlendiği anlamına gelir. Birleştir dügmesi (merge) ve manuel birleştirme yönergesi. bağlantısına tıklarsanız, GitHub size tüm bu bilgileri verecektir.
Eğer birleştirmek istemediğinize karar verirseniz, doğrudan birleştirme isteğini kapatabilirsiniz. Bu durumda isteği açan kişiye bir bildirim gönderilir.
Birleştirme İsteği Referansları
Eğer çok fazla Birleştirme İsteği ile uğraşıyorsanız ama bir sürü uzak repo eklemek veya her seferinde bir defalık çekmeler yapmak istemiyorsanız; GitHub’ın size izin verdiği güzel bir hile var. Bu biraz iler seviye bir hile (ayrıntılarını Refspec bölümünde göreceğiz) ama çok kullanışlı olabilir.
Aslında GitHub, bir repodaki birleştirme isteği dallarını sunucuda bir nevi sahte-dal olarak tanıtır. Repoyu kopyaladığınızda bunlara da sahip olamazsınız, ancak bir şekilde orada gizlenmişlerdir ve onlara kolayca erişebilirsiniz.
Bunu göstermek için ls-remote
adlı düşük seviyeli bir komut kullanacağız. (Tesisat ve Döşeme (Plumbing ve Porcelain) bölümünde ls-remote
hakkında daha fazla bilgi bulacaksınız).
Bu komut genellikle günlük Git işlemlerinde pek ullanılmaz ancak sunucuda hangi referansların mevcut olduğunu göstermek için yararlıdır.
Daha önce kullandığımız "blink" reposu üzerinde bu komutu çalıştırırsak, repoda bulunan tüm dallar, etiketler ve diğer referansların bir listesini alırız.
$ 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
Tabii ki, kendi reponuzdaysanız ve git ls-remote origin
veya kontrol etmek istediğiniz herhangi bir uzak adı verirseniz, size bunun gibi bir şey gösterecektir.
Eğer repo GitHub’ta ise ve açılmış herhangi bir Birleştirme İsteğiniz varsa, refs/pull/
ile başlayan bu referansları elde edersiniz.
Temel olarak bunlar dallardır, ancak refs/heads/
altında olmadıkları için, sunucudan kopyalama veya çekme yoluyla onları normal bir şeklide almazsınız — çekme komutu (fetch) onları doğal olarak yoksayar.
Her birleştirme isteği için iki referans bulunur: /head
ile biten referans, Birleştirme İsteği dalındaki son katkının tam olarak aynısına işaret eder.
Yani eğer biri bizim repomuzda bir birleştirme isteği açarsa ve onların bug-fix
olarak adlandırılmış dalı a5a775
katkısına işaret ediyorsa, o zaman bizim repomuzda bir bug-fix
dalımız olmayacaktır (çünkü bu dal o kişinin kendi reposundadır), ancak pull/<pr#>/head
olarak a5a775
'e işaret eden bir dalımız olacak.
Bu, bir sürü uzak depo eklemek zorunda kalmadan kolayca her birleştirme isteği dalını bir seferde indirebileceğimiz anlamına gelir.
Şimdi, doğrudan referansı almak için bir şeyler yapabilirsiniz.
$ git fetch origin refs/pull/958/head
From https://github.com/libgit2/libgit2
* branch refs/pull/958/head -> FETCH_HEAD
Bu, Git’e origin
uzak sunucusuna bağlanıp, refs/pull/958/head
adındaki referansı indirmesini söyler.
Git mutlu bir şekilde size itaat eder: istediğiniz referansı oluşturmak için gereken her şeyi indirir ve .git/FETCH_HEAD
altına bir işaretçi ekler.
Bunu, test etmek istediğiniz dallardan birinde git merge FETCH_HEAD
ile takip edebilirsiniz, ancak birleştirme işlemi komutunun ileti metni biraz garip görünebilir.
Ayrıca, çok sayıda birleştirme isteğini inceliyorsanız, bu işlem sıkıcı hale gelir.
Ayrıca, tüm birleştirme isteklerini almanın ve her bağlandığınızda bunları güncel tutmanın bir yolu daha var.
Favori metin düzenleyicinizde .git/config
dosyasını açın ve origin
uzak sunucusunu arayın.
Şöyle görünmelidir:
[remote "origin"]
url = https://github.com/libgit2/libgit2
fetch = +refs/heads/*:refs/remotes/origin/*
fetch =
ile başlayan satır, "refspec" olarak adlandırılan bir dizedir.
Bu, uzak sunucudaki adları yerel .git
dizininizdeki adlarla eşleştirmek için kullanılan bir yoldur.
Buradaki Git’e, "uzak sunucuda refs/heads
altındaki şeylerin, yerel repomda refs/remotes/origin
altına gitmesi gerektiğini" söyler.
Başka bir refspec eklemek için bu bölümü değiştirebilirsiniz:
[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 satır Git’e şunu söyler: "Tüm refs/pull/123/head
gibi görünen referanslar yerel olarak refs/remotes/origin/pr/123
şeklinde saklanmalıdır".
Şimdi, bu dosyayı kaydettikten ve bir git fetch
yaptıktan sonra:
$ 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
# …
Şimdi tüm uzak birleştirme istekleri, yerelde izleyici dallar gibi davranan referanslarla temsil ediliyorlar; bunlar salt okunurdur ve bir çekme yapılğında güncelleniyor. Bu, bir birleştirme isteğinden gelen kodu yerel olarak denemeyi son derece kolaylaştı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'
Detaylara bakmayı sevenler, refspec’in uzak kısmında sonunda head
olduğunu fark ederlerdi.
GitHub tarafında bir de refs/pull/#/merge
referansı bulunur, bu da sitenin merge
(birleştir) düğmesine tıkladığınızda ortaya çıkacak olan işlemi temsil eder.
Bu, düğmeye bile basmadan birleştirmeyi test edebilmenizi sağlar.
Birleştirme İstekleri Üzerinde Birleştirme İstekleri
Yalnızca ana veya "master" dalı hedef alan birleştirme isteklerini açmakla kalmaz, aynı zamanda ağdaki herhangi bir dalı hedef alan bir birleştirme isteğini de açabilirsiniz. Aslında başka bir birleştirme isteğini bile hedefleyebilirsiniz.
Eğer doğru yönde ilerleyen bir istek görürseniz ve buna bağlı bir değişiklik fikriniz varsa veya bunun iyi bir fikir olduğundan henüz emin değilseniz, ya da sadece hedef dala itme erişiminiz yoksa; doğrudan bir istek açabilirsiniz.
Bir birleştirme isteği açmak istediğinizde, sayfanın üst kısmında hangi dala çekmek istediğinizi ve hangisinden çekmek istediğinizi belirten bir kutu bulunur. O kutunun sağındaki ``Edit`` (Düzenle) düğmesine bastığınızda; sadece dalları değil, aynı zamanda belli bir çatalı da seçebileceğinizi göreceksiniz.
Burada, yeni dalınızı hangi birleştirme isteğine veya projenin hangi çatalına birleştireceğinizi kolaylıkla belirtebilirsiniz.
Bildirim ve İsim Etiketlemek
GitHub’un ayrıca oldukça kullanışlı bir bildirim sistemi de bulunmaktadır; ki bu, belirli birey veya gruplara sorularınız olduğunda veya geribildirime ihtiyaç duyduğunuzda, çok işinize yarayabilir.
Herhangi bir yorumda @
karakterini yazmaya başlarsanız, projedeki ortak ve katkıda bulunan kişilerin isim ve kullanıcı adları otomatik olarak tamamlanmaya başlar.
Ayrıca, o seçenek listesinde olmayan bir kullanıcıyı da etiketleyebilirsiniz, ancak genellikle otomatik tamamlama daha hızlıdır.
Bir kullanıcının etiketlediğiniz bir yorumu gönderdiğinizde, o kullanıcı bir bildirim alır. Bu, insanları konuşmalara dahil etmek için oldukça etkili bir yoldur ve anket yapmaktan kullanışlıdır. GitHub’daki birleştirme isteklerinde, insanlar sıklıkla takım veya şirket arkadaşlarını, bir konu veya birleştirme isteğini gözden geçirmek amacıyla, bu sohbet alanına çekerler.
Eğer birinin adı, bir Konu (issue) veya birleştirme isteğinde geçerse, o kişi o konuya "abone" olmuş olur ve herhangi bir işlem gerçekleştiğinde bildirim almaya devam eder. Ayrıca, bir şeyi (konu, dal, vs) siz açtıysanız, bir repoyu izliyorsanız veya bir konuya yorum yaptıysanız, yine ona abone olursunuz. Eğer artık bildirim almak istemiyorsanız, üzerinde güncellemeler almayı durdurmak için tıklayabileceğiniz bir ``Unsubscribe`` (Abonelikten Çık) düğmesi bulunmaktadır.
Bildirimler Sayfası
GitHub bağlamında "bildirimler" dediğimizde, kastettiğimiz şey: bir şey meydana geldiğinde, GitHub’un sizinle iletişime geçmeye çalıştığı belirli bir yöntemdir ve bunları yapılandırmanın birkaç farklı yolu vardır. Ayarlar sayfasından ``Notification center`` (Bildirim merkezi) sekmesine giderseniz, sahip olduğunuz seçeneklerden bazılarını görebilirsiniz.
Bildirim almak için; ``E-posta`` üzerinden ve ``Web`` üzerinden olmak üzere iki seçeneğiniz bulunmaktadır. Etkinliklere aktif olarak katıldığınızda ve izlediğiniz arşivlerdeki etkinlikler için bu ikisinden birini, hiçbirini veya her ikisini birden seçebilirsiniz.
Ağ Bildirimleri
Ağ bildirimleri yalnızca GitHub’ta mevcuttur ve bunları yalnızca GitHub’ta kontrol edebilirsiniz. Eğer tercihlerinizde bu seçeneği işaretlerseniz ve sizin için bir bildirim tetiklenirse; ekranınızın üst kısmında bildirim simgesinin üzerinde Bildirim merkezi. şekilde görüldüğü gibi, küçük mavi bir nokta göreceksiniz.
O noktaya tıklarsanız, bildirildiğiniz tüm öğelerin bir listesini, projeye göre gruplandırılmış olarak göreceksiniz. Sol kenar çubuğunda yazan proje ismine tıklayarak belirli bir projenin bildirimlerini filtreleyebilirsiniz. Ayrıca, herhangi bir bildirimin yanındaki onay işareti simgesine tıklayarak bildirimi kabul edebilirsiniz veya bir projedeki tüm bildirimleri onaylamak için grup üstündeki onay işaretine tıklayabilirsiniz. Her onay işaretinin yanında bir sessize alma düğmesi de bulunur; bu düğmeye tıklayarak ilgili öğeyle ilgili daha fazla bildirim almayı durdurabilirsiniz.
Tüm bu araçlar, büyük miktarda bildirimle başa çıkmak için çok kullanışlıdır. Birçok deneyimli GitHub kullanıcısı, e-posta bildirimlerini tamamen kapatır ve tüm bildirimlerini bu ekran aracılığıyla yönetir.
E-Posta Bildirimleri
E-posta bildirimleri, GitHub üzerinden bildirimleri yönetmenin diğer bir yoludur. Bunu açık şekilde ayarladıysanız, her bildirim için bir e-posta alırsınız. Bunun örneklerini E-posta bildirimi olarak gönderilen yorum ve Yeni bir birleştirme isteğinin e-posta bildirimi.'de görmüştük. E-postalar da düzgün bir şekilde konu başlığına göre gruplandırılır, eğer bir konu başlığına göre e-posta istemcisi kullanıyorsanız bu oldukça kullanışlıdır.
GitHub tarafından size gönderilen e-postaların başlıklarında gömülü bir miktar meta veri bulunur; bu da özel filtreler ve kurallar oluşturmak için gerçekten faydalı olabilir.
Örneğin, Yeni bir birleştirme isteğinin e-posta bildirimi.'de gösterilen e-postada Tony’ye gönderilen gerçek e-posta başlıklarına baktığımızda, gönderilen bilgiler arasında aşağıdakileri göreceğiz:
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 ilginç birkaç şey var.
Eğer bu belirli projeyi veya hatta bir birleştirme isteği ile ilgili e-postaları vurgulamak veya yeniden yönlendirmek istiyorsanız; Message-ID
içindeki veriler, size tüm bilgileri <kullanıcı>/<proje>/<tip>/<kimlik>
formatında verir.
Bu bir konu olsaydı; örneğin, <tip>
alanı "pull" (çek) yerine, "issues" (konular) olarak belirtilirdi.
List-Post
ve List-Unsubscribe
alanları size (bu alanları anlayabilen bir posta istemciniz varsa), kolayca listeye gönderi yapabilmenizi veya konudan "Aboneliğinizi" kaldırabilmenizi sağlar.
Bu, esasen bildirimin ağ sürümündeki ``mute`` (sessize al) ya da Konu (issues) veya birleştirme isteği (Pull Request) sayfasında "unsubscribe" (Abonelikten Çık) düğmesine tıklamakla aynı olacaktır.
Ayrıca, eğer hem e-posta hem de ağ bildirimleri etkinleştirilmişse, bildirinin e-posta sürümünü okursanız ve posta istemcinizde rde esimlere izin verilmişse; ağ sürümü de okunmuş olarak işaretlenir.
Özel Dosyalar
There are a couple of special files that GitHub will notice if they are present in your repository.
README (BENİOKU) Dosyası
Listenin başında README
dosyası bulunur ve GitHub’ın yazı olarak tanıdığı neredeyse herhangi bir formatta olabilir.
Örneğin, README
, README.md
, README.asciidoc
, vb. olabilir.
GitHub, kaynaklarınızda bir README dosyası görürse, bunu projenizin açılış sayfası görüntüsüne çevirir.
Birçok ekip, repoya veya projeye yeni katılanlar için ilgili tüm proje bilgilerini içermek üzere, bu dosyayı kullanır. Bu dosya genellikle şunları içerir:
-
Projenin amacı
-
Nasıl yapılandırılacağı ve kurulacağı
-
Nasıl kullanılacağı veya çalıştırılacağına dair bir örnek
-
Projenin sunulduğu lisans
-
Projeye nasıl katkıda bulunulacağı
GitHub bu dosyayı görüntüye çevireceği için, daha iyi anlaşılmasını sağlamak amacıyla içine görseller veya bağlantılar ekleyebilirsiniz.
CONTRIBUTING (KATILIM)
GitHub’ın tanıdığı diğer özel dosya CONTRIBUTING
dosyasıdır.
Herhangi bir dosya uzantısına sahip CONTRIBUTING
adında bir dosyanız varsa; biri birleştirme isteği açmaya başladığında, GitHub CONTRIBUTING dosyası varken birleştirme isteği açılması. dosyasını gösterecektir.
Buradaki fikir, projenize gönderilen bir "birleştirme isteğine" belirli şeyleri isteyip istemediğinizi belirtebilmenizdir. Bu şekilde, insanlar birleştirme isteği açmadan önce kuralları okuyabilirler.
Proje Yönetimi
Genel olarak, tek bir projede yapabileceğiniz çok fazla yönetim işi yoktur, ancak ilginizi çekebilecek birkaç öge bulunmaktadır.
Varsayılan Dalı Değiştirmek
Eğer varsayılan olarak insanların birleştirme isteği açmaları veya varsayılan olarak görmeleri için "main" (ana) dışında bir dal kullanıyorsanız, bunu repo ayarları sayfasında ``Options`` (Seçenekler) sekmesi altında değiştirebilirsiniz.
Sadece açılır menüde varsayılan dalı değiştirin; artık reponun kopyalanması da dahil, tüm önemli işlemler için varsayılan dal bu olacak.
Bir Projeyi Taşıma
GitHub’da bir projeyi başka bir kullanıcıya veya bir kuruluşa aktarmak istiyorsanız, repo ayarları sayfasının ``Options`` (Seçenekler) sekmesinin altında, bunu yapmanıza izin veren ``Transfer ownership`` (Sahipliği aktar) seçeneği bulunmaktadır.
Bu özellik, bir projeyi bırakıyorsanız ve birisi onu devralmak istiyorsa ya da projeniz büyüyorsa ve onu bir kuruluşa taşımak istiyorsanız faydalı olabilir.
Bu sadece repoyu tüm takipçi ve yıldızlarıyla birlikte başka bir yere taşımakla kalmaz, aynı zamanda URL’nizden yeni yere bir yönlendirme de kurar. Ayrıca, sadece ağ isteklerini değil, kopyalama ve Git’ten getirmeleri de yönlendirir.