- Amaç, en basit git işbirliği aracını oluşturmak
- Dış işbirlikçilerin zamanını ve enerjisini harcamadan, kendi kendine barındırılan bir git sunucusunu çalıştırmayı bir SSH sunucusu çalıştırmak kadar basit hale getirmek
- E-posta listesi ile pull request iş akışını birleştiriyor
- Yama üretmek kadar basit ama pull request'in kullanım kolaylığına sahip bir işbirliği aracı yapmayı hedefliyor
- Başka bir kod deposu oluşturmak değil, dış katkıcılarla işbirliği yapılabilen son derece basit, kendi kendine barındırılan bir git çözümü oluşturmak istiyor
Gerekenler
- Kod sahibinin git sunucusunu çalıştırmak için ihtiyaç duyduğu şeyler:
- Tek bir Golang ikili dosyası
- Dış katkıcılar için gerekenler:
- SSH anahtar çifti
- SSH istemcisi
Mevcut sorunlar
- E-posta, bir git deposuna yönelik değişiklikleri (yama setleri) gönderip almak için dağıtık bir sistem olarak harika olsa da, yeni kullanıcıları e-posta listesine dahil etmek, e-posta istemcisini düzgün biçimde yapılandırmak ve ardından kod katkısı göndermek; birçok geliştiricinin bu noktada vazgeçmesine yol açıyor
- İşbirliği e-posta protokolü üzerinden yapıldığı için özellik seti sınırlı. Örneğin e-postalar düzenlenemiyor, herkes farklı bir istemci kullanıyor ve bu istemcilerin düz metin e-posta ile yama indirme konusunda birbirinden farklı kısıtları var
- Github pull request'leri kullanmak, düzenlemek ve yönetmek kolay; ancak kullanıcıların kod incelemesi yapabilmek için Github web sitesi içinde kalması gerekiyor
- Hızlı değişiklikler için iyi, ancak kodu web tarayıcısı içinde okumaya başladığınızda önemli dezavantajlar ortaya çıkıyor. Bir noktadan sonra kodu yerel geliştirme ortamında ya da IDE içinde incelemek daha anlamlı hale geliyor
- IDE içinde PR incelemeyi sağlayan araçlar ve eklentiler var, ancak bunları kullanılabilir hale getirmek büyük çaba gerektiriyor
- Ayrıca pull request'i taklit eden kendi kendine barındırılan çözümler, bunları yönetmek için çok fazla altyapı gerektiriyor: veritabanı, git'e bağlı bir web sitesi, yönetici idaresi, servisler vb.
- Bir diğer büyük sürtünme noktası da dış kullanıcıların kod değişikliklerini göndermeden önce önce hesap oluşturup giriş yapmak zorunda olması. Bu, hem dış katkıcılar hem de altyapıyı sağlamak zorunda olan kod sahipleri için ciddi bir ek yük getiriyor
- Çoğu zaman PR göndermeden önce depo içinde bir fork oluşturmak gerekiyor. Sonra da çoğu kişi bir daha katkı yapmamasına rağmen çatallanmış depo sonsuza kadar orada kalıyor. Bu saçma görünüyor
Patch Request (PR) tanıtımı
- E-posta kurulumunun zahmeti ya da e-posta protokolünün dayattığı sınırlamalar olmadan yamaları gönderip alabileceğiniz, kendi kendine barındırılan bir git "sunucusu" yapmak istiyor
- Ayrıca ana iş akışının yerel geliştirme ortamı etrafında dönmesini istiyor. Github, iş akışını desteklemek için IDE'yi tarayıcıya getiriyor; biz ise bu fikri tersine çevirip kod incelemeyi yerel geliştirme ortamı içinde birinci sınıf bir deneyim haline getirmek istiyoruz
- Bunu, Github'un pull request iş akışı ile e-posta üzerinden yama gönderip alma arasında bir yerde konumlandırıyor
- Temel fikir, katkıcılar ile proje sahipleri arasındaki etkileşimin çoğunu yönetmek için SSH uygulamasından yararlanmak. Her şey terminal içinde ergonomik ve tam işlevli şekilde yapılabiliyor
- Bildirimler RSS ile yapılıyor ve tüm durum değişiklikleri statik web varlıklarının oluşturulmasına yol açıyor; böylece her şey basit bir dosya web sunucusu kullanılarak barındırılabiliyor
format-patch iş akışı
- Buradaki temel işbirliği aracı format-patch
- İster kod değişikliği gönderiyor olun ister kod değişikliğini inceliyor olun, her şey kodun içinde gerçekleşiyor
- Hem katkıcı hem de sahip yeni commit'ler oluşturuyor ve birbirlerinin üzerine yamalar üretiyor
- Böylece incelemecinin bir kod bloğunun tek satırına "yorum" bırakabildiği bir web görüntüleyicisine ihtiyaç kalmıyor. Buna gerek yok. Katkıcının yamasını uygulayın, yorumlarınızı ya da kod değişikliklerinizi yazın, yeni bir yama oluşturun ve yamayı "inceleme" olarak git sunucusuna gönderin
- Bu akış, iki kullanıcının bir dizi değişiklik üzerinde işbirliği yapması durumunda da tamamen aynı şekilde çalışıyor
- Aynı kod değişikliği için birden fazla yama seti gönderilmesi sorununu da çözüyor. Tüm değişikliklerin ve işbirliğinin gerçekleştiği tek bir merkezi Patch Request var
- İnceleme/yorumları git note ile kullanmanın bir yolu bulunabilir; ancak açıkçası bu çözüm kaba duruyor ve çoğu git kullanıcısının konfor alanının dışında kalıyor
- İncelemeleri kod olarak göndermeniz ve kullandığınız programlama diliyle kodun içine yorum yazmanız yeterli
- Bu yorumları "işlemek" ve sonraki yamalarda kaldırmak katkıcının işi
- Tüm yorumların ele alınmasını zorunlu kılan özellik: kodda işlenmemiş yorumlar varsa yama birleştirilmiyor. Bunlar görmezden gelinemiyor; aksi halde yanlış şekilde upstream'e gidebilir
Patch Request nasıl çalışır
- Patch Request (PR), bir git deposuna yönelik değişiklikleri göndermenin, incelemenin ve kabul etmenin en basit yolu. İşleyişi şöyle:
- Dış katkıcı depoyu klonlar (
git-clone)
- Dış katkıcı kod değişikliklerini yapar (
git-add & git-commit)
- Dış katkıcı yamayı oluşturur (
git-format-patch)
- Dış katkıcı PR'ı SSH sunucusuna gönderir
- Sahip, yeni PR için RSS bildirimi alır
- Sahip, yamayı SSH sunucusundan yerel olarak uygular (
git-am)
- Sahip, koda önerilerini yazar (
git-add & git-commit)
- Sahip, incelemeyi göndermek için yamayı SSH sunucusuna pipe eder (
git-format-patch)
- Dış katkıcı, PR incelemesi için RSS bildirimi alır
- Dış katkıcı yamayı yeniden uygular (
git-am)
- Dış katkıcı koddaki yorumları inceler ve kaldırır
- Dış katkıcı başka bir yama gönderir (
git-format-patch)
- Sahip, yamayı yerel olarak uygular (
git-am)
- Sahip, PR'ı onaylandı olarak işaretler ve kodu
main dalına gönderir (git-push)
1 yorum
Pico.sh - SSH kullanarak her şeyi web servisi olarak yöneten açık kaynak araçlar koleksiyonu içine yeni eklenenlerden biri gibi görünüyor.
Daha önce şunlar da yer alıyordu.