Gelişmiş Git İş Akışları ve Kullanımı

Son zamanlarda, projelerinizde kaynak denetimi için Git'i kullanmaya başlamanın temellerine baktık. Bu harika bir başlangıç ​​noktası olsa da, günlük kodlama çalışmanızda Git'i kullanarak kafanızı karıştırmanıza yardımcı olacak bir dizi başka komut ve Git iş akışı vardır.

Git İş Akışları

Git'i kullanmaya başladığımda, onu nasıl doğru kullanacağımı bildiğimi düşündüm. Benim ideal yaklaşımım, tüm değişiklikleri şubeler olmadan tek bir noktada yapmak ve ardından bunları depoya taahhüt etmek ve çalışmaya devam etmekti.

Sürüm kontrolünü kullanmamaktan daha iyi olsa da Git'in sağladığı gücün çoğunu kullanmadığımı fark etmem biraz zaman aldı. Git'in benim için çalışmasını sağlamak için, değişikliklerimi dallandırma ve birleştirme stratejisine ihtiyacım vardı.

Sonra git-flow çıktı ve bunu stratejim olarak benimsedim. Harika geliştiricilerin olduğu bir perdenin arkasına bakıyormuşum gibi hissettiğimi hala hatırlıyorum. Artık nasıl çalıştıklarına dair bir içgörüye sahiptim ve onlardan biri olmaya başlayabilirdim.

Ancak git-flow her senaryoya uymaz, bu yüzden ona bakarken, projelerimi yalnız bir geliştirici olarak nasıl yönettiğim de dahil olmak üzere Git projelerinizi düzenli tutmanın diğer birkaç yöntemine de göz atacağız.

git akışı

Git-flow'a şimdi baktığımda, yazılım ortamının 10 yılda büyük ölçüde değiştiğini ve git-flow'un ekibiniz için en iyi seçenek olmayabileceğini kabul ediyorum. Git-flow yazıldığında, bir uygulamayı günde birçok kez dağıtmak nadirdi. Bunun yerine, özellikle çevik bir ekipteyseniz, muhtemelen büyük bir sürüm numarası yaptınız ve birkaç ayda bir veya haftada bir yayınladınız.

Şimdi git-flow'un ne olduğuna bir göz atalım.

Git Flow için grafikler ve Git komutları ile tam kapsamlı açıklamayı görmek istiyorsanız, bu gönderiyi okumalısınız.

Git-flow'da iki dalın sonsuz bir ömrü vardır. İlk olarak, canlı/üretim ortamınıza dağıtılmaya hazır kodu yansıtması gereken ana.

İkincisi, geliştirme şubemiz var. Bu dal, yazılımımızın bir sonraki sürümü için hazır olan en son değişikliklere sahip olmalıdır. Geliştirmedeki değişiklikler canlı uygulamamıza dağıtılmaya hazır olduğunda, bunları ana dalda birleştirir ve sürüm numarasına karşılık gelen sürüm numarasıyla etiketliyoruz.

İki ana dalın dışında, üç tür destek dalı vardır.

1. Özellik

Yalnızca geliştirme dalından bir özellik dalı yapılabilir. Geliştirme dalına geri birleştirilmelidir. Adlandırma, üzerinde çalıştığınız özelliği açıklayan herhangi bir şey olabilir.

Çalışma bir sonraki sürüm için hazır olduğunda, sürüm süresini beklediği geliştirme şubesine geri birleştirilir.

2. Serbest bırakma

Yayın dalları, geliştirme dalından yapılır ve hem geliştirme hem de ana dalda birleştirilmesi gerekir. Release-x kuralıyla bir yayın dalını adlandırırsınız. Pratikte bu genellikle, kullanmayı planladığınız sürüm numarasıyla bir şubeyi şu şekilde adlandıracağınız anlamına gelir: sürüm-2.2

Yazılımınızı yayınlamak için son hazırlığı yapmanın bir yolu olarak bir sürüm dalı kullanırsınız. Bu, dosyaların sürüm numaralarını çarpmayı, çevirilerinizin yapıldığından emin olmayı veya son kod kontrollerini içerebilir.

3. Düzeltme

Düzeltme dalı ana daldan yapılır ve canlı uygulamada hemen ele alınması gereken değişiklikleri içermek için kullanılır. Bu, düzeltilmesi gereken bir hata veya ele alınması gereken bir güvenlik sorunu olabilir.

Sorun çözüldüğünde ve ana şubenize dağıtıldığında, kodunuzu uygun sürüm numarasıyla etiketlersiniz.

Ekiplerin git-flow'u artık kullanmamasının en büyük nedeni, yazılımları yayınlama şeklimizin değişmiş olmasıdır. Daha az sıklıkla daha büyük sürümler yerine, bir uygulamadaki değişikliği günde birkaç kez yayınlayabilirsiniz. Hazır olur olmaz müşterimin sitelerine haftada birçok kez iş gönderdiğimi biliyorum. Sitenin sürüm numaralarını yapmıyoruz, sadece geliştirmeye devam ediyoruz.

Standart git-flow bunu karşılamak için tasarlanmamıştır.

Github Akışı

Birçok kişinin kullandığı ikinci seçenek Github Flow.

Github Flow'un tek büyük kuralı, üretime hazır olduğu için ana daldaki kod ne olursa olsun herhangi bir zamanda dağıtılabilmesidir.

Tüm dallar, yaptığınız şey için açıklayıcı bir adla ana daldan oluşturulur.

Değişikliklerinizi hazırladıktan sonra bir çekme isteği oluşturursunuz.

Çekme istekleri, aynı kod üzerinde çalışan diğer kişilere, bu değişiklikler ana kodla birleştirilmeden önce yaptığınız işin gözden geçirilmeye hazır olduğunu söyler.

Gönderilen bir çekme isteğiniz olduğunda, birlikte çalıştığınız ekip değişiklikleri inceleyebilir ve geri bildirim sağlayabilir. Çekme isteği birleşmeye hazır kabul edilirse projeniz için ana dalda birleştirilir.

Tek bir geliştirici veya çok küçük bir ekip için Github akışının bir dezavantajı, bir çekme isteğinin yönetiminin proje yönetiminde fazladan ek yük oluşturabilmesidir. Bu yüzden işimde kullanmıyorum.

Git İş Akışlarını İstemci Projeleriyle Nasıl Kullanırım?

Müşteri çalışmamda, genellikle bir proje için günlük kod yazan tek kişi benim. Müvekkilim WordPress eklentilerini güncelleyebilir veya bazı CSS'leri değiştirebilir, ancak herhangi bir büyük kodlama işi yapmıyorlar. Bu, Github akışıyla gitseydim, yalnızca ekstra yönetim sorunları yaratan çekme isteklerimi gözden geçireceğim anlamına gelir. Hem git-flow hem de Github akışına biraz benzerlik gösteren kullandığım sisteme bakalım.

Main ve staging adında iki ana dalım var. Ana dal, üretim sitesinde şu anda hangi kod çalışıyorsa onu takip eder. Hazırlama dalı, değişiklikleri canlı siteye göndermeden önce test etmek için kullandığımız hazırlama sitesinde test edilen her şeyi izler.

Her dal ana daldan oluşturulur. Yeni özelliklere şu şekilde bir ad verilir: özellik/32-yeni-özellik. Bu bağlamda, 32 sayısı proje yönetim sistemimizdeki bilet numarasına karşılık gelir ve arkasından gelen kelimeler ne üzerinde çalışıldığının kısa bir açıklamasıdır. Hata düzeltmeleri benzer şekilde hata/20-hata-adı olarak adlandırılır.

Oluşturulan her şube önce hazırlama şubemizle birleştirilir ve ardından müşteri tarafından onaylandıktan veya tarafımca test edildikten sonra ana şubeyle birleştirilir. Bu iş akışı şöyle görünebilir.

# evreleme dalında birleştirme özelliği

git birleştirme özelliği/32-yeni-özellik

# özelliği dağıtın ve test edin

git ödeme ana

git birleştirme özelliği/32-yeni-özellik

# canlı siteye özelliği dağıtın

Projelerimde sürekli dağıtım kurulumum var, bu da kodu ana konuma her bastığımda otomatik olarak canlı siteye gönderildiği anlamına geliyor. Aynı işlem evreleme dalı için de kurulur.

Bir çekme isteği iş akışında kodumu kontrol edebilen bir ekiple çalışıyor olsaydım, bir ekipte iyi çalıştığı için bu sistemi kullanırdım. Çoğunlukla kendi başına çalışan bir geliştirici için, iş akışınızı yavaşlatacak olan yalnızca yönetim yüküdür.

Kullandığım Gelişmiş Git Komutları

Artık Git'i pratik bir iş akışında nasıl kullanabileceğimize dair bir fikrimiz olduğuna göre, bunun gerçekleşmesi için gerekli olacak daha gelişmiş komutlara bir göz atalım. Müşterimin koduyla çalışırken bu komutların her birini haftada en az birkaç kez kullanırım.

Bir GUI uygulaması kullanacak olsanız bile (Git'teki son yazımda bazı iyilerinden bahsetmiştim) arka planda neler olup bittiğini anlamak yine de önemlidir. Git GUI uygulaması tarafından oluşturulan bir sorunu çözmek için çoğu zaman terminal üzerinden çalışmak zorunda kaldım.

Satıra Göre Değişiklik Ekleme

Git kullanımını benim için Terminal tıklamasıyla yapan tek komut git add -p idi. Bu komutu öğrenene kadar GUI uygulamalarını kullandım çünkü kodumda değişiklikler yapardım ama neden bir değişiklik yaptığımı açıklayabilmek için belirli satırları farklı taahhütlere bölmek istiyorum. Bunu yapmak için satırları seçmek için bir GUI kullandım, ancak git add -p, parçalarda değişiklik eklemek için sizi etkileşimli bir arayüzde yönlendirir.

Bunu her gün birçok kez kullanıyorum.

Uzak Git Şubesini İzle

Mevcut bir depoyu aşağı çekiyorsanız ve izlemeniz gereken ancak zaten mevcut olan main ve evreleme gibi şubeleriniz varsa, şubenin bu uzak sürümlerini izlemek için şubelerin yerel sürümlerine söylemeniz gerekir.

Bunu yapmanın birkaç yolu var.

# Uzaktan kumandaya basarken yukarı akışı ayarla

git push -u başlangıç ​​evreleme

# Akış yukarı ayarla

# şu anda uzaktan kumandayla izlemek istediğiniz dalda olduğunuzu varsayar

git branch -u orijin/evreleme

git Branch --set-upstream-to=Origin/hazırlama

# Eğer takip etmek istediğiniz şubede değilseniz sonunda şubeyi belirtin

git Branch --set-upstream-to=Origin/aşama hazırlama

Değişiklikleri Taahhüt Etmeden Kaydet

Bazen henüz yapılmaya hazır olmayan bazı işlerin ortasında kalırsınız, ancak durumunu kurtarmanız gerekir. Git stash'ın kullanışlı olduğu yer burasıdır. Bu komut, değişiklikleri kaldırarak değişiklikleri sizin için saklar. Git stash pop kullanarak onları geri alabilirsiniz. Stash'ı kullanışlı hale getirmek için birkaç komut daha var, ancak bunlar düzenli olarak kullandığım ikisi.

Belirli Bir Git Taahhüdü Çekin

Bazen mevcut işinize belirli bir taahhütte bulunmanız gerekir. Temiz bir HEAD ile (henüz herhangi bir değişiklik yapmadınız), git Cherry-pick ile belirli bir taahhütte bulunabilirsiniz. git Cherry-pick ile ilgili tüm belgeleri burada bulabilirsiniz.

Git, her taahhüt için Git Nesnesi adı verilen ve genellikle SHA olarak adlandırılan uzun bir harf ve sayı dizisi oluşturur. Her taahhüt bir tane aldığından, SHA değeriyle bir işleme başvurabilirsiniz. Git Nesneleri hakkında daha fazlasını okuyun.

İhtiyacınız Olmayan Değişiklikleri Atın

Herhangi bir projenin bir noktasında, değişiklikler yapacağız ve sonra bunun işe yaramadığını anlayacağız ve bunları bir kenara bırakıp baştan başlamamız gerekecek. Olmak istediğimiz yere dönene kadar geri almaya çalışmak yerine, henüz izlenmeyen değişiklikleri kaldırmak için aşağıdaki Git komutunu kullanabiliriz.

git reset --hard

Yukarıdaki komut, kodunuzu şu anda üzerinde çalışmakta olduğunuz daldaki en son taahhüde sıfırlayacaktır. En son taahhütten önceki bir duruma geri dönmek istiyorsak, belirli bir işleme sıfırlamak için bu komutla bir <#commitSHA> kullanabiliriz. Belki de ilk şube ödemesine sıfırlamak için bunu kullanırsınız çünkü işin tüm şube değeri saklamak istediğiniz bir şey değildir, ancak işin bir kısmını zaten izlemiştiniz.

Bunu bir adım daha ileri götürmek için git clean komutuyla henüz git'te izlenmeyen dosya veya dizinleri atabiliriz.

git clean -fd: f ve d bayrakları git'e izlenmeyen dosya ve dizinleri atmasını söyler.

Dalları Kaldır

Her iki haftada bir git status komutunun sonuçlarına bakıyorum ve depomda neler olup bittiğini makul bir şekilde anlamak için çok fazla şubem olduğunu görüyorum. Bu, aşağıdaki komutlarla çözülen destek taleplerine karşılık gelen tüm dalları kaldırabileceğim anlamına gelir.

# yerel sürümü kaldırır

git şube -d $dal adı

#uzaktan kumandamdaki dalı kaldırıyor

git push $remotename --delete $dalname

Sürüm Kontrolünü Kullan

Kullanacağınız tüm Git komutlarında uzman olmayabilirsiniz, ancak unutulmaması gereken önemli bir şey, sürüm kontrolünü kullanmanız gerektiğidir . Bir proje üzerinde çalışan tek kişi siz olsanız bile Git ve Git iş akışını kullanmak projelerinizi düzenli tutmanıza yardımcı olur. Çalışmayan kodu yazdıktan sonra çalışmanızı sıfırlayana kadar CTRL + Z tuşlarına basmanız gerekmez.

Sisteminize güvenebilecek ve projeleriniz için iş üretmeye devam edebileceksiniz.

Tümüyle Yönetilen WordPress Barındırma'yı Deneyin

WordPress için optimize edilmiş barındırmaya mı ihtiyacınız var? Nexcess'in tam olarak yönetilen WordPress barındırma planlarına bugün göz atın.