Kod incelendikten sonra bir çekme isteğini güncellemek için tercih edilen Github iş akışı

Github'daki Açık Kaynak projesinde bir değişiklik gönderdim ve çekirdek ekip üyelerinden birinden kod inceleme yorumları aldım.

İnceleme yorumlarını dikkate alarak kodu güncellemek ve yeniden göndermek istiyorum. Bunu yapmak için en iyi iş akışı nedir? Git / github hakkındaki sınırlı bilgimden, aşağıdakilerden herhangi birini yapabilirim:

1. Kodu yeni bir taahhüt olarak güncelleyin ve hem ilk hem de güncellenmiş taahhüdü çekme isteğime ekleyin.

2. Her nasılsa (??) eski taahhüdü depomdan geri alır ve her şeyi içeren yeni bir taahhüt oluşturur, sonra bunun için bir çekme isteği oluşturur mu?

3. git commitbir değişiklik özelliği var, ancak taahhüdü yerel deponuzun dışına ittikten sonra kullanmamanız gerektiğini duydum? Bu durumda yerel bilgisayarımda değişiklik yaptım ve projenin github şubesine ittim. Bu 'değişiklik' kullanmakta sorun olmaz mı?

4. Başka bir şey?

Açık kaynak projesinin tarihlerinde her şeyi uygulayacak tek bir taahhüdü olacağı için seçenek 2/3 iyi olurdu, ancak bunu nasıl yapacağımdan emin değilim.

Not: Bunun cevabı etkileyip etkilemediğini bilmiyorum, ama ayrı bir dalda değişiklikler yapmadım, sadece ustanın üstüne bir taahhütte bulundum

Sadece çekme isteğinde kullanılan şubeye yeni bir taahhüt ekleyin ve dalı GitHub'a itin. Çekme isteği ek taahhütle otomatik olarak güncellenecektir.

# 2 ve # 3 gereksizdir. İnsanlar yalnızca şubenizin nerede birleştirildiğini (ve ek taahhütleri değil) görmek isterse, yalnızca git log --first-parentgünlükteki birleştirme taahhüdünü görüntülemek için kullanabilirler .

Bir çekme isteğini güncellemek için

Bir çekme isteğini (nokta # 1) güncellemek için yapmanız gereken tek şey, çekme isteğinin geldiği şubeyi satın almak ve tekrar iletmektir:

cd /my/fork
git checkout master
...
git commit -va -m "Correcting for PR comments"
git push

İsteğe bağlı - Temizleme taahhüdü geçmişi

Depo geçmişinizin temiz olması için taahhütlerinizi birlikte ezmeniz istenebilir veya kendiniz çekme isteğinizdeki (mesaj # 2) "mesajdan" uzaklaşan aracı komisyonları kaldırmak isteyebilirsiniz. Örneğin, taahhüt geçmişiniz aşağıdaki gibi görünüyorsa:

$ git remote add parent git@github.com:other-user/project.git
$ git fetch parent
$ git log --oneline parent/master..master
e4e32b8 add test case as per PR comments
eccaa56 code standard fixes as per PR comments
fb30112 correct typos and fatal error
58ae094 fixing problem

Bir şeyleri birlikte ezmek iyi bir fikirdir, böylece tek bir taahhüt olarak görünürler:

$ git rebase -i parent/master 

Bu, çekme isteğinizin geçmişini nasıl yeniden yazacağınızı seçmenizi isteyecektir, aşağıdakiler düzenleyicinizde olacaktır:

pick 58ae094 fixing actual problem
pick fb30112 correct typos
pick eccaa56 code standard fixes
pick e4e32b8 add test case as per PR comments

Bir önceki taahhüdün parçası olmak istediğiniz herhangi bir taahhüt için - squash seçimini değiştirin:

pick 58ae094 fixing actual problem
squash fb30112 correct typos
squash eccaa56 code standard fixes
squash e4e32b8 add test case as per PR comments

Ve editörünüzü kapatın. Git daha sonra geçmişi yeniden yazacak ve birleştirilmiş işlem için bir taahhüt mesajı vermenizi isteyecektir. Buna göre değişiklik yapın ve taahhüt geçmişiniz artık kısa ve öz olacaktır:

$ git log --oneline parent/master..master
9de3202 fixing actual problem

Çatalı it:

$ git push -f
Counting objects: 19, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (5/5), done.
Writing objects: 100% (11/11), 978 bytes, done.
Total 11 (delta 9), reused 7 (delta 6)
To git@github.com:me/my-fork.git
   f1238d0..9de3202  HEAD -> master

ve çekme isteğiniz, daha önce birkaç taahhüde bölünmüş tüm değişiklikleri içeren tek bir taahhüt içerecektir.

Herkese açık depolardaki geçmişi değiştirmek kötü bir şeydir

Geçmişi yeniden yazmak ve git push -fbir başkasının zaten klonladığı bir dalda kullanmak kötü bir şeydir - havuzun geçmişinin ve kasanın geçmişinin ayrılmasına neden olur.

Bununla birlikte, bir depoya entegre edilmesini önerdiğiniz değişikliği düzeltmek için çatalınızın geçmişini değiştirmek iyi bir şeydir. Gibi hiçbir istekleri çekme istekleri ezmek "gürültü" var.

Dallarla ilgili not

Yukarıda çekme talebinizi masterçatalın kolundan gelmiş gibi gösteriyorum , bununla ilgili yanlış bir şey yok, ancak bu, standart tekniğinizse, depo başına sadece bir PR'nin açık olması gibi bazı sınırlamalar yaratıyor . Teklif etmek istediğiniz her bir değişiklik için bir şube oluşturmak daha iyi bir fikirdir:

$ git branch feature/new-widgets
$ git checkout feature/new-widgets
...
Hack hack hack
...
$ git push
# Now create PR from feature/new-widgets