Eş zamanlı olarak katkıda bulunmak ve yukarı havza deposundan uzaklaşmak için uygun görgü kuralları ve önerilen GitHub iş akışı nedir?

Genel olarak GitHub ve VCS'de yeniyim. Yıllardır çeşitli dillerde programlama yapıyorum, ancak her zaman özel projelerde yalnız çalıştım (halka açık değil). Geçenlerde GitHub'dan indirdiğim ve üzerinde çalıştığım bir projede jQuery UI widget'ini kullanmaya başladım. Repo artık orijinal yazar tarafından korunmuyor. Başka bir çatal, orijinal çekme taleplerinin bazılarını birleştirmiştir. Bu benim çatalladığım kişi.

Birkaç hata buldum ve onlar için düzeltmeler yaptım. Bu düzeltmelere katkıda bulunmak isterim, ancak kendi kullanımımız için mevcut özelliklerin bazılarını kıracak değişiklikler yapmak istediğim bir sürü değişiklik daha var. Artı, başka bir çataldan bir fikir eklemek istiyorum.

Hala GIT ve GitHub'u öğreniyorum ve her şeyi yapmanın en iyi yolunu bulmaya çalışıyorum. Farklı kavramlar / görevler hakkında birçok okuma yaptım (burada, SO, GitHub yardım sayfaları, Pro Git): iş akışları, birleştirme, çekme istekleri, kiraz toplama, yeniden doğuş, dallanma. Benim gri madde yüzüyor ve ben başlamak gerekir yapıyor ben daha iyi ne okudum anlayabilmeleri.

Ana konular:

1. Sanırım (bir yerde) bir dalda bir seferde yalnızca bir çekme talebinde bulunabileceğinizi düşünüyorum. Öyleyse bu, her bir hata için ayrı bir dal kullanmam gerektiği ve ardından her biri için ayrı bir çekme isteği yapmam gerektiği anlamına mı geliyor?

2. Boşluk sorunlarını temizlemek istiyorum ve bunu ayrı bir taahhütte yapmanın en iyisi olduğunu okuduğumu hatırlıyorum. Bunu ustamda mı yoksa ayrı bir dalda mı yapmalıyım? Bu kadar önemsiz bir şey için bir çekme isteği yapmak istemiyorum , ancak dallanmadan önce boşluk değişiklikleri yaparsam, bu hata düzeltmeleri için çekme isteğini etkiler mi? Bazı çatallar boşlukları temizledi ve bu farkı çokta kullanışsız hale getirdi.

3. Çatalımla ilgili sorunları daha önce düzeltmeme rağmen hataları belgelemenin bir yolu olarak düşünüyordum. Bu iyi bir fikir mi? Meseleyi, taahhüdü ve birleşimi ustalıkla bir araya getirme konusunda nasıl ilerlerim? Yukarı yönde bir çekme isteği yaparsam, sorunum yukarı doğru da görünecek mi veya bu belge bağlantısı kaybolacak mı? Yukarı havza deposuna karşı bir sorun açamıyorum (sorun sekmesi yok).

4. Kullanmak istediğim fikri için diğer çatal yazarına kredi vermenin en iyi yolu nedir? Kodunu tam olarak kullanamıyorum, özellikle de değişikliği yukarı akımın eski bir sürümüne uygulandığından ve diğer değişikliklerimle olduğu gibi uyumlu olmadığından. Ancak bu fikri kullanmak istiyorum ve kredinin geldiği yerde kredi vermek istiyorum. Benim taahhüt mesajımda sadece repo'suna (veya profiline veya özel taahhüdüne) mi bağlanmalıyım?

5. Benioku dosyasını ve ana dosyanın üstündeki DocBlock kodunu değiştirmeyle ilgili görgü kuralları nedir? Değişiklik yapmak, adımı eklemek, repoma ve demoma bağlantılar eklemek, orijinal demoya bağlantıları kaldırmak sorun değil mi (çatalım orijinalle uyumlu olmayacağından beri)? Tabii ki, asıl yazar adını ve lisans bilgilerini bırakacağım. Kayıt için MIT lisansı altında lisanslıdır.

Hiç VCS kullanmayan bir solo geliştirici olarak, tarihi yeniden yazmaya alışkınım . Ben mükemmeliyetçi ve düzgün ve düzenli olması gereken şeylerdenim. Kayıtlı tarih fikri beni biraz tedirgin ediyor ve ilk seferinde doğru yapmak istiyorum . Oynamak / öğrenmek için yeni bir repo oluşturdum, ancak jQuery UI widget'ini düzeltmeye devam etmekten endişe duyuyorum, böylece projeme devam edebiliyorum.

1. Doğru: çekme isteği, havuzunuzdaki bir şubeye bağlanır. Şubeyi değiştirirseniz, çekme isteği olarak gönderdiğiniz şeyi de değiştirirsiniz.

   Yani evet, hata düzeltme başına bir dal (ve çekme isteği) oluşturmak zorunda. Dinlenmeye devam etmeden önce bir kişiyle başlamak ve bakıcının buna nasıl tepki gösterdiğini görmek akıllıca olabilir. Açık kaynak, doğası gereği sosyal bir süreçtir.

2. Do sizin boşluk değişiklikler için çekme talepte! Bazen koruyucu olan biri olarak konuşurken, bu tür istekleri çok seviyorum: Onları onaylıyorum ya da istemiyorum ve işlem için çok az zaman alıyorlar.

   Aynı zamanda, karşılaşabileceğiniz şey, bakımcının boşluk değişikliklerinizle aynı fikirde olmamasıdır! Bu yüzden sakının..

3. Hmm .. Burada ne elde etmeye çalıştığınız belli değil. Aşırı belgeleme gibi geliyor ve bir fikir olarak iyi değil - belki bunu neden yapmak istediğinizi netleştirebilirsiniz?

4. Onay mesajınızdaki (hatta koddaki bir yorumda) repo'suna bağlantı vermek, kredi vermenin harika bir yoludur. Marka Onun için ona teşekkür olduğunu açık - Ancak dikkatli olun fikir ve değil onun kodu. Kodu kopyaladıysanız, kod için hangi lisansı kullandığı açıkça belli değilse, bu konuda ona e-posta gönderirim. Lisans açıktır (ve bir buysa farklı sen taahhüt gönderecekseniz deposundan lisans) o zaman çekme isteği mesajında söz de çekme isteği farklı lisans ekleyip gerekir.

5. Bu gerçekten iyi bir soru ve kiminle konuştuğuna bağlı olarak değişiyor. Benim düşüncem, isminizi asla yaptığınız herhangi bir taahhüt veya koda eklememelisiniz. Asıl sebep "kodun mülkiyeti ve sorumluluğu" anlamına gelmesidir - diğer kişilerin kodu değiştirmesini engelleyebilir çünkü "bu sizindir". Ama şimdi açık kaynağın doğası hakkında büyük bir tartışmaya giriyoruz, bu yüzden burada duracağım ve şunu söyleyeceğim - proje sahibine sorun ya da sadece bunu yap ve onun tepkisine ne olduğunu gör.

6. (Yerel, henüz yayınlanmadı) geçmişinizi GIT ile yeniden yazabilirsiniz! Git rebase komutunu öğrenin - bu gitmeyi sevmemizin temel nedenlerinden biri. Bu bir var gerçekten (örneğin github,) paylaşılan bir platforma (kuvvet) itme yeniden yazılmış kaydedilmesini / tarihine kötü bir fikir. Bu, daha sonra diğer geliştiricilerin sahip olduğu depoları mahvedecektir - onlar (yeniden yazılmış tarih) değişikliklerinizi çekerken zor şeyler yapmak zorunda kalacaklar.

[# 6: Teşekkürler @toxalot!]