Các cộng tác viên trên một kho lưu trữ Github riêng tư mỗi ngã ba repo?

Hiện tại tôi đang làm việc trên một dự án và chúng tôi có mã nguồn trong một kho lưu trữ riêng trên Github, với mỗi người chúng tôi là cộng tác viên.

Những gì chúng tôi không rõ ràng là làm thế nào để phân tách từng công việc của chúng tôi.

Những gì tôi nghĩ rằng chúng ta cần phải làm là:

1. Mỗi người trong chúng ta cần rẽ nhánh kho lưu trữ
2. Khi chúng tôi sẵn sàng đẩy mã của mình, sau đó chúng tôi sẽ gửi yêu cầu kéo tới repo của người dẫn đầu dự án, người có thể đồng thời sử dụng mã này như một cơ hội để thực hiện đánh giá mã

Khi nói đến các kho lưu trữ riêng tư, đây có phải là mục đích giả mạo được sử dụng cho mục đích này không, hay tôi đang làm quá lên tình huống này?

Nhân bản repo vào máy cục bộ của nhà phát triển đã là một loại giả mạo. Nếu mỗi nhà phát triển tạo ra repo trên GitHub, điều này chỉ phục vụ để xuất bản trạng thái công việc hiện tại của họ.

Điều này có thể phù hợp khi có một repo chính trung tâm và nhiều người đóng góp không được tin cậy với quyền truy cập trực tiếp vào repo đó. Điều này hoạt động rất tốt cho các dự án nguồn mở, nơi mọi người có thể đóng góp và đưa ra yêu cầu kéo sau đó được xem xét và sáp nhập bởi một nhóm các nhà bảo trì cốt lõi. Sử dụng nhiều repos thực thi quy trình làm việc dựa trên yêu cầu kéo.

Trong một nhóm nhỏ, đáng tin cậy, điều này là không cần thiết. Để ngăn những người khác nhau tiếp cận nhau, một chiến lược như Git Flow có thể được thực hiện: Mỗi tính năng nhỏ được triển khai trên một nhánh tính năng riêng biệt. Khi tính năng hoàn thành, nó được hợp nhất vào nhánh chính. Hầu hết các đội sẽ kết hợp điều này với yêu cầu kéo hoặc đánh giá mã theo quy ước, nhưng đủ tin cậy để bỏ qua điều đó nếu thích hợp. Trong khi các repos riêng biệt sẽ dẫn đến một nhà phát triển xuất bản trạng thái hiện tại của họ trên các repos rẽ nhánh nhưng có thể nhìn thấy theo nhóm, trong một repo chung duy nhất họ sẽ đẩy các thay đổi của mình sang một nhánh tính năng riêng biệt. Thực hiện tất cả các phát triển trên master / trunk rất không được khuyến khích trong hầu hết các quy trình công việc.

Sự khác biệt cuối cùng chỉ là về quản lý truy cập và không quá nhiều về quy trình công việc được thực hiện. Bạn có thể thực hiện các quy trình công việc dựa trên yêu cầu kéo với thiết lập. Từ góc độ Git thô, không có nhiều khác biệt giữa một ngã ba và một nhánh - về cơ bản, chia sẻ về lịch sử của dự án và cho phép các cam kết được thêm vào mà không ảnh hưởng đến các nhánh / nhánh khác. Xem xét điều này, sẽ tốt hơn nhiều để chia sẻ một repo duy nhất khi trong một nhóm kín, đáng tin cậy.

Điều này sẽ hoạt động hoặc bạn có thể sử dụng một phương thức phân nhánh trong đó mỗi đóng góp có (các) chi nhánh riêng của họ, khi nhóm đồng ý, được hợp nhất với chủ.