Chiến lược xem xét mã trước khi hợp nhất để làm chủ từ các nhánh tính năng

Tôi và nhóm của tôi sử dụng các nhánh tính năng (với git). Tôi đang tự hỏi đâu là chiến lược tốt nhất để đánh giá mã trước khi hợp nhất thành chủ.

1. Tôi kiểm tra một chi nhánh mới từ chủ, hãy gọi nó là fb_ # 1
2. Tôi cam kết một vài lần và muốn hợp nhất nó trở lại thành chủ
3. Trước khi tôi hợp nhất một người nào đó có nghĩa vụ phải thực hiện đánh giá mã

Bây giờ có 2 khả năng:

1

1. Tôi hợp nhất chủ với fb_ # 1 ( không phải fb_ # 1 thành chủ) để làm cho nó cập nhật nhất có thể
2. Một đồng đội đánh giá các thay đổi giữa đầu chủ và đầu fb_ # 1
3. Nếu fb_ # 1 ổn, chúng tôi hợp nhất fb_ # 1 thành chủ
4. Ưu điểm: không có mã lỗi thời trong đánh giá
5. Nhược điểm: nếu người khác hợp nhất một cái gì đó giữa "1." và 2." những thay đổi của anh ấy xuất hiện trong đánh giá, mặc dù chúng thuộc về một đánh giá khác.

lần 2

1. Một đồng đội đánh giá các thay đổi giữa điểm thanh toán (git merge-base master fb_ # 1) và đầu fb_ # 1
2. Ưu điểm: chúng tôi thấy chính xác những gì đã thay đổi trong khi làm việc trên nhánh tính năng
3. Nhược điểm: một số mã lỗi thời có thể xuất hiện trong đánh giá.

Cách nào bạn nghĩ là tốt hơn và tại sao ? Có lẽ có một cách tiếp cận khác phù hợp hơn?

Có một biến thể của tùy chọn 1 của bạn:

1. hợp nhất chủ với fb_ # 1 (không phải fb_ # 1 với chủ) để làm cho nó cập nhật nhất có thể
2. Một đồng đội đánh giá các thay đổi giữa chủ tại điểm bạn đã hợp nhất và đầu fb_ # 1
3. Nếu fb_ # 1 ổn, chúng tôi hợp nhất fb_ # 1 thành chủ
4. kiểm tra nhanh xem hợp nhất có ổn không

ví dụ.

... ma -- ... -- mm -- ... -- mf  <- master
      \            \         /
       f1 ... fn -- fm -----      <-- fb_#1

Ở đâu:

• ma là tổ tiên của chủ và fb_ # 1.
• fn là thay đổi cuối cùng trên chi nhánh của bạn
• mm là cam kết là chủ / ĐẦU tại thời điểm bạn sáp nhập vào chi nhánh của mình (đưa ra fm ).

Vì vậy, bạn so sánh mm và fm trong đánh giá ban đầu của mình và sau đó nhanh chóng kiểm tra sau khi hợp nhất lại mf để đảm bảo không có gì thay đổi đáng kể trên bản gốc trong các bước 1-3. Điều này dường như có tất cả các ưu và không có nhược điểm nào cho đánh giá ban đầu.

Điều này giả định rằng đánh giá là nhanh so với tần suất thay đổi thông thường được đẩy lên thành chủ, vì vậy fm -> mf thường sẽ là một chuyển tiếp nhanh.

Nếu đó không phải là trường hợp, vì bất kỳ lý do gì, khuyết điểm sẽ chỉ chuyển từ đánh giá ban đầu sang đánh giá sau hợp nhất, và có thể đơn giản hơn là chỉ hợp nhất trực tiếp vào tổng thể và thực hiện đánh giá duy nhất ở đó.

lần thứ 3

• Bạn rebase nhánh trên tổng thể để cả hai làm cho nó up-to-date và giữ những thay đổi riêng biệt.

  Điều này tạo ra một lịch sử mới của chi nhánh. Đây sẽ là các bản sửa đổi mới với các ID mới sẽ có cùng nội dung, nhưng sẽ được lấy từ bản chính mới nhất và sẽ không liên kết với các bản sửa đổi cũ. Các bản sửa đổi cũ vẫn có thể truy cập được trong "reflog" nếu bạn cần tham khảo chúng, ví dụ như vì bạn thấy bạn đã mắc lỗi trong giải quyết xung đột. Bên cạnh đó họ là vô giá trị. Theo mặc định, Git sẽ cắt bỏ phần giới thiệu sau 3 tháng và loại bỏ các bản sửa đổi cũ.

• Bạn sử dụng rebase tương tác ( git rebase -ivà git commit --amend) để sắp xếp lại, chỉnh sửa và dọn dẹp các thay đổi để mỗi thay đổi được đóng lại một cách hợp lý.

  Điều này một lần nữa tạo ra lịch sử mới, lần này với lợi ích bổ sung mà bạn có thể cơ cấu lại các thay đổi để có ý nghĩa nhất trong quá trình xem xét.

• Ưu điểm:

  • không có mã lỗi thời trong đánh giá
  • chúng tôi thấy chính xác những gì đã thay đổi trong khi làm việc trên nhánh tính năng
• Nhược điểm:
  • làm thêm một chút
  • bạn phải cẩn thận để không phản đối bất cứ điều gì đã được hợp nhất hoặc bạn đã chia sẻ và người nhận không mong đợi nó sẽ được tua lại.

Thông thường công việc làm thêm có nghĩa là bạn xem xét mã kỹ lưỡng trước và điều đó cũng sẽ gặp nhiều vấn đề.

Đây là những gì Linux và Git làm. Và không có gì lạ khi thấy hàng loạt 20 đến 25 bản vá được gửi để xem xét và viết lại nhiều lần trong các dự án đó.

Trên thực tế, Linux đã làm điều đó từ sớm trong dự án khi kiểm soát phiên bản của họ là tarball và bản vá lỗi. Khi nhiều năm sau Linus bắt đầu tạo ra git, đó là lý do chính để thực hiện rebaselệnh và đó là biến thể tương tác. Cũng bởi vì nó git có khái niệm riêng về tác giả và người đi làm . Tác giả là người đầu tiên tạo ra bản sửa đổi và người đi làm là người cuối cùng chạm vào nó. Vì trong cả Linux và Git, các bản vá vẫn được gửi qua email, hai người gần như không bao giờ là cùng một người.

Trên thực tế, có một khả năng sở hữu thứ ba và có lẽ nhiều người khác, vì GIT là một triển khai của khung SCM hơn là triển khai phương pháp SCM. Khả năng thứ ba này dựa trênrebase .

Tiểu ban rebaseGIT lấy một loạt các cam kết (thường là từ điểm phân nhánh của bạn đến đỉnh của nhánh chủ đề của bạn topic) và phát lại chúng ở một nơi khác (thường là ở đầu nhánh tích hợp của bạn, ví dụ master). Tiểu ban rebasesản xuất các cam kết mới, tạo cơ hội sắp xếp lại các cam kết theo hình thức dễ xem xét hơn. Điều này mang lại một loạt các cam kết mới, tương tự như trước đây topicnhưng xuất hiện bắt nguồn từ đầu nhánh tích hợp. Chi nhánh mới này vẫn được gọi topicbởi GIT, do đó tham chiếu cũ bị loại bỏ. Tôi không chính thức dán nhãn topic-0trạng thái ban đầu của chi nhánh của bạn vàtopic-1 và v.v.

Đây là gợi ý của tôi cho topicchi nhánh của bạn :

1. (Bước không bắt buộc) Bạn tương tác rebase chi nhánh chủ đề của bạn topicở điểm phân nhánh của nó (xem --fixuplựa chọn cho commitvà -ivà --autosquashtùy chọn trên rebase), mang đến cho bạn cơ hội để viết lại cam kết của bạn trong một cách đó là dễ dàng hơn để xem xét. Điều này dẫn đến một chi nhánh topic-1.

2. Bạn khởi động lại nhánh chủ đề của mình ở đầu nhánh tích hợp của bạn, tương tự như thực hiện hợp nhất, nhưng không làm ô nhiễm lịch sử với một sự hợp nhất chỉ là một tạo tác kỹ thuật phần mềm. Điều này dẫn đến một chi nhánh topic-2.

3. Gửi topic-2cho một đồng đội đánh giá nó dựa trên mẹo master.

4. Nếu topic-2ổn thì hợp nhất nó thành chủ.

LƯU Ý Các nhánh mà ở đó nhánh liên quan đến cây cam kết, tất cả sẽ được GIT gọi là giống nhau, do đó, ở cuối quá trình, chỉ có nhánhtopic-2 có tên trong GIT.

Ưu điểm:

• Không có mã lỗi thời trong xem xét.
• Không có giả mạo nào nước ngoài sáp nhập các đánh giá của người dùng (hiện tượng bạn mô tả trong lần 1).
• Cơ hội để viết lại cam kết một cách sạch sẽ.

Nhược điểm:

• Thay vì một chi nhánh topic-0, có ba nhánh hiện vật topic-0, topic-1và topic-2được tạo ra trong các cam kết cây. (Mặc dù bất cứ lúc nào, chỉ một trong số họ có tên trong GIT.)

Trong kịch bản đầu tiên của bạn «nếu ai đó hợp nhất một cái gì đó giữa" 1. " và "2." »đề cập đến khoảng thời gian giữa việc tạo điểm nhánh và thời điểm bạn quyết định hợp nhất. Trong kịch bản này «nếu ai đó hợp nhất một cái gì đó giữa" 1. " và "2." »đề cập đến khoảng thời gian giữa rebase và hợp nhất, thường rất ngắn. Do đó, trong kịch bản tôi cung cấp, bạn có thể «khóa»master nhánh trong thời gian hợp nhất mà không làm ảnh hưởng đáng kể đến quy trình làm việc của bạn, trong khi nó không thực tế trong kịch bản thứ nhất.

Nếu bạn đang thực hiện đánh giá mã hệ thống, có lẽ nên sắp xếp lại các cam kết theo cách thích hợp (bước tùy chọn).

Quản lý các tạo phẩm nhánh trung gian chỉ gặp khó khăn nếu bạn chia sẻ chúng giữa các kho lưu trữ.