Git ile oynamaya başladım ve "yukarı akış" ve "aşağı akış" terimlerine rastladım. Bunları daha önce görmüştüm ama asla tam olarak anlamadım. Bu terimler SCM'ler ( Yazılım Yapılandırma Yönetimi araçları) ve kaynak kodu bağlamında ne anlama gelir ?

Kaynak kontrolü açısından, bir depodan kopyaladığınızda (klon, ödeme vb.) " Akış aşağı "sınız. Bilgi size "akış aşağı" olarak aktı.

Değişiklik yaptığınızda, genellikle onları " yukarı akış " olarak geri göndermek istersiniz, böylece aynı kaynaktan çeken herkes aynı değişikliklerle çalışır. Bu çoğunlukla, kaynak kontrolünün teknik bir gerekliliği yerine herkesin çalışmalarını nasıl koordine edebileceğinin sosyal bir sorunudur. Değişikliklerinizi ana projeye dahil etmek istiyorsunuz, böylece farklı geliştirme hatlarını takip etmiyorsunuz.

Bazen paket veya sürüm yöneticilerini (araç değil, insanlar) "yukarı akış" a değişiklik gönderme hakkında konuşacaksınız. Bu genellikle sistemleri için bir paket oluşturabilmeleri için orijinal kaynakları ayarlamaları gerektiği anlamına gelir. Bu değişiklikleri yapmaya devam etmek istemiyorlar, bu yüzden orijinal kaynağa "yukarı akış" gönderirlerse, bir sonraki sürümde aynı sorunla uğraşmak zorunda kalmamalıdırlar.

git tagMan sayfasında okuduğunuzda :

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

bu, mutlak bir yukarı akış repo veya aşağı akış repo olmadığı anlamına gelir . Bu kavramlar her zaman iki depo arasında görecelidir ve verinin akış şekline bağlıdır:

"YourRepo" o zaman uzak biri olarak "otherRepo" ilan etti :

• Eğer olan yukarı çekerek ( "yönünde yukarısında olan "otherRepo" "otherRepo" dan size" ve "alt baş olan için otherRepo").
• Eğer edilir akıntıya karşı iterek (bilgi artık geri nereye gittiğini "otherRepo", "yukarı" hala).

"Kimden" ve "için" not: sadece "aşağı akım" değil, "aşağı / aşağı ", dolayısıyla göreceli yönü.

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

• akış yukarı ne olduğunu biliyorsunuz (çektiğiniz veya ittiğiniz depolar)
• aşağı akıştan ne yapıldığını bilmiyorsunuz (diğer repolar repodan çekiliyor ya da repoya gidiyor ).

Temelde:

" Veri akışı " ile ilgili olarak repo, yukarı akış depolarından ("çekme") gelen ve yukarı (aynı veya diğer) yukarı akış depolarına ("itme") geri giden bir akışın altındadır ("aşağı akış") ).

İçeri resmini görebilirsiniz git-rebaseadam sayfasında "UPSTREAM Rebase GELEN KURTARMA" paragrafı ile:

Bu, bir rebase'in gerçekleştiği bir "yukarı akış" deposundan çektiğiniz anlamına gelir ve siz ("aşağı akış" repo) sonuca yapışırsınız (birçok yinelenen taahhüt, çünkü şube yukarı doğru yeniden dayandı, şube aynı şubenin taahhütlerini yeniden yarattı. yerel olarak).

Bu kötüdür, çünkü bir "yukarı akış" repo için, hepsi yinelenen taahhütlerle başa çıkma potansiyeline sahip olan birçok aşağı akış deposu (yani yukarı akış olandan, rezerve edilen dalla birlikte çekilen depolar) olabilir.

Yine, "veri akışı" benzetmesi ile, bir DVCS'de, bir "yukarı akış" kötü komutunun aşağı yönde bir " dalgalanma etkisi " olabilir.

Not: Bu verilerle sınırlı değildir. Git komutları ("porselen" olanlar gibi) genellikle dahili olarak diğer git komutlarını ("tesisat" olanlar) çağırdığı
için parametreler için de geçerlidir . Bkz. rev-parseSayfa :

Birçok git porselen komutları, bayrakların (bir tire ile başlayan parametreler ' -') ve git rev-listdahili olarak kullandıkları altta yatan komut için kullanılan parametreler ile aşağı yönde kullandıkları diğer komutlar için bayraklar ve parametreleringit rev-list karışımını alır . Bu komut aralarında ayrım yapmak için kullanılır.

Memba (ile ilgili olarak) İzleme

Akış yukarı terimi , özellikle izleme ile ilgili olarak , GIT araçları grubuna gelince bazı belirsiz anlamlara sahiptir.

Örneğin :

   $git rev-list --count --left-right "@{upstream}"...HEAD
   >4   12

geçerli yerel şubenizin arkasındaki (soldaki) ve öndeki (sağdaki) taahhüt edilenlerin sayısını, bu yerel şube için şu anda uzak olan şubeye göre ( varsa ) yazdırır (son önbelleğe alınan değeri) . Aksi takdirde bir hata mesajı yazdırır:

    >error: No upstream branch found for ''

• Daha önce de belirtildiği gibi, bir yerel depo için herhangi bir sayıda uzaktan kumandaya sahip olabilirsiniz, örneğin, bir depoyu github'dan çatalıyorsanız, bir 'çekme isteği' yayınlarsanız, kesinlikle en az iki origintanesine sahip olursunuz : github) ve upstream(çatallandığınız github deposu). Bunlar sadece değiştirilebilir isimlerdir, sadece 'git @ ...' url onları tanımlar.

Sizin .git/configokur:

   [remote "origin"]
       fetch = +refs/heads/*:refs/remotes/origin/*
       url = git@github.com:myusername/reponame.git
   [remote "upstream"]
       fetch = +refs/heads/*:refs/remotes/upstream/*
       url = git@github.com:authorname/reponame.git

• Öte yandan, @ {upstream} 'in GIT için anlamı benzersizdir:

öyle 'dal' (varsa) üzerinde 'uzaktan söyledi' izlendiğini, hangi 'Geçerli dalı' daki üzerinde 'Yerel depo' .

Herhangi bir argüman içermeyen bir düz git fetch/ yayınladığınızda getirdiğiniz / çektiğiniz daldır git pull.

Diyelim ki uzak şube başlangıç ​​noktasını / ana verilerini, kontrol ettiğiniz yerel ana şube için izleme dalı olacak şekilde ayarlamak istiyorsunuz. Sadece sorun:

   $ git branch --set-upstream  master origin/master
   > Branch master set up to track remote branch master from origin.

Bu, 2 parametre ekler .git/config:

   [branch "master"]
       remote = origin
       merge = refs/heads/master

şimdi deneyin ('yukarı akış' uzaktan kumandanın 'dev' dalı olması koşuluyla)

   $ git branch --set-upstream  master upstream/dev
   > Branch master set up to track remote branch dev from upstream.

.git/config şimdi okuyor:

   [branch "master"]
       remote = upstream
       merge = refs/heads/dev

git-push(1)Manuel Sayfa :

   -u
   --set-upstream

Güncel veya başarıyla itilen her dal için, bağımsız değişken git-pull (1) ve diğer komutlar tarafından kullanılan yukarı akış (izleme) başvurusunu ekleyin . Daha fazla bilgi için, bkz branch.<name>.merge. Git-config (1).

git-config(1)Manuel Sayfa :

   branch.<name>.merge

, Birlikte tanımlar branch.<name>.remote, üst dalda dal. Git getirme / git çekme / git rebase'e hangi dalın birleştirileceğini söyler ve git push'u da etkileyebilir (bkz. Push.default). \ (...)

   branch.<name>.remote

<Name> dalındayken git fetch ve git push komutlarına hangi uzaktan kumandadan / push komutuna aktarılacağını bildirir. Hiçbir uzaktan kumanda yapılandırılmamışsa varsayılan olarak başlangıç ​​konumuna gelir. orijin ayrıca herhangi bir dalda değilseniz kullanılır.

Memba ve İtme (Gotcha)

Manuel Sayfaya bir göz atıngit-config(1)

   git config --global push.default upstream
   git config --global push.default tracking  (deprecated)

Bu, henüz itmeye hazır olmadığınız dallara yanlışlıkla itilmeyi önlemek içindir.

Bu biraz resmi olmayan bir terminoloji.

Git söz konusu olduğunda, diğer her depo sadece bir uzaktır.

Genel olarak, yukarı akış klonlandığınız yerdir (köken). Downstream, çalışmanızı diğer çalışmalarla bütünleştiren herhangi bir projedir.

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

Örneğin, Ubuntu bir Debian türevidir, bu nedenle Debian Ubuntu için yukarı yönlüdür.

Yukarı Akım Zararlı Denilen

Ne yazık ki, buradaki diğer cevapların ulaşamadığı bir başka "yukarı akış" kullanımı, yani bir repodaki taahhütlerin ebeveyn-çocuk ilişkisine atıfta bulunmaktır. Pro Git kitabında Scott Chacon özellikle yatkındır ve sonuçlar talihsizdir. Bu konuşma tarzını taklit etmeyin.

Örneğin, bunun gerçekleşmesi için bir ileriye doğru birleştirme olduğunu söylüyor

birleştirdiğiniz şubenin işaret ettiği taahhüt, üzerinde çalıştığınız taahhüdün doğrudan yukarı akışıydı

B komitesinin, A komitesinin tek çocuğunun tek çocuğu olduğunu söylemek istiyor, bu yüzden B'yi A ile birleştirmek için ref A'yı B'yi taahhüt edecek şekilde hareket ettirmek yeterlidir. "aşağı akış" yerine "yukarı akış" olarak adlandırılmalıdır veya böyle saf bir düz çizgi grafiğinin geometrisinin neden "doğrudan yukarı akış" olarak tanımlanması gerektiği tamamen belirsiz ve muhtemelen keyfidir. (Adam sayfasıgit-merge , "şu anki şube başkanı, adlandırılan taahhüdün atasıdır" derken bu ilişkiyi açıklamaktan çok daha iyi bir iş çıkarır. Chacon'un söylemesi gereken şey budur.)

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

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

Temelde, zaman içinde taahhütlerin tarihine atıfta bulunurken "yukarı akış" ve "aşağı akış" ile ne demek istediğine dair net bir fikri yok gibi görünüyor. 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 ata olduğu açıkça görülmektedir; ve diğer yönde, komitelerin çocukları ve torunları vardır. Bu kabul edilen terminolojidir ve grafiğin yönünü açık bir şekilde açıklar, bu yüzden taahhütlerin bir repo'nun grafik geometrisi içinde birbirleriyle nasıl ilişkili olduğunu tanımlamak istediğinizde konuşmanın yolu budur. Bu durumda "yukarı akış" veya "aşağı akış" gevşek kullanmayın.

[Ek not: Yukarıda git-mergebahsettiğim ilk Chacon cümle ile man sayfası arasındaki ilişkiyi düşünüyordum ve bana göre ilkinin ikincisinin yanlış anlaşılmasına dayanabileceği ortaya çıkıyor. Man sayfası, "yukarı akış" kullanımının meşru olduğu bir durumu açıklamak için devam eder: "yukarı akış deposunu izlediğinizde, artık yerel değişiklik yapmadığınız ve şimdi daha yeni bir sürüme güncellemek istediğinizde hızlı ileri sarma genellikle gerçekleşir yukarı akış revizyonu. " Belki de Chacon "yukarı akış" kullandı çünkü onu burada man sayfasında gördü. Ancak el sayfasında uzak bir depo var; Chacon'un alıntılanan hızlı yönlendirme örneğinde uzak bir depo yok, sadece birkaç yerel olarak oluşturulan şube var.]

Genel olarak;

• yukarı akış kaynağa doğru
• akış aşağı lavaboya veya varış noktasına doğru

Bu, kaynak kontrol sistemleri de dahil olmak üzere tüm ağaç benzeri sistemler için geçerlidir.