GitHub akışının bileşenleri

Tamamlandı

Bu ünitede GitHub akışının aşağıdaki bileşenlerini gözden geçiriyoruz:

• Şubeler
• Commit’ler
• Çekme İstekleri
• GitHub Süreci
• Git flow (Git akışı)

GitHub Flow bileşenleri

GitHub'a özgü iş akışlarına geçmeden önce, GitHub Flow'un doğrudan Git'in temel kavramları üzerinde derlendiğini anlamak yararlı olacaktır.

Git, zaman içinde kodunuzdaki değişiklikleri izlemek ve yönetmek için araçlar sağlar. GitHub, bu araçların dallar, commitler, çekme istekleri ve işbirliği için görsel arayüzler gibi özelliklerle kullanımını kolaylaştırarak bu özellikleri geliştirir. Bu kavramların GitHub'da nasıl çalıştığını inceleyerek başlayalım.

Dallar nedir?

Son bölümde deponuzda yeni bir dosya ve yeni bir dal oluşturduk.

Dallar GitHub deneyiminin önemli bir parçasıdır. Varsayılan dalı etkilemeden değişiklik yapmanıza olanak sağlar.

Dalınız yeni özellikler veya düzeltmelerle deneme yapmak için güvenli bir yerdir. Hata yaparsanız, değişikliklerinizi geri alabilir veya hatayı düzeltmek için daha fazla değişiklik gönderebilirsiniz. Siz dalınızı birleştirene kadar değişiklikleriniz varsayılan dalda güncelleştirilmeyecek.

Not

Alternatif olarak, yeni bir dal oluşturabilir ve git'i terminalde kullanarak kullanıma alabilirsiniz. Komut şu şekilde olacaktır: git checkout -b newBranchName

Commitler nelerdir?

Önceki ünitede, bir commit ile depoya yeni bir dosya eklediniz. Şimdi commitlerin ne olduğunu kısaca gözden geçirelim.

Kaydetme, daldaki bir veya daha fazla dosyada yapılan bir değişikliktir. Her işleme, komut satırı aracılığıyla veya doğrudan GitHub'ın web arabiriminde yapıldığından bağımsız olarak benzersiz bir kimlik, zaman damgası ve katkıda bulunan tarafından izlenir. İşlemeler, sorun veya pull isteği gibi bir dosyanın veya bağlantılı öğenin geçmişini gözden geçiren herkes için açık bir denetim izi sağlar.

Terminalinizde Git kullanarak aşağıdakilerle işleme oluşturabilirsiniz:

git commit -m "Add a helpful commit message"

Git deposunda, sürüm denetimi işleminden geçen bir dosya birkaç geçerli durumda bulunabilir. Git deposundaki bir dosyanın birincil durumları İzlenmeyen ve İzlenen'dir.

Izlenmeyen: Henüz Git deposunun parçası olmayan bir dosyanın başlangıç durumu. Git, varlığının farkında değil.

Izlenen: İzlenen dosya, Git'in etkin olarak izlediği dosyadır. Aşağıdaki alt durumlardan birinde olabilir:

• Değiştirilmemiş: Dosya izleniyor, ancak son commit'ten beri değiştirilmemiştir.
• Değiştirilmiş: Dosya son işlemeden bu yana değiştirildi, ancak bu değişiklikler henüz sonraki işleme için hazırlanmamıştır.
• Sahneye Alındı: Dosya değiştirildi ve değişiklikler sahneleme alanına (dizin olarak da bilinir) eklendi. Bu değişiklikler kayıt edilmeye hazırdır.
• Kaydedilmiş: Dosya, deponun veritabanındadır. Dosyanın en son kaydedilmiş sürümünü temsil eder.

Bu durumlar, ekibinizin her dosyanın durumunu ve sürüm denetimi sürecinde nerede olduğunu anlamasına yardımcı olur.

Pull request nedir?

Çekme isteği, bir daldaki işlemelerin başka bir dalda birleştirilmeye hazır olduğunu belirten bir mekanizmadır.

Çekme isteğini gönderen ekip üyesi, bir veya daha fazla gözden geçirenden kodu doğrulamasını ve birleştirmeyi onaylamasını ister. Bu gözden geçirenler, değişiklikler hakkında yorum yapma, kendi değişikliklerini ekleme veya daha fazla tartışma için çekme isteğini kullanma olanağına sahiptir.

GitHub, henüz gözden geçirilmeye hazır olmayan bir çekme isteği açmanıza olanak tanıyan Taslak Çekme İsteklerini de destekler.

Değişiklikler onaylandıktan sonra (gerekirse), çekme isteğinin kaynak dalı (karşılaştırma dalı) temel dal ile birleştirilir.

Dalların, işlemelerin ve çekme isteklerinin nasıl çalıştığını gördüğünüze göre GitHub Flow'da nasıl bir araya geldiklerini inceleyelim.

GitHub iş akışı

GitHub akışı, değişiklikleri güvenli bir şekilde yapmanıza ve paylaşmanıza yardımcı olan basit bir iş akışıdır. Dalları, çekme isteklerini ve birleştirmeleri kullanarak fikirleri denemek ve ekibinizle işbirliği yapmak için idealdir.

Not

GitHub akışı birçok popüler iş akışından biridir. Diğerleri Git Flow ve gövde tabanlı geliştirmedir.

Artık GitHub'ın temellerini bildiğimize göre GitHub akışında ve bileşenlerinde adım adım ilerleyebiliriz.

1. Değişikliklerinizin, özelliklerinizin veya düzeltmelerinizin ana dalı etkilememesi için bir dal oluşturarak başlayın.
2. Ardından, güncelleştirmelerinizi dalda yapın. İş akışınız destekliyorsa, birleştirmeden önce bunları test etmek için bu daldan değişiklikleri dağıtabilirsiniz.
3. Şimdi geri bildirim almak için bir katkı isteği açın ve incelemeye başlayın.
4. Ardından yorumları gözden geçirin ve ekibinizin geri bildirimine göre gerekli güncelleştirmeleri yapın.
5. Son olarak, değişikliklerinize güvendikten sonra onayını alın ve çekme isteğini ana dala birleştirin.
6. Bundan sonra deponuzu temiz tutmak ve güncel olmayan dalları kullanmaktan kaçınmak için dalı silin.

Git flow (Git akışı)

GitHub Flow sürekli teslim için tasarlanmış basit bir iş akışı olsa da , Git akışı genellikle sürüm temelli ortamlarda kullanılan daha yapılandırılmış bir dallanma modelidir. Git Flow, GitHub Flow'dan daha uzun süredir kullanımda ve hâlâ varsayılan dal olarak master yerine main teriminin kullanıldığını görebilirsiniz.

'Başarılı bir Git dallanma modeli'nden Vincent Driessen'in görüntüsü

Git flow Dal Türleri

Git akışı birkaç uzun süreli ve geçici dal kullanır:

• master: Her zaman üretime hazır kodu yansıtır.
• develop: Sonraki sürüm için en son geliştirme çalışmalarını içerir.
• feature/*: Yeni özellikler oluşturmak için kullanılır; develop kaynağından dallanır ve tamamlandığında geri birleştirilir.
• release/*: develop üzerinden yeni bir üretim sürümü hazırlar; son test ve küçük hata düzeltmeleri yapılmasına izin verir.
• düzeltme/*: Üretimdeki sorunları hızla çözmek için kullanılır; master dalından dallandırılır.

Git akış süreci nasıl çalışır?

1. Geliştiriciler, yeni işlevler oluşturmak için özellik dalları ana dalından oluşturur.
2. Yayın zamanı geldiğinde, sürüm dalıdevelop'dan oluşturulur. Bu, geliştirmenin kesintisiz olarak devam edebilmesi için sürüm hazırlama çalışmalarını yalıtıyor.
3. Hata düzeltmeleri sürüm dalına eklenebilir, ancak önemli özelliklerin gelecek bir sürümü beklemesi gerekir.
4. Hazır olduğunda, yayın dalı master içine birleştirilir ve bir sürüm numarasıyla etiketlenir. GitHub, sürüm notları oluşturmanıza yardımcı olması için bu etiketleri kullanabilir.
5. Aynı yayın dalı, eşitlenmiş durumda kalması için develop'ya geri birleştirilmelidir.
6. Kritik bir üretim hatası oluşursa, bir hotfix dalımaster oluşturulur. Düzeltildikten sonra hem masterde hem de develop ile birleştirilir.

Git akışı ne zaman kullanılır?

• Zamanlanmış veya sürüme alınmış sürümlere sahip projeler için en uygun olan
• Birden çok üretim sürümü (örneğin, uzun vadeli destek dalları) bakımını yaparsanız yararlı olur
• Daha yavaş, daha yapılandırılmış geliştirme döngüleri (örn. kurumsal veya düzenlenmiş ortamlar) için idealdir
• Ek dal yönetimi nedeniyle GitHub Flow'dan daha "ağır" olarak kabul edilir

Not

Git akışı, dalları tümleştirmek için birleştirme commit'lerini varsayar. Yeniden baz almak veya squash birleştirmeleri kullanmak dal yapısını ve geçmiş izlemesini etkileyebilir.

GitHub kullanan birçok ekip için GitHub Flow daha basit ve hızlıdır. Ancak ekibiniz öngörülebilirliğe değer verirse ve daha fazla sürüm planlaması gerekiyorsa Git akışı daha uygun olabilir.

Tebrikler! GitHub Flow'un tamamını incelediniz ve Git akışının sürüm temelli projeler için nasıl yapılandırılmış bir alternatif sunduğunu keşfettiniz.

Şimdi sorunlar ve tartışmalar arasındaki farkları ele alacağımız bir sonraki bölüme geçelim.