İşte anlaşma, yeni bir şirkete katıldım ve neredeyse bir yıl boyunca dokunulmamış bir daldaki işi bitirmem istendi. Bu arada, ana dal istikrarlı bir hızla büyüyor. İdeal olarak, ana daldan tüm özelliklerin özellik dalına getirdiği tüm değişiklikleri birleştirmek ve oradan çalışmaya devam etmek istiyorum, ancak buna nasıl yaklaşacağımdan emin değilim.

Şubenin her iki tarafındaki önemli değişiklikleri korurken bu birleştirme işlemini nasıl güvenli bir şekilde gerçekleştiririm?

Kalbinde, iki (muhtemelen uyumlu olmayan) kod parçasının nasıl birleştirileceği , bir sürüm kontrol sorunu değil , bir geliştirme sorunudur. Git birleştirme komutu bu işlemde yardımcı olabilir, ancak sorunun şekline bağlıdır.

Her iki sürümün de tabanla karşılaştırılması en mantıklı olanıdır. Bu size bunu ilerletmek için en iyi strateji hakkında bir fikir verecektir. Her daldaki değişikliklerin niteliğine ve örtüşmesine bağlı olarak yaklaşımınız farklı olabilir.

İdeal senaryoyu hayal edin: ana dalın ve özellik dalının her birinin sadece kodun birbirini dışlayan kısımlarını değiştirdiğini keşfedersiniz, böylece tüm değişiklikleri yapıp başarabilirsiniz.

Tabii ki, bu neredeyse kesinlikle bir durum olmayacak, ancak soru şu: Bu ideal senaryodan ne kadar uzakta olacak? yani değişiklikler ne kadar iç içe geçmiş?

Ayrıca, eski özellik dalı ne kadar olgunlaştı? İyi bir çalışma durumunda mıydı (yoksa bilinmiyor)? Özelliğin ne kadarı tamamlandı?

Ana branştaki ilgili kod son bir yılda çok değişmişse veya özellik çok olgun bir durumda değilse , en yeni bir çatal yaratmayı ve eski özelliği tekrar el ile eklemeyi düşünebilirim. Bu, çalışmasını sağlamak için artan bir yaklaşım izlemenizi sağlar.

Çok sayıda kodun karışık bir birleşimini yaparsanız ve çalışmazsa, hata ayıklamak oldukça zor olacaktır. Ana şube geçtiğimiz yıl boyunca çok değiştiyse, çalışabilmesi için büyük tasarım değişiklikleri gerekebilir. Bu değişikliklerin "anlaşmazlıkları çözme" yoluyla yapılması uygun olmaz, çünkü bu, tüm değişiklikleri bir kerede yapmayı ve çalışmasını ummayı gerektirir. Bu sorun, eski kısmen bitmiş daldaki böceklerin olasılığı ile daha da artmaktadır.

Sınırlı git deneyimimde, eğer ana bağlantı noktasından çok uzağa gittiğinde, özellik dalını yeniden başlatmanın bazen daha hızlı olduğunu söyleyebilirim.

Kodun arkasındaki tarihi bilmeden iki şubeyi birleştirmek (projeye henüz yeni katıldığınıza göre) gerçekten zordur ve bahse girerim projeyi en başından takip eden bir geliştiricinin bile birleştirme konusunda bazı hatalar yapacağına bahse girerim.

Özellik dalı çok büyük değilse tabii bu mantıklı ama sadece olabilir eski özellik dalı tutmak , açılmış tekrar dalı ustadan ve elle değişiklikleri yeniden tanıtmak olduğunu oluşturma bu özelliği. Bunun en manuel yaklaşım olduğunu biliyorum, ancak eksik veya taşınan kod durumunda tam kontrolde olmanızı sağlar.

Bu durumda üst düzey bir programla programlama, kodu daha iyi tanımanıza yardımcı olacak en iyi senaryo olacaktır.
Birleştirme çatışmalarını ve test süresini dikkate alırsanız, daha da hızlı olabilirdi!

En azından bir birleşme yapmaya çalışılmasının kesinlikle yapılacak en iyi şey olduğunu varsaydım . Bu başarısız olursa veya çok zor çıkarsa, kiraz toplamasını deneyin, eğer yanlış giderse manuel yoldan gidin.

git-imerge bu amaç için tasarlandı. Artımlı birleştirme için bir yöntem sunan bir git aracıdır . Artımlı olarak birleştirerek, yalnızca iki sürüm arasındaki çarpışmalarla uğraşmak zorunda kalmazsınız. Ayrıca, bireysel değişiklikler daha küçük olduğundan, çok daha fazla sayıda otomatik olarak birleştirme gerçekleştirilebilir.

Ana hat kafasını bir yıl eski bir dalda birleştirmeye çalışmak, hayal kırıklıklarında bir egzersiz yapmak ve alnınızla masanın üzerindeki çukuru derinleştirmek olabilir.

Ana hat, aylar boyunca bir seferde olduğu yere ulaşamadı. O da gelişme ve bültenleri vardı. Hepsini tek bir monolitik birleştirme içinde güncellemeye çalışmak çok zor olabilir.

Bunun yerine, eski dal ayrılmasından sonra ilk özellik birleştirme ile ana çizgiye geri dönerek başlayın. Get o birleştirme çalışma. Sonra bir sonraki özellik birleştirilir. Ve bunun gibi. Bu özelliklerin birçoğunun birleşmesi çatışma olmadan birleşecektir. Eski dalın geçerli işlevselliğinin ana hattın gittiği yön ile uyumlu kaldığından emin olmak önemlidir.

Diğer değişikliklerde birleşme rolü için eski şubenin başından şubeye dalmak isteyebilirsiniz. Bu, birisinin geri döndüğü zaman taahhüt ve tarihin açık olduğundan ve her bir dalın rolünün ve politikasının ne olduğunu anladığından emin olmakla ilgilidir. Eski dalı bir özellik dalıydı. Çalıştığınız bir biriktirme ve uzlaşma dalıdır.

Eski özellik veya bırakma dalları hala oradaysa ve kolayca erişilebilirse, bunların çoğu daha kolay olacaktır (bazı yerlerde, eskiden daha eski olan dalların adlarını temizleme politikası vardır; ).

Tüm bunlarda önemli olan, ana hat geçmişinin her bir parçasını başarılı bir şekilde birleştirdikten sonra test edip düzeltmeyi sağlamaktır. Bir şey çatışmalar olmadan birleşse de, bu sadece kodun çelişmediği anlamına gelir . Eski özellik özelliğine erişilme şekli kullanımdan kaldırılmış veya kaldırılmışsa, başarılı birleştirme işleminden sonra düzeltmeler yapmanız gerekebilir.

Bir kenara, bu diğer sürüm kontrol sistemleri için de geçerlidir. Belirli bir svn komisyonu grubunu bir özellik için bir dalda (kiraz toplama) birleştirme, şubeyi bu özellikle çalışacak şekilde sabitleme ve bir sonraki svn komisyonunu bir toptan svn işlemi yapmak yerine birleştirme ihtiyacım oldu. birleştirme.

Biri burada bir kiraz turşusu yapabilir ve belirli taahhütler getirmeye izin verirken , bunun süreci karmaşıklaştırabilecek bazı dezavantajları vardır. Vişne toplamanız, seçtiğiniz işlemle ilgili bilgileri göstermez (bunu işlem mesajına ekleyebilirsiniz). Bu aslında tarihteki işleri takip etmeyi zorlaştırıyor.

Ayrıca, master'ı eski bir dalda etkin bir şekilde tekrar oynatmayacağınız - muhtemelen eksik olan özellikleri seçeceğiniz anlamına gelir - ve bu özellikler sıra dışı çalınabilir.

Biri gerektiğini anahtar nedeni birleştirme bayat dal üzerine usta tarihsel kaydedilmesini engellemek için muktedir, sen hakkında akıl edebileceği bir durumda bayat şube "gelecekteki tarih" diyoruz sağlar. Tarihçeden bayat dalına gelen birleşimleri ve işlevselliği yeniden bütünleştirmek için düzeltmeleri açıkça görebilirsiniz. Özellikler, master ile aynı sırada eklenmektedir. Ve işiniz bittiğinde ve nihayet efendinin başından eski şubeye birleşme yaptığınızda, her şeyin birleştiğini ve hiçbir taahhütte bulunmadığınızı biliyorsunuzdur.

Adım 1. Kod hakkında bilgi edinin, mimarisini ve en son ortak atadan bu yana her iki dalda da yapılan değişiklikleri analiz edin.

Adım 2. Eğer özellik tamamen bağımsız görünüyorsa ve temel olarak farklı kodlama alanlarına, birleştirme, uyuşmazlık düzeltme, test etme, düzeltme vb. Alanlarına dokunursa Bu mutlu yoldur, gitmeniz çok iyi. Aksi takdirde 3. Adıma gidin

Adım 3. Çatışma alanlarını analiz edin, fonksiyonel etki ve sebeplerini detaylı olarak anlayın. Burada ortaya çıkan iş gereksinimlerinde kolayca çatışmalar olabilir. BA'larla, uygun olan diğer aygıtlarla tartışın. Girişimi çözme ile ilgili karmaşıklığı hissedin.

Adım 4. Yukarıdakilerin ışığında, yalnızca çelişen parçaları ve yeniden yazmayı kesen parçaları birleştirmek / kiraz toplama / hatta kes-yapıştır yapıştırma yapıp yapmamaya karar verin, VEYA tüm özelliği sıfırdan tekrar yazıp yazmayacağınıza karar verin. .

1. Ana geliştirici / serbest bırakma dalı olarak kullanılan şubeye geçin.

Bu sistemdeki son değişiklikleri içeren daldır. Olabilir master, core, dev, bu şirkete bağlı. Senin durumunda muhtemelen masterdoğrudan.

git checkout master
git pull

Ana gelişme şubesinin en son sürümünün elinize geçtiğinden emin olmak için çekin.

2. Tamamlamanız gereken işi içeren şubeyi kontrol edin ve çekin.

Şubenin en son içeriğine gerçekten sahip olduğunuzdan emin olmak için çekin. Doğrudan kontrol ederek, önce yerel olarak oluşturmadan, içinde yeni içeriklerin master(veya sırasıyla ana dev dalında) bulunmamasını sağlarsınız.

git checkout <name of the obsolete branch>
git pull origin <name of the obsolete branch>

3. Ana gelişme kolunu eski şubeyle birleştirin.

Aşağıdaki komutu çalıştırmadan önce, yazarak git branchveya git statuseski dalda olduğunuzdan emin olun .

git merge master

git mergeKomut bu durumda, belirtilen şubesinden içeriğini birleştirmek için çalışacağız masterşu anda altındadır dalına.

Vurgu yapmaya çalışacağım . Yalnızca siz ve sizin tarafınızdan çözülmesi gereken birleştirme çatışmaları olabilir.

4. Birleştirme çatışmalarını düzeltin, çatışma düzeltmesini taahhüt edin ve itin

Birleştirme çatışmasını düzelttikten sonra, tüm dosyalarda bir araya gelip, çakışma çözümlemesine sahne, taahhüt ve itin origin.

git add .
git commit -m "fixed the merge conflict from the past year to update the branch"
git push

Genel olarak git add .tüm dosyaları işlenmek üzere hazırlamaya çağrı yapabilirsiniz . Birleştirme çakışmalarıyla uğraşırken, gerekli tüm dosyaların güncellenmesini istersiniz.

Ek not

Birleştirme ihtilafının çözülmesi sıkıcı bir iş olabilir. Özellikle de bir şirkette yeniyseniz. Bütün birleştirme çatışmalarını henüz çözecek doğru bilgiye bile sahip olamayabilirsiniz.

İşinize devam etmeden önce, ortaya çıkan tüm çatışmaları dikkatlice incelemek ve uygun şekilde düzeltmek için zaman ayırın.

Öyle olabilir, bir yıllık bir dalda çalışmaya başlarsınız, mevcut gelişme durumunu onunla birleştirirsiniz ve herhangi bir birleşme çatışması yaşamazsınız.

Bu, sistem yıl içinde çok fazla değişmiş olsa da, bir yaşındaki dalda gerçekte değiştirilen dosyalara kimse dokunmadı.