Có mục đích sử dụng các yêu cầu kéo trên repo của riêng tôi nếu tôi là nhà phát triển duy nhất không?

Vì vậy, tôi đã bắt đầu với một dự án thực sự của mình trên GitHub và mọi thứ đang diễn ra khá tốt và các ý tưởng đang trôi chảy nhanh hơn nhiều so với tôi nghĩ ban đầu. Để giữ mọi thứ ngăn nắp, tôi thiết lập một số chi nhánh để tôi có thể phát triển các tính năng khác nhau một cách riêng biệt.

Bây giờ khi tôi đẩy chi nhánh của mình lên GitHub, tôi có phần đó nơi tôi có hai nút: Pull Requestvà Comparevới tên của chi nhánh mà tôi mới đẩy đến gần đây. Tôi hiểu mục đích của Comparenút nhưng tôi không hiểu lý do tại sao tôi muốn tạo yêu cầu kéo trên repo của riêng mình.

Ai đó có thể giải thích cho tôi tại sao tôi sẽ làm điều đó? Có hữu ích khi thực hiện yêu cầu kéo trên repo của riêng tôi không nếu tôi là nhà phát triển duy nhất?

Đối với nhiều người (có lẽ là hầu hết) các nhà phát triển cá nhân tự làm việc, việc tạo các yêu cầu kéo có lẽ không đáng giá. Tuy nhiên, tôi có thể nghĩ ra ít nhất một lý do tiềm năng để làm điều đó:

Yêu cầu kéo có thể được sử dụng để theo dõi lịch sử dự án của bạn dễ dàng hơn. Yêu cầu kéo có ID vấn đề có thể được tham chiếu từ các thông báo cam kết và trong nhật ký thay đổi, cho phép bạn dễ dàng quay lại và tìm điểm hợp nhất và tập hợp các cam kết hợp nhất cho một thay đổi cụ thể mà không phải giữ lại tính năng của bạn nhánh vô thời hạn.

Ví dụ: trong Tiên phong (phích cắm không biết xấu hổ), khi chúng tôi hợp nhất yêu cầu kéo, chúng tôi thêm một mục vào thay đổi , với mô tả một dòng về thay đổi và tham chiếu đến ID yêu cầu kéo. Tất nhiên, Pioneer có một số nhà phát triển, nhưng cơ chế tương tự có thể hữu ích cho nhà phát triển tự làm việc.

Điều này có thể ít hữu ích hơn nếu bạn quyết định bám vào lịch sử cam kết tuyến tính (bằng cách khởi động lại các nhánh tính năng của bạn trước khi hợp nhất, để việc hợp nhất luôn có thể được thực hiện dưới dạng chuyển tiếp nhanh) và nếu bạn rất kỷ luật trong việc chỉnh sửa và xóa sổ cam kết trước khi hợp nhất thành chủ, bởi vì trong trường hợp đó, các thông điệp cam kết riêng lẻ có thể được sử dụng như một thay đổi trong chính chúng.

Yêu cầu kéo được tạo để ai đó có thể xem lại công việc, đưa ra nhận xét, đề xuất, thực hiện hoặc yêu cầu chỉnh sửa và sau đó hợp nhất mã để làm chủ.

Trong trường hợp của bạn, một người nào đó là bạn.

Là nhà phát triển duy nhất, bạn vẫn nên xem lại công việc của chính mình, tái cấu trúc nó và hợp nhất nó thành chủ khi sẵn sàng.

Một cách tiếp cận tôi sử dụng rất nhiều là cố gắng 'đội mũ khác', 'thử các personas khác'. Vì vậy, ngồi trong một thời gian ngắn và đặt mình vào tình huống: người mới tham gia nhóm; Junior Developer; đồng nghiệp mà bạn tôn trọng trong quá khứ, v.v ... Hãy thử và nhìn nó qua đôi mắt của họ và cố gắng nghĩ đơn giản những gì bạn có thể làm để thay đổi rõ ràng hơn, viết tốt hơn với những cái tên tốt hơn để tránh kiến ​​thức về bộ lạc và tên miền càng nhiều càng tốt .

Vì vậy, như bạn đã chỉ ra, bạn nên làm việc trong các chi nhánh khi bạn muốn tách biệt các tính năng và thay đổi chưa sẵn sàng để làm chủ. Bạn có thể làm tất cả những việc đó trong các chi nhánh (thậm chí bạn không cần yêu cầu kéo để quản lý chúng nếu bạn vẫn thực hiện các tác vụ PR, nhưng nó có thể cung cấp cấu trúc hữu ích cho bạn).

Ngoài ra, đôi khi tôi sẽ thấy rằng thay đổi của mình không hiệu quả, nhưng thay vì nỗi kinh hoàng khi cố gắng sao lưu nó từ chủ, có thể bây giờ trộn lẫn với các thay đổi chủ khác, tôi có thể thực hiện tất cả trong một nhánh mà sau đó tôi có thể bỏ qua / xóa nếu nó bắt đầu đi sai. Đây là một lợi ích rất lớn.

Vì vậy, bạn nên làm việc trong các chi nhánh và không cam kết trực tiếp làm chủ cho đến khi bạn quyết định hợp nhất toàn bộ chi nhánh.

Đây là những hướng dẫn - và không phải là quy tắc - để tuân theo. Tôi cố ý phá vỡ chúng đôi khi. Ví dụ, ngày hôm qua tôi đã sửa lỗi chính tả cho chủ.

Có vẻ như bạn có các chi nhánh từ xa cũng như các chi nhánh địa phương. Nếu bạn đang tìm thấy chi phí hoạt động của công việc đó quá nhiều, thì bạn luôn có thể làm việc trên các tính năng khác nhau bằng cách sử dụng các nhánh cục bộ mà không cần đẩy chúng.

Về cơ bản nó đi xuống để làm những gì làm việc cho bạn. Làm việc với các chi nhánh là một lợi ích to lớn đối với git và github làm cho điều đó thực sự dễ dàng, nhưng là một nhà phát triển đơn độc, không có nhu cầu lớn để sử dụng mô hình yêu cầu kéo và cam kết trực tiếp thành thạo nên hoạt động tốt. Khi dự án của bạn cuối cùng trở nên cực kỳ thành công và hàng chục hoặc hàng trăm nhà phát triển đang làm việc với nó, bạn sẽ thấy nhận được yêu cầu kéo từ dĩa của họ là một cách tuyệt vời để theo dõi dự án.

Yêu cầu kéo thường sẽ được sử dụng cho các đánh giá mã hoặc đóng góp từ người dùng với ngã ba dự án của riêng họ - cho một nhà phát triển trong dự án mà tôi không thực sự thấy mục đích.

Lý do mà tôi làm điều đó là vì đó là một cách thuận tiện để đảm bảo rằng tất cả các kiểm tra tự động đều vượt qua (nó biên dịch, nó có định dạng chính xác, kiểm tra đơn vị vượt qua ...).

Tôi không nhất thiết yêu cầu tất cả các séc phải vượt qua cho mỗi lần xác nhận, nhưng tôi muốn người đứng đầu chi nhánh chính luôn vượt qua séc. Tôi nghĩ rằng yêu cầu kéo là cách dễ dàng (có lẽ không phải là duy nhất).

Tổng quát hơn, đó là một cách để kết nối các móc để hoàn thành các thay đổi. Các xét nghiệm là một ví dụ; @ John đã đề cập đến việc tạo ghi chú phát hành như một ví dụ khác.

Kéo yêu cầu so với git đẩy cuối cùng đi xuống một trong những lịch sử cá nhân hoặc chia sẻ. Kho lưu trữ chính là nguồn cho tất cả các thay đổi, nếu những người khác đang rút ra và có khả năng thực hiện các thay đổi cục bộ, thì yêu cầu đẩy có thể khiến những người dùng đó gặp sự cố như cây mà họ đang nhận được từ các thay đổi.

Mô hình yêu cầu kéo (từ các nhánh tùy chỉnh hoặc kho cá nhân) phục vụ như một cách để cung cấp lịch sử nhất quán cho tất cả những người sử dụng và xuất phát từ mã.

Một phần lý do bạn đặt mã trên github là để làm cho mã có sẵn để giả mạo và kéo các yêu cầu. Bạn không bao giờ biết khi nào nó sẽ xảy ra, và giữ cho lịch sử đồng phát triển của bạn nhất quán sẽ là một điểm cộng lớn.