2009-09-05 38 views
32

Tôi đang đóng góp cho một dự án nguồn mở khá nhỏ được lưu trữ trên Github. Để những người khác có thể tận dụng công việc của tôi, tôi đã tạo ra chiếc nĩa của riêng mình trên Github. Mặc dù sự lựa chọn của Github về thuật ngữ, tôi không muốn hoàn toàn tách rời khỏi dự án chính. Tuy nhiên, tôi không mong đợi hoặc mong muốn rằng tất cả công việc của tôi được chấp nhận vào kho lưu trữ chính. Một số của nó tuy nhiên, đã được sáp nhập vào kho chính và tôi mong đợi điều này để tiếp tục. Vấn đề tôi đang gặp phải là cách tốt nhất để giữ cho hai cây của chúng ta trong trạng thái mà mã có thể được chia sẻ giữa chúng một cách dễ dàng.Các phương pháp hay nhất cho kho lưu trữ git trên các dự án nguồn mở

Một số tình huống tôi đã hoặc sẽ gặp phải bao gồm:

  • tôi cam kết mã mà sau đó được chấp nhận vào kho chính. Khi tôi kéo từ kho lưu trữ này trong tương lai, cam kết của tôi được nhân đôi trong kho lưu trữ của tôi.
  • Tôi cam kết mã không bao giờ được chấp nhận vào kho lưu trữ chính. Khi tôi kéo từ kho này trong tương lai, hai cây đã phân tán và sửa chữa nó là khó khăn.
  • Một người khác đến và căn cứ vào công việc của họ trên kho lưu trữ của tôi. Vì vậy, tôi nên nếu có thể tránh thay đổi các cam kết mà tôi đã đẩy, ví dụ bằng cách sử dụng git rebase.
  • Tôi muốn gửi mã đến kho lưu trữ chính. Lý tưởng nhất, những thay đổi của tôi sẽ dễ dàng có thể được chuyển thành các bản vá (lý tưởng là sử dụng git format-patch) có thể trực tiếp và sạch sẽ áp dụng cho kho lưu trữ chính.

Theo như tôi có thể nói có hai, hoặc có thể là ba cách để xử lý việc này, không ai trong số đó làm việc đặc biệt tốt:

  • thường chạy git rebase để giữ thay đổi của tôi dựa trên người đứng đầu kho lưu trữ ngược dòng. Bằng cách này tôi có thể loại bỏ các cam kết trùng lặp nhưng thường phải viết lại lịch sử, gây ra các vấn đề cho những người muốn lấy được công việc của họ từ tôi.
  • Thường xuyên hợp nhất các thay đổi lưu trữ ngược dòng vào mỏ. Điều này làm việc ok vào cuối của tôi nhưng dường như không làm cho nó dễ dàng để gửi mã của tôi đến kho lưu trữ ngược dòng.
  • Sử dụng một số kết hợp của những thứ này và có thể chọn git cherry-pick để giữ mọi thứ theo thứ tự.

Người khác đã làm gì trong tình huống này? Tôi biết tình hình của tôi tương tự như mối quan hệ giữa những người đóng góp hạt nhân khác nhau và kho lưu trữ chính của Linus, vì vậy hy vọng có những cách tốt để xử lý điều này. Tôi khá mới để git mặc dù, do đó, đã không làm chủ tất cả các sắc thái của nó. Cuối cùng, đặc biệt là do Github, thuật ngữ của tôi có thể không hoàn toàn nhất quán hoặc chính xác. Vui lòng sửa tôi.

+0

Lưu ý rằng ngay cả khi bạn (ép buộc) đẩy các thay đổi được rebased của bạn, người khác cũng có thể dễ dàng kéo với rebase để cập nhật. Nó chỉ là một hội thảo khác, nơi lịch sử liên tục được viết lại ở mọi nơi. Trên hết, bạn cần phải cẩn thận hơn một chút do lực đẩy có thể quét sạch mọi thứ :) – rubenvb

Trả lời

17

Một số lời khuyên tôi đã học được từ một tình huống tương tự:

  • Có một chi nhánh theo dõi từ xa cho công việc tác giả ngược dòng của.
  • Kéo các thay đổi từ chi nhánh theo dõi này vào chi nhánh chính của bạn một cách thường xuyên.
  • Tạo chi nhánh mới cho từng chủ đề bạn đang làm việc. Những nhánh này thường chỉ là địa phương. Khi bạn nhận được các thay đổi từ thượng nguồn thành chính, hãy rebase các nhánh chủ đề của bạn để phản ánh những thay đổi này.
  • Khi bạn hoàn thành một số công việc về chủ đề, hãy hợp nhất vào chương trình chính.Bằng cách này, những người đang bắt nguồn từ công việc của bạn, sẽ không thấy quá nhiều lịch sử viết lại, kể từ khi việc rebasing xảy ra trong các nhánh chủ đề địa phương của bạn.
  • Gửi thay đổi: Chi nhánh chính của bạn về cơ bản sẽ là một loạt các cam kết, một số trong số đó giống như cam kết, phần còn lại là của bạn. Sau này có thể được gửi dưới dạng bản vá nếu bạn muốn.

Tất nhiên, lựa chọn tên chi nhánh và điều khiển từ xa là của riêng bạn. Tôi không chắc những điều này là đầy đủ đối với kịch bản, nhưng chúng bao gồm hầu hết các rào cản của tôi.

+0

Trong thời gian kể từ khi tôi hỏi câu hỏi này, tôi đã có được nhiều kinh nghiệm hơn với Git và đã giải quyết vấn đề này là câu trả lời hay nhất. Giữ các thay đổi đang được phát triển chỉ vì các cam kết cục bộ là chìa khóa. Chắc chắn là một mẹo rất tốt. Cảm ơn. – orangejulius

+0

Bạn đã từng làm việc trên một nhánh chủ đề trên nhiều máy tính chưa? Nếu đúng thế thì bạn đã làm gì? –

+1

Không, tôi đã không làm việc trên các nhánh chủ đề trên máy tính, nhưng nó không phải là phần "trên máy tính" khó khăn. Đó là "trên mọi người" đó là. Bạn có thể dễ dàng đẩy các nhánh chủ đề của mình vào máy chủ để _you_ có thể làm việc với nó. – sykora

Các vấn đề liên quan