Sürüm yönetimi için github, dalları ve otomatik sürümler nasıl kullanılır? [kapalı]

Şimdilik temel Git / Github kavramlarının çoğunu anlıyorum, ancak daha büyük resmi anlamakta hala sorun yaşıyorum.

Bunlar şimdiye kadar çalışmayı başardığım bazı şeyler:

• İtme taahhütleri
• Dallarla çalışmak
• Github'ı kesintisiz bir entegrasyon sistemi olan Travis CI ile entegre edin
• Travis CI aracılığıyla, otomatik olarak master yapmak ve piyasaya sürülecek olan Github'da bir ZIP olarak yayınlamak için her taahhüdünü otomatik olarak oluştur.

Ancak şimdiye kadar projelerin sadece alfa / beta sürümlerinde çalıştım, bu yüzden pratikte sürümlerini henüz yayınlamadım.

Böylece sürüm oluşturma, ayrı sürümleri sürdürme, sürümleri düzeltme vb. Hakkında daha fazla bilgi edinmek istiyorum.

Aşağıdaki şeylerin gerçekleşmesini nasıl sağlayabilirim:

• Projemin farklı sürümleri var, örneğin sürüm 1.1.0 ve 2.0.0
• Sürümleri düzeltmeleri zorlama, sürümü 1.1.1 veya 2.0.1, vb.
• Sürekli bir entegrasyon sistemi yaparak bu sürümü otomatik olarak çalışır hale getirin ve başarılı olursa, o sürüm için bir sürüm yayınlayın.

Aşağıdaki seçenekler arasında şüphe duyuyorum:

• Her sürüm için etiket kullanmam gerekir mi? Öyleyse, sürekli bir entegrasyon sistemi otomatik olarak sürümleri nasıl oluşturabilir?
• Her sürüm için dallar oluşturmalı mıyım? Öyleyse, bu bir ton dal oluşturmaz mı (1.1 ve 2.0 dalı gibi, düzeltmeler tabii ki o dalın üzerine gider)
• Sürüm numarasını nasıl belirtirim? Sürüm numarasını belirten bir yapılandırma dosyasına sahip olmak uygun mudur, yoksa bunun çevresinde daha akıllı yollar var mı? Bu durumda, eğer önemliyse, bir Java projesi olacaktır.

Git-akışına bakmalısın . Mükemmel (ve popüler) bir dallanma modeli.

Git Akış Özeti

Dallanma

Sonsuza kadar kalan ana sandıklar developve master. masterEn son sürümünüzü developtutar ve en son "kararlı" geliştirme kopyanızı tutar.

Katkıda bulunanlar feature( feature/sözleşmelere göre eklenmiş ) şubeler oluşturur develop :

$ git checkout -b feature/my-feature develop

ve hotfixdallar (öneki hotfix/teamül) kapalı master:

# hotfix the latest version of master
$ git checkout -b hotfix/hotfix-version-number master

# or hotfix from a specific version
$ git checkout -b hotfix/hotfix-version-number <starting-tag-name>

Bu dallar "tek kullanımlıktır", yani ana gövdelere geri takılmadan önce kısa ömürleri vardır. Küçük işlevsellik parçalarını içine almak içindir.

Dalları Bitirme

Bir katılımcı bir featureşubeyle yapıldığında , onu tekrar birleştirir develop:

$ git checkout develop
$ git merge --no-ff feature/my-feature
$ git branch -d feature/my-feature

Bir hotfixşube bittiğinde , ikisini de bir araya getirirler masterve developbu yüzden düzeltme ilerler:

$ git checkout master
$ git merge --no-ff hotfix/hotfix-version-number
$ git checkout develop
$ git merge --no-ff hotfix/hotfix-version-number
$ git branch -d hotfix/hotfix-version-number

Bu sürekli entegrasyon yönüdür.

Bültenleri

Bir yayını paketlemeye başlamaya hazır olduğunuzda release, "sabit" developdalınızdan bir dal oluşturursunuz ( featuredal oluşturma ile aynı ). Daha sonra sürüm numarasını bir etikette belirtin (aşağıda açıklanmıştır).

Ayrı releasedalları kullanmak , develophataları giderirken ve releaseşubeye son dokunuşlar eklerken yeni özellikler geliştirmeye devam etmenizi sağlar .

Eğer serbest bırakılmasını bitirmek için hazır olduğunuzda, birleştirme releasehem içine dal masterve develop(sadece bir gibi hotfixtüm değişiklikler ileriye taşımak böylece).

Etiketleme

Bir releasedal veya dal oluşturduğunuzda hotfix, sürüm numarasını bir etikette uygun şekilde çarptırırsınız. Vanilya git ile bu gibi görünüyor:

$ git tag -a <tag-name> -m <tag-description>

Ayrıca etiketleri (ayrı olarak) uzak havuzunuza da itmeniz gerekir:

$ git push --tags

Genellikle , sürümlerinizin form aldığı anlamsal sürümleri kullanmak en iyisidir major.minor.hotfix. Büyük tümsekler geriye dönük olarak uyumlu değildir, oysaki küçük ve düzeltme tümsekleri geriye dönük olarak uyumlu değildir (beta olmadıkça 0.x.x).

birleştirme

Yukarıda gördüğünüz gibi git-flow, şubeleri aşağıdaki komutla birleştirmenizi önerir:

$ git merge --no-ff <branch-name>

Bu --no-ffseçenek, havuzun mevcut taahhüdünde bir demet şube bırakmadan tüm şube geçmişinizi korumanızı sağlar (böylece endişelenmeyin, her sürüm için bir dalınız olmayacak).

Ayrıca çekmek için teşvik edilirsiniz

$ git pull --rebase

Yani pek çok işe yaramaz birleşme komisyonu eklemiyorsunuz.

Git'i, ikisinde de varsayılan olarak yapmaları için yapılandırabilirsiniz .gitconfig. Buna bakmana izin vereceğim;)

Tarama sürümleri

Birisi kod tabanınızın belirli bir sürümünü ararken, etiketi isme göre kontrol edebilir:

# checkout in detached HEAD to browse
$ git checkout <tag-name>

# OR checkout and create a new local branch (as you might for a hotfix)
$ git checkout -b <new-branch-name> <tag-name>

Veya, birisi github'a göz atıyorsa, "dallar" açılır menüsünde "etiketler" sekmesi de vardır.

Git-flow uzantısını kullanma (önerilir)

Bu modeli kullanmanın en sevdiğim yolu, git için git flow uzantısıyla .

( Düzenleme: Louis, şimdi daha iyi çalışan ve daha aktif olabilecek AVH çatalını tavsiye etti git describe. Teşekkürler Louis.)

Uzatma tüm dağınık parçaları ( merge --no-ffbirleştirmeden sonra dalları kullanmak ve silmek gibi) otomatik hale getirir, böylece hayatınıza devam edebilirsiniz.

Örneğin, uzantıyla birlikte şöyle bir özellik dalı oluşturabilirsiniz:

$ git flow feature start my-feature-name

ve bu şekilde bitir

$ git flow feature finish my-feature-name

Düzeltmeler ve sürümler için komutlar aynıdır, ancak dal adı yerine sürüm numarasını kullanırlar:

# Create hotfix number 14 for this minor version.
$ git flow hotfix start 2.4.14

# Create the next release
$ git flow release start 2.5.0

Git akışı daha sonra sizin için sürüm etiketini oluşturur ve nazikçe herhangi bir yapılandırmada veya bildirim dosyalarında (grunt gibi bir görev yöneticisi ile yapabileceğiniz) sürümün önüne geçmenizi hatırlatır.

Umarım yardımı olur :) Travis CI kurulumunuzla hepsini nasıl entegre edeceğinizden tam olarak emin değilim, ama githooks'un sizi oraya götüreceğini tahmin ediyorum.

Her sürüm için bir etiket kullanmam gerekir mi?

Hayır, etiketleri kullanmanıza gerek yok . Her sürümü etiketlemek istiyorsanız, sorun değil veya CI sisteminizi her oluşturuşunda etiketlemek istiyorsanız bunu da yapabilirsiniz. Etiketler, esasen yalnızca kullanıcıya kolay bir ad verir, böylece daha sonra kolayca görüntüleyebilir ve görüntüleyebilirsiniz.

Her sürüm için dallar oluşturmalı mıyım?

Emin! Git'te dallanma ucuz / ücretsiz, bu yüzden aldığım her fırsattan faydalanıyorum. Ayrıca dalları oldukça hızlı bir şekilde birleştirebilir ve silebilirsiniz. Eğer birçok şubeye sahip olmak zorunda olduğunuzu düşünüyorsanız, daha sonra seçici birleştirme ile her zaman onları kısaltabilirsiniz. Denenmiş ve gerçek bir şema kullanmak istiyorsanız, bir dizi Git dallanma şeması da mevcut.

Sürüm numarasını nasıl belirtirim?

Etiketler genellikle git ile ilgili olduğu gibi sürüm numarasını belirtme şeklinizdir. Bir projenin nasıl versiyonlandırılacağından veya bunu yapmanın en iyi yolundan bahsediyorsanız, oldukça kanala dayalı bir soru olduğu için biraz kazı yapmanız gerekecek. Bazı projeler sonsuza dek Beta'da kalırken, diğerleri de stildeki gibi tam sayı sürümlerini artırıyor (Size krom bakmak)

Her sürüm için etiket kullanmam gerekir mi?

Eğer "sürüm" derken, bir sürüm veya sürüm adayı oluşturan bir dosya dizisini kastediyorsanız, her sürümü etiketlemenizi şiddetle tavsiye ederim. Yolun aşağısında 1.2.7 sürümüne başvurmanız gerekiyorsa, bir taahhüdün karması için avlanmak mı yoksa yalnızca sürüm numarasını mı kullanmak istiyorsunuz?

Ayrıca, git describederleme bilgilerini bir yerde (benim yaptığım gibi) kaydetmek için kullanırsanız, etiketleri kullanmak daha güzel çıktılar almasını sağlar.

Öyleyse, sürekli bir entegrasyon sistemi otomatik olarak sürümleri nasıl oluşturabilir?

Sürekli bir entegrasyon sistemi, etiketleri nasıl kullandığınızdan bağımsız olarak sürümler oluşturabilir. Bir taahhüdün karması temelinde bir sürüm oluşturmasını söyleyebilirsiniz. Etiketler hayatınızı kolaylaştırır.

Her sürüm için dallar oluşturmalı mıyım? Öyleyse, bu bir ton dal oluşturmaz mı (1.1 ve 2.0 dalı gibi, düzeltmeler tabii ki o dalın üzerine gider)

Dallanmayı "sürüm başına" bir şey olarak görmüyorum. Tüm versiyonlarımın masterşubede taahhüt ettiği birkaç projem var . Şimdilik bundan daha karmaşık bir şeye ihtiyacım yok çünkü hiçbir proje istikrarlı bir aşamada değil ve eski sürümleri uzun vadede desteklemeye gerek yok. Ama diyelim ki 1.0, 1.1, 1.2 yayınlamam, sonra 2.0 yayınlamam ve hala 1.0 serisini güvenlik düzeltmeleri vb. İle desteklemem gerekiyor. O zaman kesinlikle 1.x serisinin bakım sürümlerini koymak için bir şubem olacak. .

Sürüm numarasını nasıl belirtirim? Sürüm numarasını belirten bir yapılandırma dosyasına sahip olmak uygun mudur, yoksa bunun çevresinde daha akıllı yollar var mı? Bu durumda, eğer önemliyse, bir Java projesi olacaktır.

Bir yapılandırma dosyası gibi sürüm numaranız için tek bir kaynağa sahip olmak, sayıları birçok yerde güncellemeniz gerekirse ortaya çıkabilecek yağ parmak hatalarını önlemenin en iyi yoludur. Ben ... hmm ... utanç verici bir deneyimden bahsediyorum. 1.3 sürümünü yalnızca yazılımın sürüm 1.2 olduğunu bildirdiğini bulmak için yayınlarsınız. Hata!

Başka bir cevapta, mxdubois size gitflow önerdi. Gitflow'u kullanmaya karar verirseniz, AVH sürümünü kullanmanızı tavsiye ederim . Orijinal sürüm artık aktif olarak korunmuyor. Dikkat çeken bir fark, AVH baskısının git describeakıllıca çalışmasına izin veren sürüm birleştirme işlemleri gerçekleştirmesidir . Orijinal versiyonu gerçekleştirdiği bir şekilde birleştirme gezilerigit describe .

Listenizi tarıyorsanız sürümü odak noktanız olarak görüyorum .

Sürümleri korumanın bir yolu dallar ve birleştirmedir (veya yeniden montaj).

Yani sizde:

master

sonra bir dal oluştur

v1

daha sonra için daha fazla değişiklik ekleyin

master(diff1)

sonra bir dal oluştur

v3

daha sonra için daha fazla değişiklik ekleyin

master(diff2)

Şimdi:

Sürüm 2’yi güncellemek için şimdi

git checkout v2
git merge master  # for the changes you want to bring into version 2
# rebasing is also an option
# resolve any merge conflicts
# Done.

Sürüm 3’ü güncellemek için

git checkout v3
git merge master

Yukarıdakiler toptan güncellemeler içindir.

Muhtemelen daha belirgin değişiklikler yapmak isteyeceğinize rağmen daha muhtemeldir.

git cherry-pick

Kiraz toplama konusunda daha fazla bilgi için http://git-scm.com/docs/git-cherry-pick