it-swarm-tr.com

"Downstream" ve "upstream" un tanımı

Git ile oynamaya başladım ve "yukarı akış" ve "aşağı akış" terimlerini karşıladım. Bunları daha önce görmüştüm, ancak tam olarak anlamadım. Bu terimler, SCM'ler ( Yazılım Konfigürasyon Yönetimi araçlar) ve kaynak kodu bağlamında ne anlama gelir?

812
brendan

Kaynak kontrolü açısından, bir havuzdan kopyaladığınızda (klonlama, ödeme vb.) " alt " konumtasınız. Bilgi size "akış aşağı" aktı.

Değişiklik yaptığınız zaman, genellikle onları " yukarı akış " geri göndermek istersiniz, bu yüzden aynı kaynaktan çeken herkesin aynı değişikliklerle çalışabilmesi için bu depoya gönderirler. Bu çoğunlukla, kaynak kontrolünün teknik bir gerekliliği yerine, herkesin çalışmalarını nasıl koordine edebileceğinin sosyal bir konusudur. Değişikliklerinizi ana projeye dahil etmek istersiniz, böylece farklı gelişim çizgilerini takip edemezsiniz.

Bazen "yukarı akış" değişiklikleri göndermekten bahseden paket veya yayın yöneticilerini (aracı değil insanları) okursunuz. Bu genellikle orijinal kaynakları ayarlamak zorunda kaldıkları için kendi sistemleri için bir paket oluşturabilecekleri anlamına gelir. Bu değişiklikleri yapmaya devam etmek istemiyorlar, bu yüzden orijinal kaynağa "yukarı doğru" gönderirlerse, bir sonraki sürümde aynı konuyla uğraşmak zorunda kalmamalılar.

630
brian d foy

Okuduğunuzda git tag man sayfası :

Git'in önemli bir yönü, dağıtılmış olmasıdır ve büyük ölçüde dağıtılmak, sistemde içsel "yukarı akış" veya "aşağı akış" olmadığı anlamına gelir.

, bu basitçe ,mutlakyukarı havza repo veya aşağı havza deposu olmadığı anlamına gelir.
Bu kavramlar her zaman iki depo arasında görecelidir ve verinin akış yoluna bağlıdır:

"yourRepo", "otherRepo" yu "uzak" olarak ilan ettiğinde,:

  • yukarı yöndeki"otherRepo" dan çekiyorsunuz ("otherRepo", "yukarı yöndeki siz" deniliyor ve siz de "aşağı yöndesiniz diğerRepo ") için.
  • yukarı/("ötekiRepo") hala yukarı doğru ilerliyor, bilginin geri döndüğü yer hala ".

"From" ve "for" notlarını not edin: sadece "downstream" değilsiniz, "downstream/ from/for";.


DVCS (Dağıtılmış Sürüm Kontrol Sistemi) bükümü: beyan ettiğiniz uzak depolara göre kendi deponuzun yanında gerçekte aşağı akışın ne olduğu hakkında hiçbir fikriniz yok.

  • giriş yönünün ne olduğunu biliyorsunuz (çekmekte olduğunuz veya bastırdığınız depolar)
  • aşağı akıştan ne yapıldığını bilmiyorsunuz (diğer depolardan çekerek veyadeponuzdan) itiliyor.

Temelde:

"veri akışı" teriminde, reponuz yukarı akış havuzundan gelen bir akışın altında ("aşağı akış") ("çekme ") 'den ve (aynı veya diğer) ters yöndeki repolara geri dönme (" Push ") .


git-rebase man page içinde "UPSTREAM REBASE'DEN KAYITLANMASI" paragrafında bir örnek görebilirsiniz:

Bunun anlamı, bir yeniden yapılanmanın gerçekleştiği bir "yukarı akış" deposunu çekiyorsunuzve siz ("aşağı akış" repo) sonuçla sıkışmışsınızdır (çünkü birçok yinelenen taahhüt, çünkü şube yeniden doğdu, yerel olarak sahip olduğunuz aynı şubenin taahhütlerini yeniden yarattınız).

Bu kötü, çünkü bir "yukarı akış" repo için, çokaşağı havza repoları olabilir (yani yukarı akıştan gelen repolar) (yeniden doğmuş şubeyle), hepsinin yinelenen taahhütlerle uğraşma potansiyeli var.

Yine, "veri akışı" benzetmesi ile birlikte, bir DVCS'de "yukarı akış" hatalı bir komutun "dalgalanma etkisi" aşağı akış olabilir.


Not: Bu verilerle sınırlı değildir.
Ayrıca, git komutları ("porselen" gibi) genellikle dahili olarak diğer git komutlarını ("tesisat" komutları) çağırdığı içinparametrelerine de uygulanır. Bakınız rev-parse man sayfası :

Pek çok git porselence komutunda bayrakların karışımı (yani, '-' ile başlayan bir parametre) ve altta yatan git rev-list komutu için kullanılan parametreler ile dahili olarak bayraklar ve parametreler kullanılır. git rev-list'nin akış aşağısında kullandıkları diğer komutlar. Bu komut, aralarında ayrım yapmak için kullanılır.

223
VonC

Bu biraz resmi olmayan bir terminoloji.

Git’e gelince, diğer tüm depolar sadece bir uzak.

Genel olarak konuşursak, memba klonladığınız yer (Köken). Aşağı akış, çalışmanızı diğer çalışmalarla bütünleştiren herhangi bir projedir.

Terimler Git depolarıyla sınırlı değildir.

Mesela, Ubuntu bir Debian türevidir, bu yüzden Debian Ubuntu için yukarı akışlıdır.

52
hasen

Memba Zararlı Denilen

Ne yazık ki, buradaki diğer cevapların alamadığı "yukarı akış" ın bir başka kullanımı, yani bir repo içindeki sözleşmelerin ebeveyn-çocuk ilişkisini ifade etmek için bir başka kullanım vardır. Scott Chacon Pro Git kitap buna özellikle yatkın ve sonuçları talihsiz. Bu konuşma biçimini taklit etmeyin.

Örneğin, bunun hızlı bir şekilde ortaya çıkması sonucu ortaya çıkan bir birleşme olduğunu söylüyor.

birleştirdiğiniz şubenin işaret ettiği taahhüt, doğrudan yaptığınız taahhüdün hemen başındaydı.

B'nin, A'nın tek çocuğunun ... tek çocuğunun tek çocuğu olduğunu, B'yi A ile birleştirmek için, ref A'yı B'nin yerine getirmesi için hareket ettirmenin yeterli olduğunu söylemek istiyor. Neden bu yöne "aşağı akış" yerine "yukarı akış" olarak adlandırılmalı ya da bu kadar saf bir düz çizgi grafiğin geometrisinin "doğrudan yukarı akış" olarak tanımlanması gerektiği, neden tamamen belirsiz ve muhtemelen keyfi olduğu belirtilmelidir. (git-merge için olan man sayfası, "mevcut şube başkanının adlandırılmış taahhüdün bir atası olduğunu" söylediğinde bu ilişkiyi açıklamak için çok daha iyi bir iş çıkarır. Bu, Chacon'un söylemesi gereken türden bir şeydir.)

Gerçekten de, Chacon'un kendisi "aşağı akış" ı daha sonra tamamen aynı şeyi söylemek için kullanıyor gibi görünmektedir, silinen bir taahhüdün tüm çocuk taahhütlerini yeniden yazmaktan bahsettiği zaman:

Bu dosyayı Git geçmişinizden tamamen kaldırmak için 6df76'dan sonraki tüm paketleri tekrar yazmalısınız.

Temel olarak, zaman içinde taahhüt tarihine atıfta bulunurken "yukarı havza" ve "aşağı havza" ile ne anlama geldiği konusunda net bir fikri yok gibi görünüyor. O zaman bu kullanım gayrı resmidir ve sadece kafa karıştırıcı olduğu için teşvik edilmemelidir.

Her bir taahhüdün (biri hariç) en az bir ebeveyni olduğu ve ebeveynlerin ebeveynlerinin ataları olduğu tamamen açıktır; ve diğer yönde, taahhütlerin çocukları ve torunları vardır. Bu, terminolojiyi kabul eder ve grafiğin yönlülüğünü açık bir şekilde tanımlar, bu nedenle, taahhütlerin bir repo grafik geometrisi içinde birbirleriyle nasıl ilişkili olduğunu açıklamak istediğinizde konuşmanın yolu budur. Bu durumda "yukarı doğru" veya "aşağı doğru" kullanmayın.

[Ek not: Yukarıda bahsettiğim ilk Chacon cümle ile git-merge man sayfası arasındaki ilişkiyi düşünüyordum, ve sanırım eskiden ikincisini yanlış anlamaya dayanıyor olabilir. Kılavuz sayfası, "yukarı akış" kullanımının yasal olduğu bir durumu açıklamaya devam ediyor: hızlı ileri sarma, "yukarı akış havuzunu izlerken, yerel değişiklik yapmadıysanız ve şimdi daha yeni bir güncellemek istediğinizde" hızlı ileri sarma oluyor giriş revizyonu. " Belki de Chacon "upstream" i kullandı, çünkü onu man sayfasında görmüştü. Ancak man sayfasında uzak bir havuz var; Chacon'un bahsettiği hızlı ileri sarma örneğinde uzak bir depo yok, sadece birkaç yerel olarak oluşturulmuş şube var.]

48
matt