Làm thế nào để duy trì các nhánh git chạy dài

Question

Các nhánh Git lý tưởng nên kéo dài trong thời gian ngắn, có thể trong 1-2 ngày. Sau đó, nó được sáp nhập vào một số đường chính.

Nhưng trong một số trường hợp, khi chúng tôi làm việc trên các tính năng rất lớn, chúng tôi duy trì các chi nhánh. Và khi 2 hoặc 3 người làm việc trên những tính năng rất lớn này trong các lĩnh vực mã độc quyền, sẽ trở nên khó khăn để duy trì chúng.

Giữa các bản sửa lỗi nóng đi đến nhánh ổn định, chúng tôi cần giữ 2-3 nhánh lớn này đồng bộ với nhánh ổn định. Vì vậy, chúng tôi kết thúc việc này, khá thường xuyên.

(in feature-branch1) $ git merge stable 
(in feature-branch2) $ git merge stable 
(in feature-branch3) $ git merge stable 

Có cách nào phù hợp để duy trì các nhánh chạy dài này trong git không? Bằng cách làm ở trên, lịch sử git là loại lộn xộn. Các chi nhánh tính năng này chủ yếu được đẩy tới điều khiển từ xa có nghĩa là chúng ta không thể thấy rebase làm tùy chọn. Tôi có thể làm gì nữa?

Answer 1

Hợp nhất trong nhánh ổn định mọi lúc và sau đó thực sự là điều dễ nhất và tốt nhất bạn có thể thực hiện để giữ cho chi tiết tính năng của bạn được cập nhật. Tôi sẽ không khuyên bạn nên rebasing vì có thể có nhiều người làm việc trên các tính năng cùng một lúc và họ sẽ phải thiết lập lại các chi nhánh địa phương của họ rất nhiều mỗi khi có một lực đẩy buộc. Ngay cả khi chỉ có một người làm việc trên nhánh tính năng, việc sáp nhập là tốt hơn vì nó hiển thị rõ ràng điểm trong lịch sử mà bạn đã đưa vào các bản sửa lỗi từ nhánh ổn định.

Có, lịch sử của bạn có thể trông khá lộn xộn khi bạn hợp nhất chi nhánh tính năng trở lại ổn định. Nhưng miễn là bạn tránh được sự lộn xộn của vi hợp nhất hàng ngày từ git của bạn kéo (sử dụng git pull --rebase thay vào đó), bạn sẽ có thể đánh giá cao sự hợp nhất thực tế có ý nghĩa.

Nếu bạn thực sự muốn tránh hợp nhất các tính năng mới từ ổn định vào chi nhánh tính năng, nhưng chỉ muốn sửa lỗi, bạn có thể chọn các sửa lỗi vào chi nhánh tính năng. Tuy nhiên điều này có thể là rất nhiều công việc vì nó đòi hỏi bạn luôn luôn trên đầu trang của tất cả mọi thứ đang xảy ra trong ổn định. Sử dụng git cherry để giúp bạn ra ngoài:

# commits from "stable" that are not present in 
# the current branch will be prefixed with "+" 
git cherry HEAD stable 

Answer 2

Có thể thực hiện rebasing nếu nhóm đủ nhỏ và bao gồm người dùng git hợp lý có kinh nghiệm. Ví dụ:

Những gì bạn có thể làm là đồng ý rằng chi nhánh tính năng sẽ được khởi động lại ổn định mỗi đêm. Hoặc bạn có thể gửi email khi bạn rebase tính năng-chi nhánh để ổn định.

Tất cả mọi thứ nên được tốt, nhưng trong trường hợp bạn quên để đồng bộ với các ngành chức năng rebased, nói rằng bạn cam kết C trên đầu trang của các tính năng cũ nhánh oldFB, đã được rebased vào oldFB':

S1 - oldFB - C <-- feature-branch 
    \ 
    S2 - oldFB' - D <-- origin/feature-branch 

nó vẫn còn có thể rebase bạn cam kết (s) C bằng cách chạy:

git checkout feature-branch 
git rebase --onto origin/feature-branch oldFB C 

Lưu ý rằng bạn sẽ phải tìm bằng tay các cam kết gọi oldFB trong sơ đồ trên.

Answer 3

Các lựa chọn tốt nhất là để hợp nhất chỉ chi nhánh bugfix/tính năng nhỏ cần thiết vào các ngành chức năng tồn tại lâu dài của bạn. Bằng cách này bạn chỉ nhận được những gì bạn cần. Lưu ý rằng nếu bạn để các nhánh này sống đủ lâu, cuối cùng chúng có thể không được đồng bộ từ chủ.Đôi khi, bạn có thể muốn tạo nhánh tạm thời của chi nhánh tính năng tồn tại lâu dài của bạn và hợp nhất tổng thể vào chi nhánh để kiểm tra tính chính xác - xem có xung đột hay không, xem liệu thay đổi trong tổng thể có phá vỡ tính năng hay không trên.

Tốt nhất tiếp theo sẽ là hợp nhất định kỳ tổng thể vào các chi nhánh tính năng tồn tại lâu dài của bạn. Điều này là khá an toàn, nhưng cũng có thể hợp nhất trong rất nhiều thay đổi mà bạn không quan tâm và làm phức tạp mọi thứ.

Tôi sẽ không khuyên bạn nên rebasing định kỳ lên master. Nó gây khó khăn cho mọi người để đồng bộ, và nó cũng làm cho nó khó khăn hơn nhiều để duy trì lịch sử phức tạp (sáp nhập) trên các nhánh tính năng của bạn, và làm cho độ phân giải xung đột trở nên đau đớn hơn.