Thực hành tốt nhất để theo dõi ngược dòng trong ngã ba trên github

Question

Tóm tắt: Các phương pháp hay nhất để xử lý theo dõi chạy dài của kho lưu trữ thượng nguồn nơi bạn muốn duy trì một tập hợp các thay đổi cục bộ là gì?

Tôi muốn giữ một ngã ba trên github được cập nhật với thượng lưu nhưng vẫn cho phép theo dõi rõ ràng các thay đổi duy nhất cho ngã ba. (Đối với cuộc thảo luận này, giả sử rằng upstream điểm đến kho dự án chính và origin đó đề cập đến ngã ba của tôi về kho)

Hãy tưởng tượng tôi có một cái gì đó như thế này, nơi tôi chia hai một kho lưu trữ khi thượng nguồn/master là tại E.

Upstream: 
A-B-C-D-E-F 


Fork:  
A-B-C-D-E ----- P ------T 
     \-L-M-/ \-Q-R-/ 

Sau khi giả mạo mặt nạ, tôi đã tạo hai nhánh tính năng (LM và QR) để thêm các tính năng mới mà tôi cần và hợp nhất chúng trở lại nguồn gốc/bản gốc của tôi. Vì vậy, bây giờ chi nhánh của tôi có những cải tiến không tồn tại ở thượng nguồn.

Tôi thấy rằng thượng nguồn có một số bản sửa lỗi thú vị nên tôi muốn trở lại đồng bộ với thượng nguồn. Dựa trên hầu hết các tài liệu tham khảo tôi đã tìm thấy (git hub fork), cách được khuyến nghị để thực hiện việc này là hợp nhất luồng/tổng thể vào nguồn gốc/chủ của bạn và tiếp tục trên con đường của bạn. Vì vậy, tôi sẽ ra lệnh như:

git checkout master 
git fetch upstream 
git git merge upstream/master 
git push 

Sau đó, tôi sẽ kết thúc với kho trông như thế này:

Upstream: 
A-B-C-D-E-F 


Fork:  
A-B-C-D-E ----- P ------T-F' 
     \-L-M-/ \-Q-R-/ 

Có một vài vấn đề tôi thấy với điều này mặc dù.

1. Tôi không thực sự có cam kết F trong repo của mình, tôi có F 'có nội dung giống nhau, nhưng hàm băm khác nhau. Vì vậy, tôi không thể dễ dàng tham khảo các cam kết giữa hai kho và biết rằng tôi có một sự thay đổi. (nó trở nên phức tạp hơn khi xem xét rằng thượng lưu có thể có nhiều hơn một thay đổi và có bộ chi nhánh riêng của nó được hợp nhất)

2. Khi tôi tiếp tục và tiếp tục làm điều này, ngày càng trở nên khó khăn cho tôi biết những gì thay đổi tôi có trong kho lưu trữ của tôi vượt ra ngoài những gì đang ở thượng nguồn. Ví dụ: tôi có thể gửi một số thay đổi này ngược dòng trong khi tiếp tục thêm các sàng lọc của riêng mình. Sau một vài lần lặp lại điều này, làm thế nào để bất cứ ai nhìn vào kho lưu trữ của tôi biết nó khác với luồng ngược dòng như thế nào? (có lệnh git để tìm những thay đổi này không?)

3. Tương tự như # 2, ai đó sẽ tìm thấy bản sửa lỗi ở phía trên và kiểm tra xem ngã ba của tôi có sửa chữa không?

Tôi đoán gốc của vấn đề là không có cách nào để đảm bảo rằng kho lưu trữ của tôi đang "đồng bộ" với thượng nguồn tại bất kỳ điểm nào vì mã và băm không giống nhau. Vì vậy, làm thế nào để tôi đi về việc theo dõi những thay đổi một cách chính xác và giữ cho bản thân mình khỏi bị điên rồ cố gắng giữ cho mọi thứ được đồng bộ?

Lưu ý: Tôi đã xem xét sử dụng rebase để tiếp tục rebasing kho lưu trữ của mình ở phía thượng nguồn, nhưng điều này có một tập hợp hoàn toàn các vấn đề khác. Ví dụ, nếu bất cứ ai tham chiếu đến kho lưu trữ của tôi thông qua các mô-đun con, nhánh, vv thì lịch sử viết lại sẽ phá vỡ các tham chiếu của chúng. Ngoài ra, tôi không nghĩ rằng lịch sử chi nhánh của tôi sẽ tồn tại trong quá trình rebase nên tôi sẽ không có cái nhìn toàn diện về tất cả các nhánh tính năng mà tôi đã tạo và lịch sử liên quan.

Những người khác xử lý việc này như thế nào? Một số phương pháp hay nhất mà tôi nên xem xét là gì?

---

Cập nhật:

Dựa trên thông tin phản hồi từ Seth, tôi tạo ra một tập hợp các kho thử nghiệm để hiển thị những gì tôi đã nói về và làm thế nào nó hoạt động ra cách ông nói.

Các kho là:

• upstream
• fork

Họ sẽ hiển thị rõ ràng hơn bao sáp nhập từ thượng nguồn trông khi có sự thay đổi địa phương là tốt.

Answer 1

Bạn không đúng trong giả định của mình. Bạn đã nói trong ví dụ văn bản của mình rằng bạn sẽ chạy lệnh git merge. Nếu bạn thực sự có ý nghĩa này, và không phải là git cherry-pick (và cho hồ sơ, git-merge là thực hành tốt nhất trong tình huống) thì bạn KHÔNG nhận được F` trong chi nhánh của bạn, bạn nhận được F. Có lẽ một hình ảnh:

Sau các lấy nhưng trước khi hợp nhất, các hợp đồng mua của bạn trông như thế này:

Upstream: 
A-B-C-D-E-F [master] 


Fork: /-F     [upstream/master] 
A-B-C-D-E ----- P ------T  [master] 
     \-L-M-/ \-Q-R-/  [Other branches] 

Sau khi sáp nhập, repo của bạn sẽ trông như thế này:

Fork: /-F-------------\ [upstream/master] 
A-B-C-D-E ----- P ------T-U [master] 
     \-L-M-/ \-Q-R-/  [Other branches] 

New cam kết "U" trong repo của bạn sẽ là một kết hợp cam kết, giống như cam kết "P" và "T".

git cherry-pick sẽ tạo "F" "như bạn đã chỉ ra trong ví dụ của mình. Đừng làm thế. git rebase đôi khi có thể hỗ trợ các chi nhánh rebasing git rebase -p nhưng không phải lúc nào cũng hoạt động. Ngoài ra, đó là viết lại lịch sử công cộng, đó là một ý tưởng tồi.

Tôi có tài liệu về các phương pháp hay nhất về git: Commit Often, Perfect Later, Publish Once Bạn có thể đặc biệt muốn điều tra phần luồng công việc để có thêm cảm hứng.