Là tốt hơn để bắt đầu một Yêu cầu kéo hoặc thực hiện một cam kết hợp nhất cục bộ trên bản gốc?

Bây giờ tôi đã sử dụng GitHub khá lâu và tôi thường sử dụng để đẩy các nhánh tính năng của mình và sau đó bắt đầu Yêu cầu Kéo mà tôi tự hợp nhất. Tôi tìm thấy nó giúp tôi theo dõi nơi tôi sáp nhập các chi nhánh.

Nhưng gần đây tôi đã đọc nhiều hơn về cách Git hoạt động và tôi nhận ra rằng tôi có thể sử dụng các cam kết hợp nhất để tham chiếu khi tôi hợp nhất các chi nhánh.

Vậy, tôi nên làm gì khi hợp nhất một nhánh tính năng thành master:
Thực hiện một cam kết hợp nhất trên master và sau đó đẩy nó ngược dòng HOẶC Đẩy nhánh cục bộ và bắt đầu Yêu cầu kéo?

Tôi đã đọc Giới thiệu Yêu cầu Kéo cho nhóm 2 người - hợp nhất các yêu cầu của riêng tôi? và luồng công việc với 2 người trong một dự án và tôi có nên mở yêu cầu kéo từ một chi nhánh trên repo chính thức hoặc ngã ba của tôi không? nhưng không ai trong số họ dường như trả lời những gì tôi đang tìm kiếm.

— Ashhar Hasan
nguồn

Chính xác thì bạn cảm thấy thiếu gì từ những câu trả lời đó?

— RubberDuck

Người đầu tiên nói về nó từ ý nghĩa rằng các yêu cầu kéo có nghĩa là được xem xét ngang hàng. Cái thứ hai cung cấp một quy trình làm việc. Cái thứ ba thậm chí không liên quan.

— Ashhar Hasan

Tôi đang xem xét điều này từ một Thực tiễn Tốt nhất hoặc Cách duy trì quan điểm lịch sử git tốt .

— Ashhar Hasan

Khi tôi hợp nhất một PR, tôi làm như vậy bằng cách hợp nhất chi nhánh cục bộ. Điều này cho phép tôi đảm bảo hợp nhất áp dụng sạch sẽ và chạy lại các thử nghiệm trước khi công bố kết quả. Yêu cầu kéo của GitHub chỉ là một hình thức chính thức của quy trình công việc này, bản thân Git không có khái niệm về PR.

— amon

Khi PR được hợp nhất, nó tạo ra một cam kết hợp nhất trên chủ, vì vậy tôi không nghĩ rằng điều này tạo ra bất kỳ sự khác biệt nào trong lịch sử git. Do đó, tôi không nghĩ có bất kỳ lý do nào để sử dụng cái này hay cái kia ngoài sở thích cá nhân của bạn giữa dòng lệnh và UI Github.

— Ixrec

Câu trả lời:

Cơ chế hợp nhất git:
Sử dụng git merge featurewhile trên master hợp nhất nhánh featurevới mastervà tạo ra một merge-commit(nếu nhánh không thể chuyển tiếp nhanh) trong lịch sử git. Để buộc một merge-committhực hiện, sử dụng --no-fftùy chọn với merge.

Hợp nhất cơ chế Yêu cầu kéo:
Khi chúng tôi bắt đầu Yêu cầu kéo trên GitHub, nó tạo ra GitHub Issuenơi mọi người có thể nói chuyện và thảo luận về các cam kết trong PR trước khi hợp nhất nó. Khi một PR được hợp nhất trên GitHub, nó thực hiện chính xác như vậy git merge feature.

Tôi nên làm gì?
Vì vậy, theo như lịch sử có liên quan, không có sự khác biệt giữa hai.
Và theo như sự đóng góp, những người đóng góp của bạn sẽ không phải làm gì khác cho hai tình huống. Họ giống nhau (trừ cuộc trò chuyện nhỏ tốt đẹp).

Thực tiễn tốt nhất:
Và tôi không thể tìm thấy một thực tiễn tốt nhất nhưng logic nói rằng PR không hữu ích lắm nếu chỉ có một người duy nhất trên kho lưu trữ.

@lxrec và @amon đã giúp tôi đi đến kết luận này.

— Ashhar Hasan
nguồn

Mẹo: git mergecó thể không ghi lại một cam kết hợp nhất nếu nó có thể thực hiện một chuyển tiếp nhanh về phía trước. Để buộc một cam kết hợp nhất, bạn có thể thêm --no-fftùy chọn.

— amon

Tôi thích thực hiện git-merge trên cục bộ hơn là thực hiện trên githuib.com, nếu tôi phải làm bất cứ điều gì như vậy trên github.com, tôi không muốn làm trực tiếp trên nhánh chính, trước tiên tôi muốn lấy nhánh không chính chủ được đặt ở chế độ dàn trước khi đưa nó vào sản xuất.

— Ciasto piekarz

Như Ashhar đã nói, về mặt kỹ thuật và lịch sử không có sự khác biệt. Đối với các dự án có một nhóm nhỏ, tôi thích sáp nhập trực tiếp thay vì thêm bước tạo PR. Tuy nhiên, khi một tính năng cần xem xét / phản hồi hoặc khi đó là WIP và nhiều người sẽ làm việc với nó, tôi có xu hướng mở PR và thêm danh sách các nhiệm vụ vào mô tả của PR.

Lưu ý rằng git mergecó thể sử dụng chuyển tiếp nhanh nếu không có thay đổi nào đối với bản gốc, vì vậy bạn có thể muốn sử dụng git merge --no-ff. Tôi có xu hướng không.

Vì vậy, tóm lại, chỉ sử dụng PR khi bạn cần thảo luận. Nếu không thì chỉ cần hợp nhất trực tiếp.

— Louay Alakkad
nguồn

Điều đáng nói là các cuộc thảo luận và phản hồi về yêu cầu kéo có thể đến từ các nguồn tự động cũng như các thành viên trong nhóm. Nếu bạn có một máy chủ CI được thiết lập, nó có thể đưa ra kết quả xây dựng và kiểm tra để bạn không bao giờ hợp nhất thứ gì đó phá vỡ bản dựng trên bản gốc.

— Eric