Git: Quy trình công việc Forking

Quy trình công việc Forking khác về cơ bản so với các quy trình công việc Git phổ biến khác. Thay vì sử dụng một kho lưu trữ phía máy chủ duy nhất để hoạt động như cơ sở mã cơ sở trung tâm, nó cung cấp cho mọi nhà phát triển kho lưu trữ phía máy chủ của riêng họ. Điều này có nghĩa là mỗi người đóng góp không chỉ có một, mà là hai kho Git: một kho riêng cục bộ và một bên máy chủ công cộng. Quy trình công việc Forking thường thấy nhất trong các dự án nguồn mở công cộng.

Ưu điểm chính của Quy trình làm việc của Forking là các đóng góp có thể được tích hợp mà không cần mọi người phải chuyển sang một kho lưu trữ trung tâm duy nhất. Các nhà phát triển đẩy đến kho lưu trữ phía máy chủ của riêng họ và chỉ người bảo trì dự án mới có thể đẩy đến kho lưu trữ chính thức. Điều này cho phép người bảo trì chấp nhận các cam kết từ bất kỳ nhà phát triển nào mà không cho họ quyền truy cập bằng văn bản vào cơ sở mã chính thức.

Luồng công việc Forking thường theo mô hình phân nhánh dựa trên luồng công việc Gitflow . Điều này có nghĩa là các nhánh tính năng hoàn chỉnh sẽ được chuyển sang hợp nhất vào kho lưu trữ của dự án ban đầu. Kết quả là một quy trình làm việc phân tán cung cấp một cách linh hoạt cho các nhóm lớn, hữu cơ (bao gồm cả bên thứ ba không tin cậy) để cộng tác an toàn. Điều này cũng làm cho nó trở thành một quy trình làm việc lý tưởng cho các dự án nguồn mở.
 

Làm thế nào nó hoạt động

Như trong các quy trình công việc Git khác , Dòng công việcForking bắt đầu với một kho lưu trữ công khai chính thức được lưu trữ trên một máy chủ. Nhưng khi một nhà phát triển mới muốn bắt đầu làm việc với dự án, họ không trực tiếp sao chép kho lưu trữ chính thức.

Thay vào đó, họ phân nhánh kho lưu trữ chính thức để tạo một bản sao của nó trên máy chủ. Bản sao mới này đóng vai trò là kho lưu trữ công cộng cá nhân của họ. Không có nhà phát triển nào khác được phép sử dụng nó, nhưng họ có thể lấy các thay đổi từ nó (chúng ta sẽ thấy tại sao điều này lại quan trọng trong giây lát). Sau khi họ đã tạo bản sao phía máy chủ của mình, nhà phát triển thực hiện git cloneđể có được một bản sao của nó vào máy cục bộ của họ. Điều này phục vụ như môi trường phát triển riêng tư của họ, giống như trong các quy trình công việc khác.

Khi họ sẵn sàng xuất bản một cam kết cục bộ, họ đẩy cam kết đó vào kho lưu trữ công khai của chính họ chứ không phải là chính thức. Sau đó, họ gửi yêu cầu kéo với kho lưu trữ chính, cho phép người bảo trì dự án biết rằng bản cập nhật đã sẵn sàng để được tích hợp. Yêu cầu kéo cũng phục vụ như một chủ đề thảo luận thuận tiện nếu có vấn đề với mã đóng góp. Sau đây là một ví dụ từng bước của quy trình công việc này.

1. Nhà phát triển 'rèn' kho lưu trữ phía máy chủ 'chính thức'. Điều này tạo ra bản sao phía máy chủ của riêng họ.
2. Bản sao phía máy chủ mới được sao chép vào hệ thống cục bộ của họ.
3. Đường dẫn từ xa Git cho kho lưu trữ 'chính thức' được thêm vào bản sao cục bộ.
4. Một nhánh tính năng cục bộ mới được tạo.
5. Nhà phát triển thực hiện thay đổi trên chi nhánh mới.
6. Cam kết mới được tạo ra cho những thay đổi.
7. Chi nhánh được đẩy sang bản sao phía máy chủ của nhà phát triển.
8. Nhà phát triển mở một yêu cầu kéo từ chi nhánh mới vào kho 'chính thức'.
9. Yêu cầu kéo được phê duyệt để hợp nhất và được hợp nhất vào kho lưu trữ phía máy chủ ban đầu
    

Để tích hợp tính năng này vào cơ sở mã chính thức, nhà bảo trì sẽ kéo các thay đổi của người đóng góp vào kho lưu trữ cục bộ của họ, kiểm tra để đảm bảo nó không phá vỡ dự án, sáp nhập nó vào masternhánh cục bộ của họ , sau đó đẩy masterchi nhánh đến kho lưu trữ chính thức trên máy chủ . Sự đóng góp bây giờ là một phần của dự án và các nhà phát triển khác nên lấy từ kho lưu trữ chính thức để đồng bộ hóa kho lưu trữ cục bộ của họ.

Điều quan trọng là phải hiểu rằng khái niệm về kho lưu trữ chính thức của YouTube trong Dòng công việc Forking chỉ là một quy ước. Trong thực tế, điều duy nhất làm cho kho lưu trữ chính thức trở nên chính thức là nó là kho lưu trữ công khai của người duy trì dự án.

Ngã ba vs nhân bản

Điều quan trọng cần lưu ý là kho lưu trữ "rẽ nhánh" và "forking" không phải là hoạt động đặc biệt. Các kho lưu trữ được tạo bằng cách sử dụng git clonelệnh tiêu chuẩn . Các kho lưu trữ phân tách nói chung là "bản sao phía máy chủ" và thường được quản lý và lưu trữ bởi dịch vụ Git của bên thứ 3 như Bitbucket . Không có lệnh Git duy nhất để tạo kho lưu trữ rẽ nhánh. Một hoạt động nhân bản về cơ bản là một bản sao của một kho lưu trữ và lịch sử của nó. 

Phân nhánh trong quy trình làm việc của Forking

Tất cả các kho lưu trữ công cộng cá nhân này thực sự chỉ là một cách thuận tiện để chia sẻ các chi nhánh với các nhà phát triển khác. Mọi người vẫn nên sử dụng các nhánh để tách biệt các tính năng riêng lẻ, giống như trong Dòng công việc của Chi nhánh tính năng và Luồng công việc Gitflow. Sự khác biệt duy nhất là làm thế nào những chi nhánh được chia sẻ. Trong Dòng công việc Ngã ba, chúng được kéo vào kho lưu trữ cục bộ của nhà phát triển khác, trong khi ở Dòng tính năng và Dòng công việc Gitflow, chúng được đẩy đến kho lưu trữ chính thức.

Ngã ba kho

Tất cả các nhà phát triển mới cho dự án Forking Workflow cần phân nhánh kho lưu trữ chính thức. Như đã nêu trước đây, forking chỉ là một git clonehoạt động tiêu chuẩn . Bạn có thể thực hiện việc này bằng cách SSH vào máy chủ và chạy git cloneđể sao chép nó sang một vị trí khác trên máy chủ. Các dịch vụ lưu trữ Git phổ biến như Bitbucket, cung cấp các tính năng repo repo tự động hóa bước này.

Nhân bản ngã ba của bạn

Tiếp theo mỗi nhà phát triển cần sao chép kho lưu trữ rẽ nhánh công khai của riêng họ. Họ có thể làm điều này với git clonelệnh quen thuộc .

Giả sử việc sử dụng Bitbucket để lưu trữ các kho lưu trữ này, các nhà phát triển trong một dự án nên có tài khoản Bitbucket của riêng họ và họ nên sao chép kho lưu trữ của mình với:

git clone https://user@bitbucket.org/user/repo.git

Thêm một điều khiển

Trong khi các luồng công việc Git khác sử dụng một điều khiển từ xa gốc duy nhất trỏ đến kho lưu trữ trung tâm, thì luồng công việc Forking yêu cầu hai điều khiển từ xa một cho kho lưu trữ chính thức và một cho kho lưu trữ phía máy chủ cá nhân của nhà phát triển. Mặc dù bạn có thể gọi những điều khiển từ xa này bất cứ điều gì bạn muốn, nhưng một quy ước chung là sử dụng nguồn gốc làm điều khiển từ xa cho kho lưu trữ của bạn (điều này sẽ được tạo tự động khi bạn chạy git clone) và ngược dòng cho kho lưu trữ chính thức.

git remote add upstream https://bitbucket.org/maintainer/repo

Bạn sẽ cần phải tự tạo điều khiển từ xa ngược dòng bằng cách sử dụng lệnh trên. Điều này sẽ cho phép bạn dễ dàng cập nhật kho lưu trữ cục bộ của mình khi dự án chính thức tiến triển. Lưu ý rằng nếu kho lưu trữ ngược dòng của bạn đã bật xác thực (nghĩa là nó không phải là nguồn mở), bạn sẽ cần cung cấp tên người dùng, như vậy:

git remote add upstream https://user@bitbucket.org/maintainer/repo.git

Điều này yêu cầu người dùng cung cấp mật khẩu hợp lệ trước khi nhân bản hoặc lấy từ cơ sở mã chính thức.

Làm việc trong một chi nhánh: thực hiện và thúc đẩy thay đổi

Trong bản sao lưu trữ cục bộ của nhà phát triển, họ có thể chỉnh sửa mã, cam kết thay đổi và tạo các nhánh giống như trong các quy trình công việc Git khác:

git checkout -b some-feature
# Edit some code
git commit -a -m "Add first draft of some feature"

Tất cả các thay đổi của họ sẽ hoàn toàn riêng tư cho đến khi họ đẩy nó vào kho lưu trữ công khai của họ. Và, nếu dự án chính thức được chuyển tiếp, họ có thể truy cập các cam kết mới với git pull:

git pull upstream master

Vì các nhà phát triển nên làm việc trong một nhánh tính năng chuyên dụng, điều này thường sẽ dẫn đến một sự hợp nhất nhanh chóng.

Yêu cầu kéo

Khi một nhà phát triển sẵn sàng chia sẻ tính năng mới của họ, họ cần thực hiện hai điều. Đầu tiên, họ phải làm cho đóng góp của họ có thể truy cập được cho các nhà phát triển khác bằng cách đẩy nó vào kho lưu trữ công cộng của họ. Điều khiển từ xa gốc của chúng đã được thiết lập, vì vậy tất cả những gì chúng cần phải làm là như sau:

git push origin feature-branch

Điều này phân kỳ từ các quy trình công việc khác ở chỗ điểm gốc từ xa đến kho lưu trữ phía máy chủ cá nhân của nhà phát triển, không phải là cơ sở mã chính.

Thứ hai, họ cần thông báo cho người bảo trì dự án rằng họ muốn hợp nhất tính năng của họ vào cơ sở mã chính thức. Bitbucket cung cấp một nút Yêu cầu kéo theo kiểu kéo dài dẫn đến một biểu mẫu yêu cầu bạn chỉ định nhánh nào bạn muốn hợp nhất vào kho lưu trữ chính thức. Thông thường, bạn sẽ muốn tích hợp featurechi nhánh của mình vào chi nhánh từ xa ngược dòng master.

Tóm lược

Tóm lại, Dòng công việc Forking thường được sử dụng trong các dự án nguồn mở công cộng. Forking là một git clonehoạt động được thực hiện trên một bản sao máy chủ của một dự án repo. Luồng công việc Forking thường được sử dụng cùng với dịch vụ lưu trữ Git như Bitbucket. Một ví dụ cấp cao về Quy trình làm việc của Forking là:

1. Bạn muốn đóng góp cho một thư viện mã nguồn mở được lưu trữ tại bitbucket.org/userA/open-project
2. Sử dụng Bitbucket, bạn tạo một nhánh của repo thành bitbucket.org/YourName/open-project
3. Trên hệ thống cục bộ của bạn, bạn thực thi git clonetrên https://bitbucket.org/YourName/open-project để lấy bản sao cục bộ của repo
4. Bạn tạo một featurechi nhánh mới trong repo địa phương của bạn
5. Công việc được hoàn thành để hoàn thành tính năng mới và git commitđược thực hiện để lưu các thay đổi
6. Sau đó, bạn đẩy featurechi nhánh mới vào repo rẽ nhánh từ xa của bạn
7. Sử dụng Bitbucket, bạn mở ra một yêu cầu kéo cho chi nhánh mới so với repo ban đầu tại bitbucket.org/userA/open-project

Quy trình làm việc của Forking giúp người duy trì dự án mở kho lưu trữ cho các đóng góp từ bất kỳ nhà phát triển nào mà không phải quản lý cài đặt ủy quyền theo cách thủ công cho từng người đóng góp. Điều này cung cấp cho người bảo trì nhiều hơn một quy trình làm việc kiểu "kéo". Được sử dụng phổ biến nhất trong các dự án nguồn mở, Dòng công việc Forking cũng có thể được áp dụng cho quy trình công việc của doanh nghiệp tư nhân để cung cấp quyền kiểm soát có thẩm quyền hơn đối với những gì được sáp nhập vào một bản phát hành. Điều này có thể hữu ích trong các nhóm có Người quản lý triển khai hoặc chu kỳ phát hành nghiêm ngặt.