GitHub'da Forking ve Branching

Github projesinin bir şubesini oluşturmaya karşı bir github projesinin çatallanmasının avantajları ve dezavantajları hakkında daha fazla bilgi edinmek istiyorum.

Forking, projemin versiyonunu orijinalinden daha izole ediyor, çünkü orijinal projenin ortak çalışanlar listesinde olmam gerekmiyor. Evde bir proje geliştirdiğimizden, insanları ortak çalışan olarak eklemede sorun yok. Ancak, bir projeyi çatallamanın ana projede birleştirme değişikliklerini daha zor hale getirip getirmeyeceğini anlamak istiyoruz. Yani, dallanmanın iki projenin senkronizasyonda tutulmasını kolaylaştıracağını merak ediyorum. Başka bir deyişle, ana projemin sürümü ile ana proje arasındaki dalı birleştirdiğimde değişiklikleri birleştirmek ve zorlamak daha mı kolay?

Belirli bir proje için ortak çalışan olarak kayıtlı olmadığınız için her zaman bir şube oluşturamaz veya mevcut bir dalı çekemez ve geri alamazsınız.

Forking, GitHub sunucu tarafındaki bir klondan başka bir şey değildir :

• doğrudan geri itme imkanı olmadan
• ile çatal kuyruk özelliği birleştirme isteğini yönetmek eklendi

Çatalı orijinal proje ile senkronize halde tutarsınız:

• orijinal projeyi uzaktan kumanda olarak ekleme
• o orijinal projeden düzenli olarak getiriliyor
• mevcut gelişiminizi bu getiriden güncellediğiniz ilgi alanına ekleyin.

Rebase, değişikliklerinizin basit olduğundan emin olmanızı sağlar (işlemek için birleştirme çatışması yoktur), orijinal projenin koruyucusunun projesine yamalarınızı eklemesini istediğinizde çekme isteğinizi daha kolay hale getirir.

Amaç, doğrudan katılım her zaman mümkün olmasa da işbirliğine izin vermektir.

GitHub tarafında klonlamanız, artık iki "merkezi" deponuz olduğu anlamına gelir (birkaç ortak çalışandan görülebilen "merkezi" olarak ").
Bunları doğrudan bir proje için ortak çalışan olarak ekleyebiliyorsanız , başka bir yönetimi yönetmenize gerek yoktur biri çatalla.

Birleştirme deneyimi yaklaşık olarak aynı olurdu, ancak ekstra bir dolaylama seviyesiyle (önce çatalı itin, ardından orijinal repodaki evrimleşme riski ile birlikte hızlı ileri birleştirme işlemlerinizi artık hızlı ileri gitmeyin) .
Bu, doğru iş akışının git pull --rebase upstream(çalışmalarınızı yukarı akıştan yeni taahhütlerin üzerine yeniden tabanlaştırmak) ve daha sonra git push --force origin, geçmişi kendi taahhütlerinizin her zaman orijinal (yukarı akış) repodaki taahhütlerin üstünde olacağı şekilde yeniden yazmak için olduğu anlamına gelir. .

Ayrıca bakınız:

• Git çatal git klon mu?
• Orijinal Github veri havuzundan yeni güncellemeleri çatallı Github veri havuzuna çekin

İşte üst düzey farklılıklar:

Çatallanan

Artıları

• Dalları kullanıcı tarafından ayrılmış tutar
• Birincil depodaki dağınıklığı azaltır
• Takım süreciniz dış katkıda bulunan süreci yansıtır

Eksileri

• Aktif (veya aktif olmayan, bu konuda) tüm şubeleri görmeyi zorlaştırır
• Bir dalda işbirliği yapmak daha zordur (çatal sahibinin kişiyi ortak çalışan olarak eklemesi gerekir)
• Git'te birden çok uzaktan kumanda kavramını anlamanız gerekiyor
  • Ek zihinsel defter tutma gerektirir
  • Bu, Git ile süper rahat olmayan insanlar için iş akışını zorlaştıracak

Dallanma

Artıları

• Bir proje çevresinde yapılan tüm işleri tek bir yerde tutar
• Tüm ortak çalışanlar, ortak çalışmak için aynı şubeye başvurabilir
• Başa çıkacak tek bir Git kumandası var

Eksileri

• Terk edilen şubeler daha kolay birikebilir
• Takım katkı süreciniz harici katkıda bulunan süreciyle eşleşmiyor
• Ekip üyelerini şubeye katılmadan önce katkıda bulunan olarak eklemeniz gerekir

Git'in genel iş akışı ile ilgilidir. Doğrudan ana projenin deposuna aktarma olasılığınız düşüktür. GitHub projesinin havuzunun şube tabanlı erişim kontrolünü destekleyip desteklemediğinden emin değilim, örneğin kimseye ana şubeye gönderme izni vermek istemezsiniz.

Genel örüntü aşağıdaki gibidir:

• Özgün projenin deposunu, daha sonra değişiklikleri göndermenize izin verilecek olan kendi GitHub kopyanıza sahip olacak şekilde çatallayın.
• GitHub veri havuzunuzu yerel makinenize kopyalayın
• İsteğe bağlı olarak, orijinal deponuzu yerel deponuza ek bir uzak havuz olarak ekleyin. Daha sonra, bu depoda yayınlanan değişiklikleri doğrudan alabilirsiniz.
• Değişikliklerinizi ve kendi taahhütlerinizi yerel olarak yapın.
• Değişikliklerinizi GitHub veri havuzunuzda aktarın (genellikle projenin veri havuzunda yazma izinlerine sahip olmadığınız için).
• Projenin yöneticileriyle iletişime geçin ve değişikliklerinizi almasını ve gözden geçirmesini / birleştirmesini isteyin ve projenin deposuna geri dönmelerine izin verin (siz ve isterseniz).

Bu olmadan, kamu projelerinin herkesin kendi taahhütlerini doğrudan itmesine izin vermek oldukça sıra dışı.

Forking, mevcut depodan tamamen yeni bir havuz oluşturur (sadece gitHub / bitbucket'te git clone yapmak)

Çatallar en iyi şekilde kullanılır: 'bölmenin' amacı, asla ebeveyni ile bir araya gelemeyecek mantıksal olarak bağımsız bir proje oluşturmaktır.

Şube stratejisi mevcut / çalışan depo üzerinde yeni bir şube oluşturur

Dallar en iyi şekilde kullanılır: bir özellik boyunca çalışmak için geçici yerler olarak oluşturulduklarında, dalı başlangıç ​​noktasıyla birleştirmek amacıyla.

Daha Spesifik: - Açık kaynaklı projelerde, depoya kimlerin itebileceğine karar veren havuzun sahibidir. Ancak, açık kaynak fikri herkesin projeye katkıda bulunabileceğidir.

Bu sorun çatallarla çözülür: bir geliştirici açık kaynaklı bir projede bir şeyi değiştirmek istediğinde, resmi depoyu doğrudan klonlamaz. Bunun yerine, bir kopya oluşturmak için çatallar. İş bittiğinde, deponun sahibinin değişiklikleri gözden geçirebilmesi ve bunları projesiyle birleştirip birleştirmeyeceğine karar verebilmesi için bir çekme isteği yaparlar.

Çekirdek çatal özelliği dallanma özelliklerine benzer, ancak dallar oluşturmak yerine depodan bir çatal yapılır ve bir birleştirme isteği yerine bir çekme isteği yaratırsınız.

Aşağıdaki linkler farkı iyi açıklanmış bir şekilde sunmaktadır:

https://blog.gitprime.com/the-definitive-guide-to-forks-and-branches-in-git/

https://buddy.works/blog/5-types-of-git-workflows

http://www.continuousagile.com/unblock/branching.html