Cập nhật kho lưu trữ dùng chung git

Question

Xem xét kho lưu trữ Một kho lưu trữ github được quản lý qua Gerrit. Tôi nhân bản kho lưu trữ A và tạo một nhánh mới bắt đầu từ nhánh master của kho A. Tôi đã đẩy nhánh mới này vào kho lưu trữ gitlab mới B. Tôi là admin trên kho B và tôi chia sẻ nó với các nhà phát triển khác. Các nhà phát triển không thể thúc đẩy nhánh này, nhưng tôi có thể hợp nhất các yêu cầu kéo của họ. Tôi đã hợp nhất một số yêu cầu kéo trên nhánh chính của kho B. Vì vậy, kho B có các cam kết ban đầu của kho A và các cam kết mới của yêu cầu kéo: B cam kết trên đầu A cam kết (b a).

Sau đó, tôi muốn cập nhật kho B với các cam kết mới của kho lưu trữ A. Gọi các cam kết này là +.

tôi thấy hai lựa chọn:

1. Nếu tôi kết hợp A vào B, kết quả là: a + b a.
2. Nếu tôi rebase B trên A +, kết quả là: b a + a.

Tùy chọn 1: cam kết phát triển được trộn lẫn với các cam kết bên ngoài. Khó gỡ lỗi và làm nổi bật sự khác biệt.

Tùy chọn 2: Tôi phải đẩy các thay đổi trên điều khiển từ xa B. Hậu quả, nếu tôi không nhầm, có thể là: 1. nếu nhà phát triển kéo B và họ đã cam kết với chủ B địa phương, họ sẽ mất các thay đổi cục bộ của họ; 2. nhà phát triển có thể gặp phải những rắc rối lớn trong quá trình khởi động lại chi nhánh địa phương của họ sau khi cập nhật bắt buộc của chi nhánh B.

Tôi nên tiến hành như thế nào để tránh mọi sự cố?

Answer 1

Nếu tôi hiểu nó một cách chính xác, bạn có một duy nhất (địa phương) kho trông hơi như thế này:

  A/master 
       ↓ 
* -- * -- * -- a 
       \ 
       * -- * -- b 
          ↑ 
         B/mybranch 

Bây giờ, A được cập nhật, vì vậy nó trông như thế này:

      A/master 
           ↓ 
* -- * -- * -- a -- * -- * -- a+ 
       \ 
       * -- * -- b 
          ↑ 
         B/mybranch 

Lưu ý ở đây là bạn có hai nhánh phân tách không theo đường thẳng. Vì vậy, nói rằng bạn sẽ nhận được a+ b a khi bạn hợp nhất A vào B không chính xác. Bạn không nhận được một hợp nhất, nhưng mà giữ lịch sử vì nó là:

      A/master 
           ↓ 
* -- * -- * -- a -- * -- * -- a+ 
       \    \ 
       * -- * -- b --- M 
           ↑ 
          B/mybranch 

Như bạn thấy, bạn vẫn có những thông tin mà các cam kết đến từ: Những người giữa a và a+ đến từ một chi nhánh, và những cái khác giữa a và b đến từ người khác. Và M kết hợp các nhánh tro đó. Thông thường, này chính xác là cách thích hợp để giải quyết vấn đề này.

Lợi ích của việc này hơn là việc rebasing - như bạn đã nhận thấy chính mình — là các cam kết vẫn như cũ. Tất cả người dùng đã tương tác với một trong hai kho lưu trữ có thể chỉ cần kéo những thay đổi đó mà không gặp bất kỳ sự cố nào. Nếu bạn đã xóa bất kỳ cam kết nào, họ sẽ phải khắc phục thủ công điều đó (có thể là họ thậm chí không nhận ra điều đó, vì vậy họ sẽ chỉ thực sự tạo ra một lịch sử thậm chí còn lộn xộn hơn với các cam kết trùng lặp).

Vì vậy, hợp nhất chắc chắn là tốt hơn để làm việc với ở đây.Có, lịch sử sẽ không hoàn hảo như một đường thẳng, nhưng nó truyền tải đúng những gì đã xảy ra: Có một đường phát triển phân tách độc lập và sau đó đã được cập nhật với các thay đổi từ kho lưu trữ ngược dòng A. Thông tin này có thể hữu ích và như vậy nó có ý nghĩa để giữ chúng trong. Và đặc biệt là nếu bạn có người dùng tương tác với cả những điều khiển từ xa, họ chắc chắn sẽ thích giữ kho lưu trữ của họ tương thích với cả hai điều khiển từ xa.

Nếu bạn không muốn lịch sử để trông như thế này, và không quan tâm về tính tương thích với A, bạn cũng có thể dẹp tất cả những thay đổi từ A vào bạn B:

      A/master 
           ↓ 
* -- * -- * -- a -- * -- * -- a+ 
       \ 
       * -- * -- b -- [A] 
           ↑ 
          B/mybranch 

Ở đây, [A] là cam kết bị bẻ cong có chứa tất cả các thay đổi giữa a và a+ trong một cam kết. Bạn có thể nhận kết quả này bằng cách rebase A lên B trong khi đè bẹp tất cả các cam kết. Trong trường hợp này, bạn nên nêu rõ nơi mà những thay đổi đó xuất phát từ thư cam kết.