Güncelleme 2019:
Bu günlerde, soru Git'i kullanan bir bağlamda görülüyordu ve dağıtılmış geliştirme iş akışını (esas olarak GitHub aracılığıyla işbirliği yaparak ) kullanmanın 10 yılı genel en iyi uygulamaları gösteriyor:
master, herhangi bir zamanda üretime dağıtılmaya hazır olan şubedir: bir sonraki sürüm, seçilen bir dizi özellik dalı birleştirilir master.dev(veya entegrasyon dalı veya ' next'), bir sonraki sürüm için seçilen özellik dalının birlikte test edildiği daldırmaintenance(veya hot-fix) şube, mevcut sürüm evrimi / hata düzeltmeleri için devvemaster
İş akışının Bu tür (eğer birleştirmezseniz deviçin master, ancak sadece özellik dalı birleştirme nerede devardından etmek, seçilmesi halinde masterGit uygulanan sırayla, bir sonraki sürüm için hazır değil dalları özelliği kolayca açılan edebilmek için) gitworkflow ( burada gösterilen bir sözcük ) ile kendini repo edin .
Daha fazla bilgi için rocketraman/gitworkflow. Bunu Trunk Tabanlı Geliştirme ile yapmanın tarihi, Adam Dymitruk tarafından yazılan yorum ve tartışmalarda belirtilmiştir .
(kaynak: Gitworkflow: Göreve Yönelik Astar )
Not: Bu dağıtılmış iş akışında, istediğiniz zaman işleyebilir ve herhangi bir sorun olmadan kişisel bir şubeye bazı WIP (İş Devam Ediyor) iletebilirsiniz: bir özellik dalının bir parçası haline getirmeden önce taahhütlerinizi yeniden düzenleyebilirsiniz (git rebase).
Orijinal cevap (Ekim 2008, 10+ yıl önce)
Her şey , sürüm yönetiminizin sıralı niteliğine bağlıdır
Birincisi, bagajınızdaki her şey bir sonraki sürüm için gerçekten mi? Halihazırda geliştirilmiş olan bazı fonksiyonların:
- çok karmaşık ve hala rafine edilmesi gerekiyor
- zamanında hazır değil
- ilginç ama bu bir sonraki sürüm için değil
Bu durumda, gövde mevcut geliştirme çabalarını içermelidir, ancak bir sonraki sürümden önce tanımlanan bir ayırma dalı , yalnızca uygun kodun (bir sonraki sürüm için onaylanmış) birleştirildiği, ardından homologasyon aşamasında sabitlendiği bir konsolidasyon şubesi olarak hizmet edebilir , ve nihayet üretime geçtiğinde donmuştu.
Üretim kodu söz konusu olduğunda, yama dallarınızı da yönetmeniz gerekirken şunları da unutmayın:
- ilk yama seti aslında ilk üretime geçmeden önce başlayabilir (yani, zamanında düzeltemeyeceğiniz bazı hatalarla üretime gireceğinizi biliyorsunuz, ancak ayrı bir dalda bu hatalar için çalışma başlatabilirsiniz)
- diğer yama dalları, iyi tanımlanmış bir üretim etiketinden başlamak için lükse sahip olacak
Dev şubesine gelince , paralel olarak yapmanız gereken başka geliştirme çabalarınız yoksa, bir bagajınız olabilir :
- büyük yeniden düzenleme
- diğer sınıflardaki şeyleri arama şeklinizi değiştirebilecek yeni bir teknik kütüphanenin test edilmesi
- önemli mimari değişikliklerin dahil edilmesi gereken yeni bir yayın döngüsünün başlangıcı.
Şimdi, geliştirme-bırakma döngünüz çok ardışıksa, diğer cevapların önerdiği gibi gidebilirsiniz: bir gövde ve birkaç serbest bırakma dalı. Bu, tüm gelişimin bir sonraki sürüme gireceği kesin olan küçük projeler için işe yarıyor ve sadece dondurulabilir ve yamaların yer alabileceği serbest bırakma dalı için bir başlangıç noktası olarak hizmet edebilir. Bu nominal süreçtir, ancak daha karmaşık bir projeniz olur olmaz ... artık yeterli değildir.
Ville M.'nin yorumuna cevap vermek için:
- geliştirici dalının 'geliştirici başına bir dal' (her bir geliştiricinin işlerini görmek / almak için başkalarının çalışmalarını birleştirmek zorunda kalacağı) anlamına gelmediğini, ancak geliştirme başına bir geliştirici dalın olduğunu unutmayın. çaba.
- Bu çabaların yeniden gövdeye birleştirilmesi gerektiğinde (veya tanımladığınız herhangi bir "ana" veya serbest bırakma dalı), bu geliştiricinin çalışmasıdır, değil - tekrar ediyorum, DEĞİL - SC Yöneticisi (nasıl çözüleceğini bilemez) herhangi bir çelişki). Proje lideri birleşmeyi denetleyebilir, yani zamanında başlayıp / bitirdiğinden emin olabilirsiniz.
- birleştirmeyi yapmak için gerçekte kim seçerseniz seçin, en önemlisi:
- birleştirmenin sonucunu uygulayabileceğiniz / test edebileceğiniz birim testleri ve / veya montaj ortamına sahip olmak.
- söz konusu birleştirme işleminin kendisini çok karmaşık veya oldukça uzun bir süre içinde kanıtladığında, önceki duruma geri dönebilmek için birleştirme işleminin başlangıcından önce bir etiket tanımlamış olması.
