Git 🌙
Chapters ▾ 2nd Edition

6.1 GitHub - Bir Projeye Katkıda Bulunmak

GitHub, Git repoları için tek başına en büyük barındırıcıdır ve milyonlarca geliştirici ve projenin işbirliği için merkezi bir noktadır. Tüm Git repolarının çok büyük bir yüzdesi GitHub’de barındırılır ve birçok açık kaynaklı proje, barındırma, sorun takibi, kod incelemesi ve diğer işler için GitHub’i kullanır. Bu nedenle, GitHub, Git açık kaynak projesinin doğrudan bir parçası olmasa da, Git’i profesyonel olarak kullanırken GitHub ile etkileşime geçme ihtiyacı duyma ihtimaliniz oldukça yüksektir.

Bu bölüm, GitHub’i etkili bir şekilde kullanma üzerinedir. Bir hesap oluşturmayı ve yönetmeyi, Git repoları oluşturmayı ve kullanmayı, projelere katkıda bulunma ve kendi projenize katkıları kabul etmek için yaygın iş akışlarını, GitHub’in programlamaya dayalı arayüzünü ve genel olarak hayatınızı kolaylaştıracak birçok başka küçük ipucunu kapsayacağız.

Kendi projelerinizi GitHub üzerinden yayınlamak veya GitHub’ta barındırılan diğer projelerle işbirliği yapmak istemiyorsanız, doğrudan Git Araçları bölümüne geçebilirsiniz.

İlk yapmanız gereken şey ücretsiz bir kullanıcı hesabı oluşturmaktır. https://github.com adresine gidin, henüz alınmamış bir kullanıcı adı seçin, e-posta adresinizi girin ve bir şifre belirleyin, ardından büyük yeşil "Sign up for GitHub" düğmesine tıklayın.

Göreceğiniz bir sonraki şey, yükseltilmiş planların fiyatlandırma sayfasıdır, ancak şimdilik bunu yok sayabilirsiniz. GitHub, e-posta adresinizi doğrulamak için size bir e-posta gönderecektir. E-posta ile gönderilen linki tıklayın ve işleme devam edin. Daha sonra göreceğiniz üzere bu çok önemlidir.

Ekranın sol üst köşesindeki Octocat (sekiz kollu kedi) logosuna tıklamak sizi gösterge panelinize götürecektir. Artık GitHub’ı kullanmaya hazırsınız.

Bir Projeye Katkıda Bulunmak

Artık bir Github hesabınız olduğuna göre, mevcut bir projeye katkıda bulunmakta yardımcı olabilecek bazı ayrıntıları gözden geçirelim.

Projeleri Çatallamak

Bir erişim izniniz olmayan projeye katkıda bulunmak istiyorsanız, projeyi "çatallayabilirsiniz" (fork). Bir projeyi "çatalladığınızda", GitHub projenin tamamen size ait bir kopyasını oluşturur; bu, sizin derleminizde (derlem: namespace) bulunur ve üzerine değişikliklerinizi itebilirsiniz.

Not

"Projeyi çatallamak" (fork) ifadesi, geçmişte bir bağlamda oldukça olumsuz bir anlam taşımıştır: birinin açık kaynaklı bir projeyi farklı bir yöne taşıması, hatta bazen rekip bir proje oluşturarak katkıcıları bölmesi gibi. Ancak GitHub’da "çatallamak" terimi, sadece: üzerinde değişiklikler yaparak katkı sağlamak amacıyla, açık kaynak kodlu bir projeyi, kendi ad-alanınızda çoğaltmak anlamına gelir.

Bu şekilde, kullanıcıları katkılayıcı olarak eklemek ve itme erişimi vermek gibi işlerle uğraşmak zorunda kalınmaz. İnsanlar bir projeyi çatallayabilir, kodlarını itebilir ve (bir sonraki adımda ele alacağımız üzere) değişikliklerini birleştirerek orijinal repoya katkıda bulunmak amacıyla bir birleştirme isteği (pull request) gönderebilirler. Böylece, proje sahibi ve katkıda bulunanlar arasında değişiklikler üzerine bir müzakere başlar. Proje sahibi değişikliklerden memnun olduğu noktada bu değişiklikleri birleştirebilir.

Bir projeyi çatallamak için, projenin sayfasını ziyaret edin ve sayfanın sağ üst köşesindeki "Fork" (çatalla) düğmesine tıklayın.

Fork
Görsel 89. "Fork" (Çatalla) düğmesi.

Birkaç saniye sonra, kendi yazılabilir kodunuzun bir kopyasıyla yeni proje sayfanıza yönlendirileceksiniz.

GitHub Akışı

GitHub, birleştirme isteklerine odaklanan belirli bir iş birliği iş akışı etrafında tasarlanmıştır. Bu akış, ister tek bir ortak repoda sıkı işbirliği yapan bir ekiple, ister düzinelerce çatalı olan bir projeye katkıda bulunan ama birbirini tanımayan yabancılarla, isterse dünyanın dört bir yanında ofisleri bulunan küresel bir şirket için çalışın, sorunsuz bir şekilde çalışır. Bu, Git Dalları bölümünde ele alınmış olan Tematik Dallar iş akışına odaklanmıştır.

Genel olarak nasıl çalıştığı şöyle özetlenebilir:

  1. fork: Projeyi çatallayın.

  2. branch: master dalından konu bazlı (tematik) bir dal çıkarın.

  3. commit: Projeyi geliştirmek için katkılar işleyin.

  4. push: Bu dalı GitHub projenize itin.

  5. pull Request: GitHub’ta bir birleştirme isteği açın.

  6. Değişiklikleri proje sahibiyle tartışın ve katkı işlemeye devam edin.

  7. merge: Proje sahibi değişiklikleri ana dala birleştirir veya birleştirme isteğini reddeder.

  8. pull: Kendi çatalınızı güncellenmiş ana dala eşleyin.

Bu temel olarak Birleşme Yöneticisi İş Akışı bölümünde ele alınan Birleştirme Yöneticisi iş akışıdır, ancak değişiklikleri iletmek ve incelemek için e-posta yerine ekipler GitHub’ın ağ tabanlı araçlarını kullanır.

Örnek olarak, GitHub’da bulunan bir açık kaynak projesine, bu akışı kullanarak bir değişiklik önerisini birlikte inceleyelim.

Birleştirme İsteği Oluşturmak

Diyelim ki, Arduino programlanabilir mikrodenetleyicisinde çalıştırmak için kod arayan Tony https://github.com/schacon/blink adresinde harika bir program dosyası bulur.

TKatkıda bulunmak istediğimiz proje.
Görsel 90. Katkıda bulunmak istediğimiz proje.

Tek sorun, yanıp sönme hızının çok yüksek olması. Her ışıltı arasında 1 saniye yerine 3 saniye beklemenin çok daha iyi olduğunu düşünüyoruz. Bu yüzden programı iyileştirelim ve bir değişiklik önerisi olarak projeye geri gönderelim.

Öncelikle, kendi kopyamızını almak için yukarıda belirtildiği gibi Fork düğmesine tıklıyoruz. Kullanıcı adımız burada "tonychacon" olduğu için kendi kopyamızı https://github.com/tonychacon/blink adresinde bulabilir ve burada düzenleyebiliriz. Yerel olarak kopyalayacak, bir tema dalı oluşturacak, kod değişikliği yapacak ve son olarak bu değişikliği GitHub’a geri iteceğiz.

$ 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 'three seconds is better' (5)
[slow-blink 5ca509d] three seconds is better
 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. Projemizin kendi çatalını yerel olarak kopyalayın.

  2. Açıklayıcı bir tema dalı oluşturun.

  3. Kodda değişiklik yapın.

  4. Değişikliğin iyi olduğundan emin olun.

  5. Değişikliği tema dalına katkı olarak işleyin.

  6. Yeni tema dalınzı GitHub çatalınıza geri itin.

Şimdi GitHub’daki çatalımıza geri dönersek; GitHub’ın yeni tema dalını ittiğinizi fark ettiğini, değişikliklerimizi kontrol etmek ve orijinal projeye bir Birleştirme İsteği açmak için büyük yeşil bir düğme sunduğunu görebiliriz.

Alternatif olarak, <kullanıcı>/<proje>/dal (örnekte: tonychacon/blink/tema_dalı) adresindeki "Branches" (dallar) sayfasına giderek dalınızı bulabilir ve oradan yeni bir birleştirme isteği açabilirsiniz.

Birleştirme isteği düğmesi
Görsel 91. Birleştirme isteği düğmesi

Yeşil düğmeye tıklarsak, birleştirme isteğimize bir başlık ve açıklama vermemizi isteyen bir ekran görürüz. Genellikle buna biraz çaba harcamak faydalı olur, çünkü iyi bir açıklama, orijinal projenin sahibinin ne yapmaya çalıştığınızı, önerdiğiniz değişikliklerin doğru olup olmadığını ve değişikliklerin kabul edilmesinin orijinal projeyi iyileştirip iyileştirmeyeceğini belirlemesine yardımcı olur.

Ayrıca, master dalından önde (ahead) olan tema dalımızdaki katkıların bir listesini (bu senaryoda sadece bir tane) ve bu dalın projenin sahibi tarafından birleştirilmesi durumunda yapılacak tüm değişikliklerin birleştirilmiş bir farkını görürüz.

Birleştirme İsteği
Görsel 92. "Birleştirme İsteği" oluşturma sayfası

Bu ekranda Create pull request (birleştirme isteği oluştur) düğmesine tıkladığınızda, çatalınızı aldığınız proje sahibi bir değişiklik önerildiği konusunda bir bildirim alacak ve tüm bu bilgilere bağlantı veren bir sayfaya yönlendirilecek.

Not

Birleştirme İstekleri genellikle katkı sağlayan kişi tamamlanmış bir değişikliği yapmaya hazır olduğunda, bu gibi açık projelerde yaygın olarak kullanılır; ancak iç projelerde geliştirme döngüsünün başında da sıklıkla kullanılır. Çünkü Birleştirme İsteği açıldıktan sonra bile tema dalına güncelleme yapabilirsiniz. Genellikle projenin sonunda değil, başında açılır; işi ekipçe, bir bağlam içinde ardışık yapabilmek için bir yol olarak kullanılır.

Birleştirme İsteği Tekrarı

Bu noktada, proje sahibi önerilen değişikliği inceleyebilir, birleştirebilir, reddedebilir veya üzerine yorum yapabilir. Diyelim ki fikri beğendi, ancak ışığın kapalı kalma süresinin, açık kalma süresinden biraz daha uzun sürmesini tercih etti.

Bu konuşma, GitHub üzerinde çevrimiçi olarak gerçekleşirken, Dağıtık Git bölümünde sunulan iş akışlarında e-posta üzerinden gerçekleşir. Proje sahibi, birleştirilmiş farkı gözden geçirebilir ve herhangi bir satıra tıklayarak bir yorum bırakabilir.

Birleştirme isteği satır yorumu
Görsel 93. Birleştirme isteğindeki belirli bir kod satırına yorum yapmak

Yönetici bu yorumu yaptıktan sonra, isteği açan kişi (ve hatta repoyu izleyen herkes) bir bildirim alır. Bunu özelleştirmeyi daha sonra ele alacağız, ancak e-posta bildirimlerini açmış olsaydı, Tony şöyle bir e-posta alırdı:

E-posta bildirimi
Görsel 94. E-posta bildirimi olarak gönderilen yorum

Ayrıca herkes bu birleştirme isteği üzerine herkese açık yorumlar da yapabilir. Birleştirme isteği tartışma sayfası bölümünde, projenin sahibinin hem bir kod satırına yorum yapması, hem de tartışma bölümünde genel bir yorum bırakması örneğini görebilirsiniz. Kod yorumlarının da konuşmaya dahil edildiğini görebilirsiniz.

Birleştirme isteği tartışma sayfası
Görsel 95. Birleştirme isteği tartışma sayfası

Şimdi katkılayıcı, değişikliklerinin kabul edilmesi için yapması gerekenleri görebilir. Neyse ki bu çok basittir. E-posta üzerinden serinizi tekrar oluşturup, posta listesine yeniden göndermeniz gerekirken; GitHub’ta sadece konu dalına tekrar katkı işleyip iterseniz, birleştirme isteği otomatik olarak güncellenir. Birleştirme isteği kapanışı bölümünde, güncellenen bir birleştirme isteğindeki eski kod yorumunun, artık değiştirilmiş bir satıra yapıldığı için daraltıldığını görebilirsiniz.

Varolan bir birleştirme talebine yeni katkılar işlemek, bir bildirim tetiklemez; bu yüzden Tony düzeltmelerini ittikten sonra, proje sahibine istenen değişikliği yaptığını bildirmek için bir yorum bırakmaya karar verir.

Birleştirme isteği kapanışı
Görsel 96. Birleştirme isteği kapanışı

Bu birleştirme talebinin "Files Changed" (Değiştirilen Dosyalar) sekmesine tıklarsanız, "bileşke fark"ı alırsınız; yani, bu konu dalı birleştirildiğinde, ana dalınıza kaynaşacak olan tüm kod farkını. git diff terimi, temelde bu birleştirme isteğinin dayandığı dal için git diff master...<branch> komut çıktısını site otomatik olarak gösterir. Bu tür bir fark hakkında daha fazla bilgi için Katkıları Tanımlamak bölümüne bakın.

Diğer bir dikkat çekici nokta ise; GitHub’ın birleştirme isteğinin temiz bir şekilde birleştirilip birleştirilemeyeceğini kontrol etmesi ve birleştirmeyi sunucuda yapmak için bir düğme oluşturmasıdır. Bu düğme, repoya yazma erişiminiz varsa ve basit birleşme mümkünse görünür. Tıklarsanız, GitHub "ileri-sarma" (fast-forward) olabilecek durumlarda bile "ileri-sarmayan" (non-fast-forward) birleşmesi gerçekleştirir ve bir birleştirme katkısı oluşturur.

Tercih ederseniz, basitçe dalı çekip (pull), yerelde birleştirebilirsiniz (merge). Bu dalı master dala birleştirir ve GitHub’a iterseniz, birletşirme isteği otomatik olarak kapanır.

Bu, çoğu GitHub projesinin kullandığı temel iş akışıdır. Konu dalları oluşturulur, üzerlerinde birleştirme istekleri açılır, bir tartışma başlar, belki daha fazla çalışma yapılır ve sonunda istek ya kapatılır ya da birleştirilir.

Not
Çatal zorunlu değil

Önemli bir nokta da, aynı repodaki iki dal arasında da bir birleştirme isteği açabileceğinizdir. Bir özellik üzerinde birileriyle birlikte çalışıyorsanız ve her ikininin de projeye yazma erişimi varsa; bir konu dalını repoya itebilir; ardından üzerinde tartışma ve kod incelemesi sürecini başlatmak için, aynı projenin master dalına bir birleştirme talebi açabilirsiniz. Çatallamanız gerekmez.

Gelişmiş Birleştirme İstekleri

GitHub’daki bir projeye katkıda bulunmanın temellerini öğrendikten sonra, birleştirme istekleriyle ilgili birkaç ilginç ipucunu ve püf noktasını öğrenelim; böylece onları daha etkili bir şekilde kullanabilirsiniz.

Yama Olarak Birleştirme İsteği

Birçok projenin, birleştirme isteklerini; posta listesi tabanlı projelerin düşündüğü gibi sıralı ve kusursuz bir yama kuyruğu olarak görmediğini anlamak gereklidir. Çoğu GitHub projesi, Birleştirme isteği dallarını, önerilen bir değişiklik etrafında yapılan karşılıklı konuşmalar olarak düşünür ve uygulanan birleştirme bileşik bir fark ile sonuçlanır.

Değişiklik genellikle, kodun mükemmel olduğu düşünülmeden önce önerildiği için - ki posta listesi tabanlı yama serisi katkılarında bi çok daha nadirdir - bu önemli bir ayrımdır. Bu, yürütücülerle daha erken bir müzakere başlatır, böylece doğru çözüme varılması daha ziyade bir topluluk çabası haline gelir. Bir birleştirme isteğiyle kod önerildiğinde, yürütücüler veya topluluk bir değişiklik önerirse; yama serisi genellikle yeniden yapılmaz. Bunun yerine bu ek değişiklik, yeni bir katkı olarak dalın içine itilir ve önceki çalışmanın bağlamı korunur.

Örneğin, Birleştirme isteği kapanışı örneğine tekrar bakarsanız, katkı sağlayıcının katkısını yeniden temellemediğini (rebase) ve başka bir birleştirme isteği göndermediğini farkedeceksiniz. Bunun yerine, yeni katkılar işleyip, bunları mevcut dala itmiştir. Bu şekilde, gelecekte bu birleştirme isteğine tekrar baktığınızda, kararların neden alındığına dair tüm bağlamı kolayca görebilirsiniz. Sitedeki "Birleştir" düğmesine tıklamak; gerektiğinde orijinal tartışmayı aramayı kolaylaştırmak için, birleştirme isteğine referans veren bir birleştirme katkısı oluşturur.

Ana Repoyla Güncel Tutmak

Eğer birleştirme isteğiniz güncelliğini yitirirse veya başka bir nedenle temiz bir şekilde birleştirilemezse; yürütücünün bunu kolaylıkla birleştirebilmesi için bunu düzeltmek isteyeceksiniz. GitHub bunu sizin için test edecek ve her birleştirme isteğinin alt kısmında birleştirmenin normal olup olmadığını size bildirecektir.

PR birleştirme hatası
Görsel 97. Birleştirme isteği temizce yapılamaz

Eğer Birleştirme isteği temizce yapılamaz gibi bir şey görürseniz; rengin yeşile dönmesi için dalınızı düzeltmek istersiniz, böylece yürütücü ekstra iş yapmak zorunda kalmaz.

Bunu yapmanın temel olarak iki yolu bulunmaktadır. Ya dalınızı hedeflediğiniz dalın (genellikle çatalladığınız reponun master dalı) üzerine yeniden temellersiniz (rebase) veya hedef dalı kendi dalınıza birleştirirsiniz.

GitHub’daki çoğu geliştirici, önceki bölümde ele aldığımız aynı nedenlerden dolayı, genellikle ikincisini seçer. Önemli olan katkı geçmişi ve nihai birleşmedir. Yeniden temellemek biraz daha temiz bir geçmiş sağlar ama çok daha zor ve hata yapmaya meyilli bir işlemdir.

Eğer hedeflediğiniz dala birleştirerek, birleştirme isteğinizi birleştirilebilir hale getirmek istiyorsanız; özgün repoyu yeni bir uzak repo olarak ekleyip, ordan getirirsiniz (fetch); ardından reponun ana dalını, kendi tema dalınıza birleştirirsiniz; sorunları düzeltir ve son olarak bunu üzerinde birleştirme isteği açtığınız dala geri itersiniz.

Önceki "tonychacon" örneğini kullanırsak; diyelim ki orijinal yazar birleştirme isteğinde çakışma oluşturacak bir değişiklik yaptı. Şimdi bu adımları birlikte gözden geçirelim.

$ 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 repoyu ``upstream`` adıyla bir uzak olarak ekleyin.

  2. Bu uzaktan en yeni çalışmayı alın.

  3. Bu reponun ana dalını kendi tema dalınıza birleştirin.

  4. Oluşan çakışmayı düzeltin.

  5. Aynı konu dalına geri yükleyin.

Bunu yaptıktan sonra, birleştirme isteği otomatik olarak güncellenecek ve düzgünce birleştirilebiliyor mu diye tekrar kontrol edilecektir.

PR onarıldı
Görsel 98. Birleştirme isteği sorunsuzca gerçekleştirilebiliyor

Git’in harika özelliklerinden biri de sürekli olarak bunu yapabilmenizdir. Çok uzun süreli bir projeniz varsa, hedef dal üzerinden defalarca birleştirme işlemi yapabilirsiniz ve sadece son birleştirdiğinizden beri ortaya çıkan çakışmalarla uğraşmanız gerekecektir; bu da süreci çok daha yönetilebilir hale getirir.

Eğer mutlaka dalı temizlemek için yeniden temellemek istiyorsanız, elbette yapabilirsiniz, ancak zaten açılmış olan dal üzerinde "zorla itme işlemi" (force push) yapmaktan kaçınmanız şiddetle tavsiye edilir. Başkaları tarafından çekilip, üzerinde daha fazla çalışma yapılmışsa; Yeniden Temellemenin Riskleri bölümünde belirtilen tüm sorunlarla karşılaşırsınız. Onun yerine, yeniden temellenmiş dalı GitHub’da yeni bir dala itin ve eskisine referans veren yepyeni bir birleştirme isteği açın, ardından orijinal isteği kapatın.

Referanslar

Sonraki sorunuz muhtemelen "Eski birleştirme isteğine nasıl referans verebilirim?" olabilir. GitHub’da yazı yazabileceğiniz hemen hemen her yerde diğer şeylere referans vermenin pek çok farklı yolu bulunmaktadır.

Başka bir birleştirme isteği veya bir iş paketine nasıl referans verileceğini açıklayalım. Tüm birleştirme istekleri ve iş paketleri numaralandırılır ve bunlar proje içinde benzersizdir. Örneğin, birleştirme isteği #3 ve iş paketi #3’e sahip olamazsınız. Başka bir birleştirme isteği veya iş paketine herhangi bir yerden referans vermek istiyorsanız, sadece herhangi bir yorum veya açıklamada #<num> yazabilirsiniz. Ayrıca, birleştirme isteği veya iş paketi başka bir yerdeyse daha kesin olabilirsiniz; kendi reponuzun bir çatalında bir paket veya isteğe atıfta bulunuyorsanız kullanıcıadı#<num> yazın, başka bir repoda bir şeye referans veriyorsanız kullanıcıadı/repo#<num> yazın.

Hadi bir örnek üzerinde görelim. Diyelimk ki önceki örnekteki dalı yeniden temelledik, onun için yeni bir birleştirme isteği oluşturduk ve şimdi yeni istekten eskisine referans vermek istiyoruz. Ayrıca, repo çatalındaki bir iş paketine ve tamamen farklı bir projedeki bir başka iş paketine de referans vermek istiyoruz. Açıklamayı Birleştirme İsteği çapraz referansları. örneğinde olduğu gibi doldurabiliriz.

PR referansları
Görsel 99. Birleştirme İsteği çapraz referansları.

Bu birleştirme isteği gönderildiğinde, bunların Birleştirme isteği çapraz referansları gibi işlendiğini göreceğiz. we’ll see all of that rendered like Birleştirme isteği çapraz referansları.

PR referansaları işlendi.
Görsel 100. Birleştirme isteği çapraz referansları

Orada belirttiğimiz tam GitHub URL’sinin yalnızca gerekli bilgilere kısaltıldığını görebilirsiniz.

Şimdi Tony, orijinal Birleştirme İsteğini kapatırsa: GitHub, birleştirme isteği zaman çizelgesinde otomatik olarak bir geri izleme etkinliği oluşturduğu için, yeni istekte onu görebiliriz. Bu, bu birleştirme isteğini ziyaret eden ve kapatıldığını gören herkesin, onu geçersiz kılan isteğe kolayca bağlantı kurabileceği anlamına gelir. Bu bağlantı Kapalı birleştirme isteği zaman çizelgesinde yeni birleştirme isteği bağlantısı. gibi görünecektir:

Kapalı PR
Görsel 101. Kapalı birleştirme isteği zaman çizelgesinde yeni birleştirme isteği bağlantısı.

Sadece iş paketi numaralarını değil, aynı zamanda bir belirli bir katkıyı SHA-1 ile de referans verebilirsiniz. Tam 40 karakterlik bir SHA-1 belirtmeniz gerekiyor, ancak GitHub bu şekilde bir yorumda gördüğünde doğrudan katkıya bağlantı kurar. Tekrar edersek, katkıları çatallarda veya diğer repolarda, aynı iş paketlerinde olduğu gibi eferanslayabilirsiniz.

GitHub Flavored (Aromalı) Markdown

Diğer İş Paketlerine bağlantı vermek, GitHub’da hemen hemen her metin kutusunda yapabileceğiniz ilginç şeylerin, sadece başlangıcıdır. İş Paketi ve Birleştirme İsteği açıklamaları, yorumlar, kod yorumları ve daha fazlasında "GitHub Flavored Markdown" adı verilen bir yapıyı kullanabilirsiniz. Markdown, düz metin şeklinde yazıp, zengince işlenmiş olarak sunmak anlamına gelir.

Metin ve yorumların, Markdown kullanılarak nasıl yazılacağının ve işleneceğinin örneği için GitHub Aromalı Markdown’ın yazım ve sunum örneği. bağlantısına bakın.

Markdown örneği
Görsel 102. GitHub Aromalı Markdown’ın yazım ve sunum örneği.

GitHub Markdown’a kendinden kattığı çeşni sayesinde, size sıradan Markdown sözdiziminden öteye geçen deneyimler sunar. Bunlar, bir İş Paketi yorumu, Birleştirme İsteği veya açıklama oluştururken oldukça kullanışlı olabilir.

Görev Listeleri

Özellikle Birleştirme İsteklerinde kullanım için, gerçekten kullanışlı ilk GitHub özel Markdown özelliği, Görev Listesidir. Bir görev listesi, yapmak istediğiniz işlerin tıklanabilir kutucuklar halinde listelenmesidir. Bunları bir İş Paketi veya Birleştirme İsteği içine koymak, genellikle tamamlanmasını isteğininiz işleri belirtir.

Bir görev listesini şöyle oluşturabilirsiniz:

- [X] Kod yaz
- [ ] Tüm testleri yaz
- [ ] Dokümentasyonu hazırla

Bunu, Birleştirme İsteği veya İş Paketinin açıklamasına dahil edersek, sonucu .Markdown yorumu içindeki görev listesi. gibi görüntülenir.

Örnek görev listesi.
Görsel 103. .Markdown yorumu içindeki görev listesi.

Bu genellikle Birleştirme İsteklerinde, Birleştirme İsteği’nin birleştirilmeye hazır olmadan önce, dalda ne yapmak istediğinizi belirtmek için kullanılır. Gerçekten harika olan kısım; doğrudan onay kutularına tıklayarak yorumları güncelleyebilmenizdir - görevleri işaretlemek için Markdown’ı doğrudan düzenlemenize gerek yoktur.

Dahası, GitHub, İşlerinizde ve Birleştirme İsteklerinizde görev listelerini arar ve onları listelenen sayfalarda meta veri olarak gösterir. Örneğin, içinde görevler listesi olan bir Birleştirme İsteğiniz varsa ve Birleştirme İstekleri giriş sayfasına bakarsanız, ne kadarının tamamlandığını görebilirsiniz. Bu, insanların Birleştirme İsteklerini alt görevlere ayırmalarına ve diğer kişilerin dalın gelişimini izlemesine yardımcı olur. Bunu Birleştirme İsteği listesinde görev listesi özeti. örneğinde görebilirsiniz.

Örnek görev listesi
Görsel 104. Birleştirme İsteği listesinde görev listesi özeti.

Bu özellikler, bir Birleştirme İsteğini erken açarsanız ve yeni bir özelliğin gelişimini izlemek için kullanırsanız, son derece yararlı olabilir.

Kod Parçacıkları (Code Snippets)

Yorumlara kod parçacıkları da ekleyebilirsiniz. Bu, deneyebileceğiniz bir şeyi gerçekten denemeden önce, bir katkı yorumu olarak eklemek isteğiğinizde, çok kullanışlı bir özelliktir. Ayrıca, çalışmayan veya bu Birleştirme İsteğinde uygulanabilecek kod örneği eklemek için de sıkça kullanılır.

Kod parçacığını eklemek için, onu (ters-kesme işaretleriyle "`") kafeslemelisiniz.

```java
for(int i=0 ; i < 5 ; i++)
{
   System.out.println("i is : " + i);
}
```

Eğer yukarıdaki örnekte olduğu gibi java ya da bir programlama dili adı eklerseniz, GitHub ek olarak kod parçacığının sözdizimini de vurgulamaya çalışacaktır. Yukarıdaki örnekte sonuç Kafeslenmiş kod örneği. gibi olur.

Kafeslenmiş kod
Görsel 105. Kafeslenmiş kod örneği.

Alıntı

Eğer uzun bir yorumun küçük bir kısmına yanıt veriyorsanız, diğer yorumdan alıntı yapacağınız kısımları, > karakteriyle başlatarak seçebilirsiniz. Aslında, bu o kadar yaygın ve kullanışlıdır ki bunun için bir klavye kısayolu bile vardır. Yanıtlamak amacıyla alıntılamak istediğiniz metni vurgulayın ve r tuşuna basın, bu size yorum kutusunda bu metni alıntılayacaktır.

Alınıtı şöyle görünecektir:

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

İşlendikten sonra yorum İşlenmiş alıntı örneği.'deki gibi görünecektir.

İşlenmiş alıntı
Görsel 106. İşlenmiş alıntı örneği.

Emoji

Son olarak, yorumlarınızda emoji de kullanabilirsiniz. Bu aslında, birçok GitHub İşlemi ve Birleştirme İsteğinde gördüğünüz yorumlarda yaygın olarak kullanılır. Hatta GitHub’da bir emoji yardımcısı bile vardır. Bir yorum yazıyorsanız ve : karakteri ile başlarsanız, bir otomatik tamamlama, aradığınız emojiyi bulmanıza yardımcı olur.

Emoji tamamlayıcısı
Görsel 107. İş başındaki emoji tamamlayıcısı.

Emojiler, yorumun herhangi bir yerinde :<isim>: şeklinde olabilir. Örneğin, şöyle bir şey yazabilirsiniz:

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:

İşlendiğinde Yoğun emojili yorumlar. gibi görünür.

Emoji
Görsel 108. Yoğun emojili yorumlar.

Bu yorum müthiş faydalı sayılmaz, ama duyguları başka türlü iletmenin zor olduğu bir ortama, eğlenceli bir unsur ekler.

Not

Bu günlerde emoji karakterlerini kullanan çok sayıda ağ hizmeti bulunmaktadır. Ne demek istediğinizi ifade eden emoji bulmanıza yardımcı olacak harika bir referans çizelgesi şurada bulunabilir:

Görüntüler

Teknik olarak, bu GitHub’a özgün Markdown olmasa da son derece kullanışlıdır. Yorumlara Markdown görüntü bağlantıları eklemenin yanı sıra, ilgili URL’leri bulmak ve gömülü bağlantılar eklemek de zor olabilir; bu yüzden GitHub metin alanlarına sürükleyip bırakarak görüntüler gömmenize olanak tanır.

Görüntüleri sürükle ve bırak
Görsel 109. Görüntüleri yüklemek için sürükleyip bırakarak gömün.

Görüntüleri yüklemek için sürükleyip bırakarak gömün. bağlantısına bakarsanız, metin alanının üstünde küçük bir ipucu, "Markdown olarak ayrıştırıldı" uyarısı, görebilirsiniz. Buna tıkladığınızda, GitHub’da Markdown ile yapabileceğiniz her şeyi içeren bir hatırlatma notuna erişebilirsiniz.

GitHub’taki Herkese Açık Repolarınızı Güncel Tututun

Bir GitHub reposunu çatalladıktan sonra, "oluşturduğunuz çatal" artık sizin reponuzun bir parçasıdır ve orijinalinden bağımsız olur. Özellikle, orijinal repoya yeni katkılar işlendikçe; GitHub, şu şekilde bir mesajla sizi bilgilendirir:

This branch is 5 commits behind progit:master.
Bu dal progit:master'in 5 katkı gerisindedir.

Ancak, GitHub reponuz asla GitHub tarafından otomatik olarak güncellenmez; bunu kendiniz yapmanız gerekir. Neyse ki, bunu yapmak çok kolaydır.

Bunu yapmanın yollarından biri hiçbir yapılandırma gerektirmez. Örneğin, https://github.com/progit/progit2.git adresinden çatallandıysanız, master dalınızı şu şekilde güncel tutabilirsiniz:

$ git checkout master (1)
$ git pull https://github.com/progit/progit2.git (2)
$ git push origin master (3)
  1. Eğer başka bir daldaydıysanız, master dalına dönün.

  2. Değişiklikleri https://github.com/progit/progit2.git adresinden getirin ve bunları master dala birleştirin.

  3. master dalınızı origin 'a itin.

İşe yarıyor, ancak her seferinde getirme URL’sini yazmak biraz can sıkıcı. Bu işlemi yapılandırma yoluyla otomatik hale getirebilirsiniz:

$ 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. Kaynak reposunu ekleyin ve ona bir isim verin. Burada progit adı verilmiştir.

  2. master dalınızı progit uzak reposundan getirmek üzere ayarlayın.

  3. Varsayılan itme reposunu origin olarak tanımlayın.

Bunu bir kez yaptığınızda iş akışı çok daha basit hale gelir:

$ git checkout master (1)
$ git pull (2)
$ git push (3)
  1. Eğer başka bir daldaysanız, master dalına geri dönün.

  2. progit reposundan değişiklikleri getirin ve master dalına birleştirin.

  3. master dalınızı origin 'a itin.

Bu yaklaşım faydalı olabilir, ancak bazı dezavantajları da bulunmaktadır. Git sessizce bu işlemi yapacaktır, ancak master dalına bir katkı işlerseniz; progit 'den çekip, ardından origin 'e gönderirken, size bir uyarı vermeyecektir. Bu düzenleme ile tüm bu işlemler geçerli hale gelir. Bu nedenle, master dalına doğrudan katkı işlememeye dikkat etmelisiniz, çünkü bu dal etkin bir şekilde üst-akım reposuna aittir.

scroll-to-top