xem lại mã với git-Flow và github


43

Với git và github thông thường, tôi có thể thực hiện đánh giá mã bằng cách tạo yêu cầu kéo của nhánh tính năng mà tôi đang làm việc với nhánh chính. Làm thế nào tôi có thể đánh giá mã với git-Flow? Với quy trình công việc như "kết thúc tính năng luồng git 'Tôi bối rối không biết việc xem xét mã thực sự xảy ra ở đâu và làm thế nào git-Flow hoặc git có thể tạo điều kiện cho đánh giá đó.


Bạn có thể xem xét về gerrit mặc dù tôi không chắc làm thế nào nó tích hợp tốt với git-Flow. Dù sao, quy trình làm việc nhóm của bạn là gì?
OnesimusUnbound

Câu trả lời:


29

Chúng tôi vấp phải vấn đề chính xác này gần đây. Chúng tôi thực sự thích luồng git, vì nó sử dụng một mức độ ngữ nghĩa tốt (sử dụng cùng cấp độ mà bạn sử dụng trong thảo luận nhóm: "Tôi sẽ bắt đầu tính năng A" hơn là "Tôi sẽ tạo một nhánh, kiểm tra nó"), trong khi git là cấp độ "thực hiện" (cũng tốt và hữu ích, nhưng khác nhau).

Vấn đề chúng tôi gặp phải là git feature finish, vì nó hợp nhất chi nhánh vào phát triển, trong khi chúng tôi muốn gửi yêu cầu kéo và (điều này rất quan trọng) được người đánh giá hợp nhất , chứ không phải người đi làm, để nhấn mạnh quyền sở hữu nhóm.

Giải pháp hiện tại của chúng tôi:

  1. Ai đó sử dụng luồng git để tạo một nhánh tính năng
  2. Khi hoàn tất, anh ta tạo một yêu cầu kéo (sử dụng github)
  3. Việc xem xét diễn ra, với các cam kết bổ sung tiềm năng
  4. Yêu cầu kéo được sáp nhập bằng GitHub bởi người đánh giá .
  5. Không có kết thúc tính năng luồng git (vì nhánh đã được hợp nhất)

Điều này phù hợp với thực tiễn của chúng tôi, với nhược điểm là phải tự xóa chi nhánh (vì chúng tôi không git kết thúc dòng chảy). Bước tiếp theo của chúng tôi có lẽ sẽ là thực hiện lại một số phần của luồng git (vì chủ yếu là về chuỗi lệnh git) để tính đến điều này (có phần "làm sạch" của kết thúc, mà không cần hợp nhất).


3
Làm thế nào về việc tạo một nhánh phát hành? Điều gì xảy ra với các thẻ?
E-Riddie

16

Quá trình nhóm tôi làm việc với việc sử dụng cho việc này như sau:

  1. Tạo một nhánh tính năng: git flow feature start module_1
  2. Mã được cập nhật trên nhánh tính năng
  3. Khi các thay đổi được cam kết, chúng được đẩy lên GitHub (hoặc một lần vào cuối nếu được ưu tiên)
  4. Khi tính năng được hoàn thành, yêu cầu kéo được mở trong so sánh GitHub developvà nhánh tính năngmodule_1
  5. Nhóm xem xét yêu cầu kéo và đưa ra nhận xét
  6. Mọi thay đổi từ yêu cầu kéo được thực hiện cho nhánh tính năng
  7. Khi tất cả các thay đổi được kết hợp trên nhánh tính năng, nhánh tính năng kết thúc: git flow feature finish module_1
  8. Các developchi nhánh được đẩy lên GitHub (GitHub sẽ tự động đánh dấu yêu cầu kéo như khép kín / sáp nhập khi điều này xảy ra)

Thông thường tất cả quá trình này được thực hiện bởi tác giả ban đầu nhưng điều đó là không bắt buộc. Bất cứ ai trong nhóm của chúng tôi đều có thể bước vào và chọn quy trình này bất cứ lúc nào. Tất cả những gì họ phải làm là kiểm tra nhánh tính năng và tiếp tục quá trình. Ai đã từng chạy git flow feature finish module_1sẽ có sự xa xỉ của chi nhánh tính năng địa phương của họ bị xóa nhưng bất kỳ ai khác đã kiểm tra chi nhánh phải làm điều này bằng tay nếu họ muốn sử dụng một cái gì đó như thế nào git branch -D feature/module_1.

Đối với các hotfix, chúng tôi sử dụng một cách tiếp cận tương tự và tạo yêu cầu kéo trong GitHub trước khi chúng tôi hoàn thành hotfix.


Cảm ơn câu trả lời này. Tôi đã không nhận ra rằng git sẽ đánh dấu PR đóng cửa sau khi hợp nhất.
AbbeyTROLLA

3

Nếu bạn đang thực hiện đánh giá mã, thì tôi sẽ cho rằng bạn có một kho lưu trữ trung tâm chứa mã "chính thức". Các nhà phát triển kéo từ và đẩy đến kho lưu trữ trung tâm này.

Khi bạn sử dụng Gerrit , Gerrit sẽ trở thành kho lưu trữ trung tâm (nó có các máy chủ SSH và HTTP tích hợp cho phép người dùng tương tác với nó về cơ bản giống như cách họ đã có). Khi sử dụng Gerrit, quy trình làm việc sẽ trở thành:

  1. Nhà phát triển thực hiện thay đổi trên bất kỳ chi nhánh nào, cam kết cục bộ.
  2. Nhà phát triển đẩy những thay đổi đó đến Gerrit.
  3. Gerrit tạo các mục đánh giá để người khác xem xét.
  4. Các đồng nghiệp xem xét mã, đưa ra nhận xét và chấp nhận hoặc từ chối cam kết.
  5. Khi cam kết được chấp nhận, thì Gerrit sẽ thực hiện những thay đổi đó cho những người khác rút khỏi chi nhánh.

Khi sử dụng kho lưu trữ trung tâm, các nhà phát triển khác có thể thấy các thay đổi được gửi sau bước 2. Gerrit giới thiệu quy trình xem xét mã và vì vậy các nhà phát triển khác chỉ thấy các thay đổi được gửi sau bước 5.

Điều này hoạt động tốt với git-Flow (hoặc bất kỳ sơ đồ phân nhánh nào khác) vì Gerrit hỗ trợ xem xét các thay đổi được thực hiện trên bất kỳ chi nhánh nào.


3

Đây là một đề nghị khác.

  1. Thực hiện quy trình dòng git thông thường để tạo một tính năng , nhưng không hoàn thành hoặc hợp nhất nó.
  2. Tạo một yêu cầu kéo , nhưng không hợp nhất nó. Chờ người phê duyệt để lại nhận xét. Nhận xét là dấu hiệu của sự chấp thuận.
  3. Làm dòng chảy git kết thúc . (Hoặc người phê duyệt hoặc nhà phát triển có thể làm điều này, tùy thuộc vào những gì nhóm đã đồng ý.) Yêu cầu kéo sẽ được đánh dấu là hợp nhất trên github. Bạn vẫn cần xóa chi nhánh về nguồn gốc.
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.