Ngã ba so với phân nhánh trong GitHub

Tôi muốn biết thêm về những lợi thế và bất lợi của việc từ bỏ một dự án github so với việc tạo ra một nhánh của dự án github.

Forking làm cho phiên bản dự án của tôi tách biệt hơn so với phiên bản gốc vì tôi không phải nằm trong danh sách cộng tác viên của dự án ban đầu. Vì chúng tôi đang phát triển một dự án nội bộ, không có vấn đề gì trong việc thêm người làm cộng tác viên. Nhưng, chúng tôi muốn hiểu nếu việc từ bỏ một dự án sẽ khiến các thay đổi hợp nhất trở lại dự án chính khó hơn. Đó là, tôi tự hỏi nếu phân nhánh làm cho việc giữ hai dự án đồng bộ dễ dàng hơn. Nói cách khác, việc hợp nhất và đẩy các thay đổi giữa phiên bản dự án chính của tôi và dự án chính khi tôi phân nhánh có dễ dàng hơn không?

Bạn không thể luôn tạo một chi nhánh hoặc kéo một chi nhánh hiện có và đẩy trở lại chi nhánh đó, bởi vì bạn chưa đăng ký làm cộng tác viên cho dự án cụ thể đó.

Ngã ba không gì khác hơn là một bản sao ở phía máy chủ GitHub :

• mà không có khả năng trực tiếp đẩy lùi
• với tính năng hàng đợi ngã ba được thêm vào để quản lý yêu cầu hợp nhất

Bạn giữ một ngã ba đồng bộ với dự án ban đầu bằng cách:

• thêm dự án ban đầu như một điều khiển từ xa
• lấy thường xuyên từ dự án ban đầu
• khởi động lại sự phát triển hiện tại của bạn trên đầu nhánh quan tâm mà bạn đã cập nhật từ lần tìm nạp đó.

Rebase cho phép bạn đảm bảo các thay đổi của mình đơn giản (không có xung đột hợp nhất để xử lý), giúp cho yêu cầu kéo của bạn trở nên dễ dàng hơn khi bạn muốn người duy trì dự án ban đầu đưa các bản vá của bạn vào dự án của mình.

Mục tiêu thực sự là cho phép cộng tác mặc dù không phải lúc nào cũng có thể tham gia trực tiếp .

Việc bạn sao chép ở phía GitHub có nghĩa là bạn hiện có hai kho lưu trữ "trung tâm" ("trung tâm" là "hiển thị từ một số cộng tác viên).
Nếu bạn có thể thêm chúng trực tiếp làm cộng tác viên cho một dự án, bạn không cần phải quản lý một dự án khác một với một ngã ba.

Trải nghiệm hợp nhất sẽ giống nhau, nhưng với một mức độ gián tiếp cao hơn (đẩy đầu tiên trên ngã ba, sau đó yêu cầu kéo, với nguy cơ tiến triển trên repo ban đầu làm cho việc hợp nhất chuyển tiếp nhanh của bạn không tiến nhanh nữa) .
Điều đó có nghĩa là quy trình công việc chính xác là git pull --rebase upstream(khởi động lại công việc của bạn trên đỉnh của các cam kết mới từ thượng nguồn), và sau đó git push --force origin, để viết lại lịch sử theo cách mà các cam kết của bạn luôn nằm trên các cam kết từ repo ban đầu (ngược dòng) .

Xem thêm:

• Git ngã ba là git clone?
• Kéo các bản cập nhật mới từ kho lưu trữ Github ban đầu vào kho lưu trữ Github rẽ nhánh

Dưới đây là sự khác biệt cấp cao:

Ngã ba

Ưu

• Giữ các nhánh cách nhau bởi người dùng
• Giảm sự lộn xộn trong kho lưu trữ chính
• Quy trình nhóm của bạn phản ánh quy trình đóng góp bên ngoài

Nhược điểm

• Làm cho khó khăn hơn để xem tất cả các nhánh đang hoạt động (hoặc không hoạt động, cho vấn đề đó)
• Cộng tác trên một chi nhánh phức tạp hơn (chủ sở hữu ngã ba cần thêm người làm cộng tác viên)
• Bạn cần hiểu khái niệm về nhiều điều khiển từ xa trong Git
  • Yêu cầu sổ sách kế toán bổ sung
  • Điều này sẽ khiến công việc trở nên khó khăn hơn đối với những người không thoải mái với Git

Phân nhánh

Ưu

• Giữ tất cả các công việc đang được thực hiện xung quanh một dự án ở một nơi
• Tất cả các cộng tác viên có thể đẩy đến cùng một chi nhánh để cộng tác trên đó
• Chỉ có một điều khiển từ xa để xử lý

Nhược điểm

• Các chi nhánh bị bỏ rơi có thể chồng chất dễ dàng hơn
• Quy trình đóng góp nhóm của bạn không phù hợp với quy trình đóng góp bên ngoài
• Bạn cần thêm thành viên nhóm làm cộng tác viên trước khi họ có thể phân nhánh

Nó phải làm với quy trình làm việc chung của Git. Bạn không thể đẩy trực tiếp vào kho lưu trữ của dự án chính. Tôi không chắc chắn nếu kho lưu trữ của dự án GitHub có hỗ trợ kiểm soát truy cập dựa trên chi nhánh hay không, vì bạn sẽ không muốn cấp cho bất kỳ ai quyền đẩy vào nhánh chính chẳng hạn.

Mô hình chung như sau:

• Ngã ba kho lưu trữ của dự án ban đầu để có bản sao GitHub của riêng bạn, sau đó bạn sẽ được phép đẩy các thay đổi.
• Sao chép kho GitHub của bạn vào máy cục bộ của bạn
• Tùy chọn, thêm kho lưu trữ ban đầu dưới dạng kho lưu trữ từ xa bổ sung trên kho lưu trữ cục bộ của bạn. Sau đó, bạn sẽ có thể tìm nạp các thay đổi được xuất bản trực tiếp trong kho lưu trữ đó.
• Thực hiện sửa đổi của bạn và cam kết của riêng bạn tại địa phương.
• Đẩy các thay đổi của bạn vào kho lưu trữ GitHub của bạn (vì bạn thường không có quyền ghi trực tiếp trên kho lưu trữ của dự án).
• Liên hệ với người bảo trì của dự án và yêu cầu họ tìm nạp các thay đổi của bạn và xem xét / hợp nhất và để họ đẩy trở lại kho lưu trữ của dự án (nếu bạn và họ muốn).

Không có điều này, điều khá bất thường đối với các dự án công cộng là cho phép bất cứ ai trực tiếp thực hiện các cam kết của mình.

Forking tạo một kho lưu trữ hoàn toàn mới từ kho lưu trữ hiện có (chỉ cần thực hiện git clone trên gitHub / bitbucket)

Dĩa được sử dụng tốt nhất: khi mục đích của 'chia tách' là tạo ra một dự án độc lập logic, có thể không bao giờ đoàn tụ với cha mẹ của nó.

Chiến lược chi nhánh tạo ra một nhánh mới trên kho lưu trữ hiện có / đang hoạt động

Các nhánh được sử dụng tốt nhất: khi chúng được tạo như là nơi tạm thời để làm việc thông qua một tính năng, với mục đích hợp nhất nhánh với nguồn gốc.

Cụ thể hơn: - Trong các dự án nguồn mở, chủ sở hữu của kho lưu trữ là người quyết định ai có thể đẩy vào kho lưu trữ. Tuy nhiên, ý tưởng về nguồn mở là mọi người đều có thể đóng góp cho dự án.

Vấn đề này được giải quyết bằng các nhánh: bất cứ khi nào nhà phát triển muốn thay đổi thứ gì đó trong dự án nguồn mở, họ sẽ không sao chép trực tiếp kho lưu trữ chính thức. Thay vào đó, họ fork nó để tạo một bản sao. Khi công việc kết thúc, họ đưa ra yêu cầu kéo để chủ sở hữu kho lưu trữ có thể xem xét các thay đổi và quyết định có hợp nhất chúng với dự án của mình không.

Tại cốt lõi của nó tương tự như phân nhánh tính năng, nhưng thay vì tạo các nhánh, một nhánh của kho lưu trữ được thực hiện và thay vì thực hiện một yêu cầu hợp nhất, bạn tạo một yêu cầu kéo.

Các liên kết dưới đây cung cấp sự khác biệt theo cách được giải thích rõ:

https://blog.gitprime.com/the-definitive-guide-to-fork-and-branches-in-git/

https://buddy.works/blog/5-types-of-git-workflows

http://www.cContuptagile.com/unblock/branching.html