Nghi thức đúng đắn và quy trình công việc GitHub được đề xuất để đồng thời đóng góp và chuyển hướng từ repo ngược dòng là gì?


21

Tôi mới biết đến GitHub và VCS nói chung. Tôi đã lập trình bằng nhiều ngôn ngữ trong nhiều năm, nhưng tôi luôn làm việc một mình trong các dự án tùy chỉnh (không phát hành công khai). Gần đây tôi đã bắt đầu sử dụng tiện ích UI jQuery mà tôi đã tải xuống từ GitHub trong một dự án tôi đang thực hiện. Các repo không còn được duy trì bởi tác giả ban đầu. Một ngã ba khác đã kết hợp một số yêu cầu kéo ban đầu. Đây là một trong những tôi rẽ nhánh.

Tôi tìm thấy một vài lỗi và đã đưa ra các bản sửa lỗi cho chúng. Tôi muốn đóng góp các bản sửa lỗi này, nhưng tôi cũng có rất nhiều thay đổi khác mà tôi muốn thực hiện, để sử dụng riêng, điều đó sẽ phá vỡ một số tính năng hiện có. Thêm vào đó, tôi muốn kết hợp một ý tưởng từ một ngã ba khác.

Tôi vẫn đang học GIT và GitHub và tôi đang cố gắng tìm ra cách tốt nhất để giải quyết mọi thứ. Tôi đã đọc rất nhiều (ở đây, các trang trợ giúp SO, GitHub, Pro Git) về các khái niệm / nhiệm vụ khác nhau: quy trình làm việc, hợp nhất, yêu cầu kéo, chọn anh đào, phân nhánh, phân nhánh. Chất xám của tôi đang bơi và tôi cần bắt đầu làm để tôi có thể hiểu rõ hơn những gì tôi đã đọc.

Các vấn đề chính:

  1. Tôi nghĩ rằng tôi đã đọc (ở đâu đó) rằng bạn chỉ có thể có một yêu cầu kéo trên một chi nhánh tại một thời điểm. Vì vậy, điều đó có nghĩa là tôi nên có một nhánh riêng cho từng lỗi và sau đó thực hiện một yêu cầu kéo riêng cho từng lỗi?

  2. Tôi muốn dọn dẹp các vấn đề về khoảng trắng và dường như tôi nhớ rằng đọc rằng tốt nhất nên làm điều này trong một cam kết riêng. Tôi nên làm điều này trong chủ của tôi hoặc một chi nhánh riêng biệt? Tôi không muốn thực hiện một yêu cầu kéo cho một cái gì đó quá tầm thường , nhưng nếu tôi thực hiện thay đổi khoảng trắng trước khi phân nhánh, điều đó có ảnh hưởng đến yêu cầu kéo để sửa lỗi không? Một số dĩa đã làm sạch khoảng trắng và nó thực sự làm cho diff khá vô dụng.

  3. Tôi đã nghĩ đến việc tạo ra các vấn đề chống lại ngã ba của mình như một cách ghi lại các lỗi mặc dù tôi đã có cách khắc phục chúng. Đó có phải là một ý tưởng tốt? Làm cách nào để liên kết với nhau về vấn đề, cam kết và hợp nhất với chủ? Nếu tôi thực hiện yêu cầu kéo ngược dòng, vấn đề của tôi cũng sẽ xuất hiện ngược dòng hay liên kết tài liệu đó sẽ bị mất? Tôi không thể mở một vấn đề chống lại repo ngược dòng (không có tab vấn đề).

  4. Cách tốt nhất để cung cấp tín dụng cho tác giả ngã ba khác cho ý tưởng của mình mà tôi muốn sử dụng là gì? Tôi không thể sử dụng mã của anh ấy một cách chính xác, đặc biệt vì thay đổi của anh ấy được áp dụng cho phiên bản cũ hơn của dòng ngược và không tương thích với các thay đổi khác của tôi. Nhưng tôi muốn sử dụng ý tưởng và tôi muốn cung cấp tín dụng khi tín dụng đáo hạn. Tôi có nên liên kết với repo của anh ấy (hoặc hồ sơ hoặc cam kết cụ thể) trong tin nhắn cam kết của mình không?

  5. Các nghi thức liên quan đến việc thay đổi tệp readme và DocBlock ở đầu tệp chính là gì? Có thể thay đổi, thêm tên của tôi, thêm liên kết vào repo và bản demo của tôi, xóa liên kết đến bản demo gốc (vì ngã ba của tôi cuối cùng sẽ không tương thích với bản gốc)? Tất nhiên, tôi sẽ để lại tên tác giả và thông tin giấy phép ban đầu. Đối với hồ sơ, nó được cấp phép theo giấy phép MIT.

Là một nhà phát triển solo chưa bao giờ sử dụng VCS, tôi đã quen với việc viết lại lịch sử . Tôi là người cầu toàn và thích mọi thứ phải gọn gàng và ngăn nắp. Ý tưởng về lịch sử được ghi lại đang khiến tôi hơi lo lắng và tôi muốn thực hiện nó ngay lần đầu tiên . Tôi đã tạo một repo mới để chơi / tìm hiểu, nhưng tôi rất lo lắng khi bắt đầu sửa chữa tiện ích UI UI để tôi có thể tiếp tục với dự án của mình.

Câu trả lời:


15
  1. Đúng: một yêu cầu kéo được liên kết với một nhánh trong kho lưu trữ của bạn. Nếu bạn sửa đổi chi nhánh, thì bạn cũng sửa đổi những gì bạn đang gửi dưới dạng yêu cầu kéo.

    Vì vậy, có, bạn phải tạo một nhánh (và yêu cầu kéo) cho mỗi lần sửa lỗi. Có thể là khôn ngoan khi bắt đầu với một và xem người bảo trì phản ứng với người đó như thế nào trước khi tiếp tục làm phần còn lại. Nguồn mở là một quá trình xã hội vốn có.

  2. Đừng tạo một yêu cầu kéo cho những thay đổi khoảng trắng của bạn! Nói như một người đôi khi là người bảo trì, tôi thích những loại yêu cầu kéo này: Tôi chấp nhận hoặc không chấp nhận và họ mất ít thời gian để xử lý.

    Những gì bạn cũng có thể gặp phải là người bảo trì không đồng ý với những thay đổi khoảng trắng của bạn! Cẩn thận..

  3. Hmm .. Không rõ bạn đang cố gắng đạt được điều gì ở đây. Nghe có vẻ như quá nhiều tài liệu và không tốt cho một ý tưởng - có lẽ bạn có thể làm rõ lý do tại sao bạn muốn làm điều này?

  4. Liên kết với repo của anh ấy trong thông điệp cam kết của bạn (hoặc thậm chí trong một nhận xét trong mã) là một cách tuyệt vời để cung cấp tín dụng. Hãy cẩn thận mặc dù - làm cho rõ ràng rằng bạn đang cảm ơn anh vì anh ý tưởngkhông cho mã của mình. Nếu bạn đã sao chép mã, thì tôi sẽ gửi email cho anh ấy về nó, trừ khi rất rõ anh ấy đang sử dụng giấy phép nào cho mã của mình. Nếu giấy phép rõ ràng (và đó là giấy phép khác với kho lưu trữ mà bạn đang gửi cam kết) thì bạn cần thêm giấy phép khác trong yêu cầu kéo và cũng đề cập đến trong thông báo yêu cầu kéo của bạn.

  5. Đây là một câu hỏi thực sự tốt và khác nhau tùy thuộc vào người bạn nói chuyện. Ý kiến ​​của tôi là bạn không bao giờ nên thêm tên của mình vào bất kỳ cam kết hoặc mã nào bạn làm. Lý do chính là nó ngụ ý "quyền sở hữu và trách nhiệm đối với mã" - nó có thể ngăn người khác sửa đổi mã vì "đó là của bạn". Nhưng bây giờ chúng ta đang tham gia vào một cuộc thảo luận lớn về bản chất của nguồn mở, vì vậy tôi sẽ dừng lại ở đây và nói - hỏi người bảo trì dự án hoặc chỉ làm điều đó và xem phản ứng của anh ta.

  6. Bạn có thể viết lại lịch sử (địa phương, chưa được công bố) của bạn với GIT! Tìm hiểu lệnh git rebase - đây là một trong những lý do chính khiến tôi yêu git. Đó là một ý tưởng thực sự tồi tệ (buộc) đẩy các cam kết / lịch sử được viết lại vào kho lưu trữ được chia sẻ (ví dụ như github). Điều này sau đó sẽ làm hỏng các kho lưu trữ mà các nhà phát triển khác có - họ sẽ phải làm những điều khó khăn khi kéo các thay đổi (viết lại lịch sử) của bạn.

[# 6: Cảm ơn @toxalot!]


Đối với # 6, có, bạn có thể viết lại lịch sử, nhưng chỉ lịch sử địa phương. Một khi nó được đẩy lên một repo công khai, đó là một ý tưởng thực sự tồi tệ để viết lại lịch sử.
toxalot
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.