Git’teki dersler: birleştirme / yeniden oluşturma

Git adı verilen dağıtılmış sürüm kontrol sistemi, CVS ve SVN gibi önceki sürüm kontrol sistemlerine kıyasla geliştiricilerin kod birleştirme ve dallanma düşünme biçimini değiştirdi.


Git ile bu işlemler nispeten kolay ve hızlı hale geldi. Bu sistem, geliştiricilerin ana daldan izole edilen yeni özellikler oluşturmasına ve özellik entegrasyona hazır olduğunda daha sonra entegre etmelerine olanak tanır.

Git konusunda yeniyseniz, aşağıdaki bağlantılar hızlı bir şekilde başlamanıza yardımcı olacaktır:

  • Git – Basit Kılavuz
  • Git Temel Bilgileri
  • Git Dallanma Temelleri
  • Başarılı Bir Git Dallanma Modeli

Git’te, değişiklikleri bir daldan diğerine entegre etmenin iki ana yolu vardır:

  1. birleştirmek
  2. rebase

-Ff seçeneği ve –no-ff seçeneği ile birleştirmeye bakacağız. Not: git –no-ff rebase komutu yoktur.

Hızlı Demo Kurulumu

Git birleştirmenin iki yoluna bakmadan önce, aşağıdaki komutlarla çalışan bir Git havuzu kuralım:

1
2
3
4
5
6
mkdir kodum

echo “foo bar baz” > BBKod / fan.txt

git init mycode

cd kodum

git foo.txt ekle

git commit -m “İleti gönder”

Şimdi “myfeature” adında yeni bir şube oluşturalım ve bu şubeye geçelim:

1git checkout -b myfeature

Şimdi yerel depomuzun “myfeature” kolundaki “foo.txt” dosyasında değişiklik yapabiliriz:

1
2
echo -e “foo bar baznquux” > fan.txt

git commit -a -m ‘özellik ekledi’

“Özellikim” değişikliğimizin tamamlandığını varsayalım ve şimdi bu özelliği “ana” şubemize entegre etmek istiyoruz.

Git grafiğimiz şöyle görünecektir:

1
2
3
   B özelliklerim

/

Usta

Git hakkında daha önce de belirtildiği gibi, bununla ilgili iki yolumuz var: ya birleştirme ya da bir rebase yapmak.

Nasıl kullanılır: git merge

Git birleştirme komutu iki veya daha fazla dalı birleştirir.

İlk olarak, birleşmeyi ana şubemize uygulayabilmemiz için “efendiye” geri dönelim.

1git ödeme yöneticisi

Şimdi birleştirmeyi yapabiliriz, ancak önce bir birleştirme oluşturmak için iki farklı yolu tartışalım.

Çoğunlukla mevcut şube başkanı, adlandırılan komutun (“özelliğim”) bir atasıdır. Bu en yaygın durumdur. Bu senaryoda, birleştirilmiş geçmişi depolamak için yeni bir taahhüt gerekli değildir. Bunun yerine, git HEAD (dizinle birlikte), fazladan birleştirme taahhüdü oluşturmadan adlandırılmış işleme işaret edecek şekilde güncelleştirilir.

Git birleştirmenin varsayılan davranışı, mümkünse hızlı ileri bir birleştirme yapmaktır. Bu varsayılan davranış -ff seçeneğiyle açık hale getirilebilir veya bu davranış hızlı ileri alma birleştirme (–no-ff) seçeneğiyle bastırılabilir. Ek açıklamalı bir etiketi birleştirirken Git, hızlı ileri birleştirme mümkün olsa bile her zaman bir birleştirme taahhüdü oluşturur.

–No-ff kullanırken, git geçmişini inceleyen biri üzerinde çalışmak için teslim aldığınız dalı açıkça görebilir. Ayrıca, –no-ff birleşmesinin sonunda nasıl fazladan birleştirme taahhüdü olduğunu unutmayın.

Aşağıda bir –no-ff ve -ff birleştirme arasındaki farkı gösteren bir resim bulunmaktadır..

git --no-ff rebase

Artık ikisinden birini kullanma seçeneğiniz var:

1git merge myfeature

Bu komuttan sonra git grafimiz şöyle görünecektir:

1A – B ustası

Veya şu şekilde şube geçmişini saklayabiliriz:

1git merge –no-ff özelliklerim

Bu son durumda, git grafiğimiz şu şekilde görünecektir:

1
2
3
  B özelliklerim

/

A – C ustası

Ve aşağıdaki git log komutunu çalıştırırsak:

1git log –graph –full-history –all –pretty = biçim: “% h% x09% d% x20% s”

Bu benzer bir git grafiği gösterecektir:

1
2
3
4
5
* 5368727 (HEAD, master) Şube ‘myfeature’ı birleştir

|

| * 6267227 (özelliklerim) özelliklerim eklendi

| /

* ac54e38 İşlem mesajı

Hangi birleştirme türünü tercih edeceğiniz, birleştirme yaparken şube bilgilerinin ne kadarını depolamak istediğinize bağlıdır.

Nasıl kullanılır: git rebase

Değişiklikleri bir daldan diğerine entegre etmenin ikinci yolu git rebase yapmaktır.

Birleştirme, her bir taahhüt geçmişinin grafiğini korurken iki dalı bir araya getirdiğinde, yeniden baslatma, kaynak daldaki değişiklikleri yeniden yazarak dalları birleştirerek hedef dalın alt öğesi olarak görünürler..

Git rebase iletme bağlantı noktaları yerel, güncellenmiş yukarı akış kafasına geçer. Yeniden pazarlama, bir şubenin yeni bir temel taahhüdüne taşınması sürecidir.

Git grafiğinde böyle görünüyor. Aşağıdaki geçmişin var olduğunu ve mevcut dalın “özelliğim” olduğunu varsayın:

1
2
3
      A – B – C Instagram Hesabındaki Resim ve Videoları myfeature

/

D – E – F – G ustası

Ve şimdi yaparsak:

1git rebase ustası

Sonuç:

1
2
3
        A‘ – B’ – C ’özellikleri

/

D — E — F — G master

“Ana” dal artık birleştirme taahhüdü oluşturmadan “G” işlemindeki “myfeature” şube değişikliklerini içeriyor. Bu nedenle, şubeleri birleştirme taahhüdü ile birleştirmek yerine, yeniden temellendirme “myfeature” dalını ustanın üstüne inşa ederek bütünleştirir. Sonuç, geliştiriciler için anlaşılması daha kolay olabilen doğrusal bir tarihtir. Git günlüğü artık “D — E — F — G master” ın doğrusal geçmişini gösterecektir.

Çatışma durumunda, git rebase ilk sorunlu işlemde duracak ve çatışma işaretlerini ağaçta bırakacak.

Birleştir veya Yeniden Oluştur?

Her iki kod entegrasyonu yöntemi de en uygun olduklarında kullanılmalıdır. Belirli bir yöntemin ne zaman kullanılması gerektiği konusunda farklı görüşler vardır..

Bir yöntemin diğerine tercih edilebileceği durumları açıklayan bazı bağlantılar şunlardır:

  • birleştirme veya yeniden pazarlama?
  • Ne Zaman Birleştirilir ve Ne Zaman Yeniden Düzenlenir
  • Git Team Workflows: birleştirme veya yeniden pazarlama?
Jeffrey Wilson Administrator
Sorry! The Author has not filled his profile.
follow me
    Adblock
    detector