Tôi vừa bắt đầu sử dụng git và trong khi tương đối dễ tìm ra cách làm điều gì đó với git, tôi đang gặp khó khăn khi tìm ra khi làm điều gì đó với git.Khi nào chi nhánh trong git?
Ví dụ: khi nào thì thường chi nhánh một dự án?
Tôi đã nghĩ đến việc phân nhánh từng phiên bản của một dự án hiện tại và khi nó hoàn thành việc sáp nhập nó với chủ - đó là thực tế phổ biến?
Tôi chắc chắn có những người làm những việc khác với những gì tôi làm. Tuy nhiên, đây là những gì tôi làm theo:
Tôi không chắc chắn ý bạn là gì khi phân nhánh từng phiên bản của dự án hiện tại.
Dù sao, git khuyên bạn nên tạo 'nhánh chủ đề'. Theo 'nhánh chủ đề', điều đó có nghĩa là bạn tạo một chi nhánh khi bạn đang làm việc trên một tính năng/lỗi. Giả sử tôi đang làm việc trên jQueryUI và tôi đã được yêu cầu thêm một tính năng vào Lịch jQuery cho phép người dùng chỉ định các ngày không thể chọn được.
Nếu tôi ở chi nhánh có tên chính, tôi sẽ tạo chi nhánh địa phương có tên là nhánh 'SpecifyDateExclusion' và bắt đầu thực hiện thay đổi của tôi. Bất kỳ và tất cả các mã liên quan đến tính năng này sẽ đi vào chi nhánh này.
master
|
|
|___ SpecifyDateExclusion
Trong khi tôi đang làm việc trên tính năng này, một báo cáo lỗi cho biết lịch đã bị hỏng trong Opera 10 và lỗi này cần được khắc phục ngay bây giờ. Tôi quay lại nhánh chính của mình và tạo một nhánh khác có tên Opera10BugFix và bắt đầu sửa lỗi trong đó.
master
|
|
|___ SpecifyDateExclusion
|
|
|___ Opera10BugFix
Rất sớm, bạn có thể có các chi nhánh như
master
|
|
|___ SpecifyDateExclusion
|
|___ Feature1
|
|___ Feature2
|
|___ Feature3
|
|___ Opera10BugFix
|
|___ BugFix1
|
|___ BugFix2
lợi thế bạn có thể yêu cầu là gì?
Ưu điểm là tính linh hoạt mà nó mang lại cho tôi trong khi chuẩn bị bản phát hành của tôi. Giả sử bản phát hành tiếp theo của tôi chủ yếu là về sửa lỗi.
Tôi sẽ tạo nhánh mới có tên 'InterimBugFix' từ trang cái và hợp nhất tất cả các nhánh sửa lỗi của tôi.
Nếu tôi muốn tạo kết hợp phát hành lỗi/tính năng, tôi sẽ tạo một chi nhánh có tên 'NextVersion' từ chính và hợp nhất các chi nhánh/chi nhánh sửa lỗi của tôi.
Git cực kỳ mạnh mẽ về cách bạn quản lý các chi nhánh này và nếu bạn có thể tưởng tượng điều gì đó, Git sẽ cho phép bạn làm điều đó.
Có nhiều câu trả lời cho điều này tùy thuộc vào "chiến lược phân nhánh" của bạn. 2 đơn giản nhất (theo kinh nghiệm của tôi) là các nhánh nhiệm vụ/tính năng và các nhánh phát hành. Mà bạn sử dụng sẽ phụ thuộc vào cách chu kỳ phát hành của bạn hoạt động, trong số những thứ khác.
Nếu bạn đang tích hợp và phát hành liên tục thì các nhánh nhiệm vụ/tính năng có ý nghĩa, khi chúng rời khỏi "chính" (thân trong VCS khác) ở trạng thái tương đối ổn định, làm cho bản phát hành trở nên dễ dàng. Nhưng nếu bạn có chu kỳ phát hành có cấu trúc hơn, có thể các nhánh phát hành sẽ có ý nghĩa hơn vì chúng có thể được sử dụng để xác định kỹ hơn những gì được thêm vào mỗi bản phát hành. Tất nhiên, một chiến lược lai cũng khả thi.
Tôi thường sử dụng các nhánh nhiệm vụ/tính năng, do đó mọi lỗi hoặc yêu cầu tính năng đều được phân nhánh. Sau đó, làm việc trên và, khi hoàn thành, sáp nhập trở lại vào tổng thể.
Điều tốt nhất về Git là nó không ép buộc bất kỳ quyết định nào đối với bạn. Điều tồi tệ hơn về Git là nó không ép buộc bất kỳ quyết định nào đối với bạn.
Quy trình làm việc của bạn hoàn toàn tùy thuộc vào bạn. Bạn có ý định cộng tác hay bạn đang phát triển độc lập? Bạn có một thời gian ngắn hoặc dài giữa các bản phát hành? Những ràng buộc này có thể giúp xác định một quy trình làm việc phù hợp.
Tôi làm việc trong một nhóm nhỏ gồm 4 nhà phát triển với chu kỳ lặp lại hai tuần. Vào đầu chu kỳ, chúng tôi đồng ý về phạm vi và phát triển chống lại chủ. Bất cứ điều gì mà chúng tôi mong đợi vượt quá hai tuần được chuyển (hoặc bắt đầu cuộc sống) trong một chi nhánh (Điều này không xảy ra thường xuyên, phạm vi của chúng tôi là chặt chẽ).
Vào cuối chu kỳ hai tuần, chúng tôi thực hiện QA, thẻ và bản phát hành của chúng tôi. Bắt đầu chu kỳ tiếp theo, các nhánh khác được sáp nhập trở lại làm chủ.
Nếu bạn cần vá bản phát hành, chúng tôi tạo chi nhánh, cam kết, QA, thẻ và phát hành.
Đối với bất kỳ thử nghiệm nào, chúng tôi thường sẽ tạo một chi nhánh mới và giữ nó tách biệt khỏi nhánh cho đến khi nó phù hợp để được hợp nhất hoặc bị loại bỏ.
Nói tóm lại, các chi nhánh nhóm chúng tôi khi:
công việc của chúng tôi là rất tập trung, và có lẽ không điển hình của nhiều người dùng Git. Không đúng hay sai, nó chỉ là chọn những gì phù hợp nhất.
"phát triển chống lại chủ" - điều đó có nghĩa là bạn phát triển bằng cách sử dụng nhánh chính? – LDK
Đúng vậy. –
Điều này rất quan trọng: Git không có Quy trình kiểm soát phiên bản. Thay vào đó, nó là bộ công cụ xây dựng quy trình kiểm soát phiên bản. Và cũng giống như với Bộ công cụ xây dựng LEGO, việc đặt mọi thứ lại với nhau là rất nhiều công việc nhàm chán, khó khăn, nhàm chán, nhưng kết quả sẽ là * tuyệt vời *, bởi vì nó là * của bạn *, * bạn * xây dựng nó bằng chính bạn tay, và nó được điều chỉnh chính xác theo nhu cầu của bạn. Nói hay lắm! –
Trong Phát triển ứng dụng Web, chúng tôi làm điều này:
Chúng tôi duy trì một chi nhánh hoang sơ được gọi là "sản xuất". Nó chứa mã tồn tại trên các trang web trực tiếp.
Bất kỳ thay đổi nào xảy ra trong các nhánh Nhiệm vụ. Vì vậy, bạn có thể thấy một nhánh Task-13923-add-feature-x. Các chi nhánh này là được tạo ra từ chi nhánh sản xuất và chi nhánh sản xuất phải được hợp nhất thành trước khi sáp nhập vào sản xuất (vì vậy nó luôn luôn là một chuyển tiếp nhanh, không có xung đột tiềm ẩn).
Mọi người khác đều hợp nhất chi nhánh "Sản xuất" theo thời gian vào chi nhánh nhiệm vụ của họ để luôn cập nhật.
Khi nghi ngờ, chi nhánh. Chi nhánh rẻ, và thông tin từ các chi nhánh mới có thể dễ dàng được chuyển đến các chi nhánh cũ.Khi một chi nhánh đã vượt qua tính hữu ích của nó, nó có thể dễ dàng bị giết.
"Để cho nhánh chính sạch sẽ bằng cách không làm cho nó trở thành công việc đang tiến hành (WIP)" Tôi thích ý tưởng đó. – LDK