Bất cứ khi nào một dự án mới bắt đầu, thường bắt đầu bằng cách cam kết thành thạo cho đến khi bạn có một cái gì đó "ổn định", và sau đó bạn bắt đầu làm việc trong các chi nhánh.
Ít nhất, đây là cách tôi thường làm. Có cách nào để bắt đầu ngay lập tức các chi nhánh từ lần cam kết thứ hai không? Liệu nó có ý nghĩa để làm theo cách này? Rõ ràng, "Cam kết ban đầu" sẽ luôn là chủ, nhưng sau đó, khi nào tôi sẽ biết đó là thời điểm thích hợp để bắt đầu tạo chi nhánh cho các tính năng mới?
Câu trả lời:
Ngay.
Điều quan trọng là câu hỏi chính sách dành cho Master là gì. Với git, thông thường, chính sách chi nhánh trên Master là bản phát hành ổn định có thể xây dựng . Đôi khi, Master là 'đường chính' nơi các nhánh được tạo và hợp nhất trước khi sáp nhập vào nhánh Phát hành. Đây là hai cách tiếp cận vai trò / chính sách khác nhau.
Nó thường là một nguồn lỗi để mọi người thay đổi vai trò hoặc chính sách của một phần chi nhánh thông qua dự án. Nhà phát triển solo sẽ dễ dàng truyền đạt những thay đổi này đến những người đóng góp hơn, nhưng cố gắng để hàng tá lập trình viên nhận ra "Master hiện ở mức 1.0, vui lòng phân nhánh các tính năng thay vì mọi người đẩy mạnh vào nó"
Tôi đã chạm vào cách tiếp cận chính sách ở trên. Chính sách cho Master là nó là bản phát hành ổn định có thể xây dựng . Kiểm tra các thay đổi gia tăng nhỏ vào điều này có nghĩa là bạn không có thứ gì đó có thể xây dựng ổn định mọi lúc. Không kiểm tra các thay đổi nhỏ đi ngược lại "rất nhiều đăng ký nhỏ (nhưng hoàn thành)" có xu hướng là chính sách tốt nhất (và được khuyến khích bằng cách phân nhánh dễ dàng).
Từ góc độ dựa trên vai trò, bạn đã bắt đầu với vai trò chính, phát hành, bảo trì và phát triển, và sau đó một số điểm cho thấy vai trò phát triển và bảo trì chuyển sang các chi nhánh. Điều này một lần nữa có nghĩa là một sự thay đổi trong những gì được phép trên chủ và có thể gây nhầm lẫn cho những người đóng góp về nơi mọi thứ thuộc về. Nó cũng có thể (hơi) nhầm lẫn lịch sử chi nhánh, khuyến khích các cam kết lớn có nghĩa là hợp nhất lớn hơn và khó hiểu hơn.
Khóa vai trò và chính sách trên các chi nhánh đơn giản và nhất quán ngay từ đầu.
"Chi nhánh thay đổi chính sách" này có thể được nhìn thấy trong Mô hình phân nhánh . Ý tưởng của mỗi chi nhánh có vai trò, có thể được đọc trong Chiến lược phân nhánh SCM nâng cao . Cả hai đều là những bài đọc rất tốt.
Chủ yếu có hai tình huống mà bạn thường muốn bắt đầu làm việc với các chi nhánh:
khi bạn hoặc nhóm của bạn phải bắt đầu một tính năng mới có cơ hội nhỏ nhất không được thêm vào bản phát hành tiếp theo (có thể là bản phát hành đầu tiên từng có), sau đó bắt đầu phát triển trong một nhánh tính năng riêng biệt
khi bạn phải cung cấp các bản sửa lỗi cho các lỗi nghiêm trọng cho bản phát hành mới nhất và bạn muốn tạo một bản phát hành lỗi mới chỉ chứa các bản sửa lỗi đó, nhưng không có các tính năng mới được phát triển (và có thể không ổn định)
Đối với những quyết định như vậy, tôi nghĩ thật hữu ích khi luôn nghĩ về "tính năng mới" hoặc "lỗi", kể từ khi bạn có phiên bản đầu tiên có thể biên dịch / chạy được của chương trình.
Michael Feathers liệt kê bốn lý do để thay đổi trong cuốn sách nổi tiếng của mình, nhưng tôi cũng sẽ đặt "tối ưu hóa tài nguyên" dưới "nhánh tính năng mới" (đối với tính năng phi chức năng) và "cải thiện thiết kế" nhiều lần trong "nhánh tính năng mới". , vì IMHO không bao giờ nên cải thiện thiết kế khi điều này không nhằm mục đích làm cho việc thực hiện một tính năng cụ thể dễ dàng hơn.
Nếu bạn theo git-Flow - và, thật lòng mà nói, tôi nghĩ bạn sẽ điên nếu bạn sử dụng Git và không sử dụng mô hình phân nhánh đó - thì bạn không bao giờ nên cam kết cho masterđến khi bạn thực sự sẵn sàng để phát hành công khai.
Cam kết đầu tiên của bạn masterphải là một kho lưu trữ trống. Cam kết tiếp theo của bạn masterphải là một cam kết hợp nhất từ developchi nhánh hoặc chi nhánh phát hành tạm thời và nó phải ổn định, được thử nghiệm và sẵn sàng để triển khai (nếu là ứng dụng) hoặc phân phối công khai (nếu là thư viện).
Có những mô hình phân nhánh khác cho Git, nhưng hầu hết trong số họ đã có nguồn gốc từ các mô hình SCM tập trung lớn tuổi và có thể dẫn đến những vấn đề nghiêm trọng trong một môi trường DVCS. Bạn không thực sự phải sử dụng tiện ích mở rộng dòng git và bạn không nhất thiết cần tất cả các nhánh phát hành / hotfix / tính năng đó, nhưng các bộ xương trần là developvà master, và mã không ổn định đi vào develop.
master. Hãy nhớ rằng đó masterkhông phải là điều gì đặc biệt đối với git, nó không cần phải ở đó. Bạn chỉ có thể có một nhánh phát triển cho đến khi bạn muốn phát hành.
Neal Ford của Th Thinkworks ủng hộ việc sử dụng các tính năng chuyển qua phân nhánh để tránh vấn đề "hợp nhất địa ngục". Hãy xem xét trường hợp hai lập trình viên hợp nhất hàng ngày từ nhánh chính và một trong những thay đổi đáng kể trong vài tuần và sau đó cam kết. Các lập trình viên khác rất có thể kết thúc trong địa ngục hợp nhất. Để tránh vấn đề này, Ford khuyên bạn nên "mang nỗi đau về phía trước" (một thuộc tính nhanh nhẹn nổi tiếng) bằng cách chỉ có một chi nhánh và cam kết với nó hàng ngày. Tính năng bổ sung được thêm vào thông qua các tính năng bật tắt tính năng này cho đến khi nó được kiểm tra đầy đủ.
Phương pháp này dường như hoạt động tốt nhất trong môi trường thực hiện phân phối liên tục vì các vấn đề với cam kết sẽ bị bắt ngay lập tức.
Đã hai năm kể từ câu trả lời cuối cùng cho câu hỏi này và tôi nghĩ bây giờ câu chuyện đã thay đổi. Đối với tôi câu trả lời là "Bất cứ khi nào bạn sử dụng kiểm soát mã nguồn để theo dõi các phiên bản."
Để giải thích, những ngày này theo dõi các phiên bản dự án với kiểm soát mã nguồn không phải lúc nào cũng hoạt động. (ví dụ: sử dụng npm để quản lý sự phụ thuộc và chỉ định các phiên bản ngữ nghĩa với '^') Trong trường hợp đó, các tạo phẩm của dự án thay đổi mỗi khi quá trình xây dựng xảy ra, không cần thiết tương ứng với thay đổi mã nguồn mỗi lần. Để xử lý loại thách thức mới này, một số nhóm chọn đã xây dựng 'tạo tác' được lưu trong hệ thống điều khiển tạo tác (ví dụ: JFrog Artifactory) cho các phiên bản dự án theo dõi.
Rõ ràng khi bạn đã có kiểm soát phiên bản tạo tác, bạn sẽ không kéo "mã sản xuất" từ chi nhánh GIT và xây dựng / triển khai sang sản xuất, thay vào đó bạn tham khảo hệ thống kiểm soát tạo tác cho các phiên bản có thể chạy trực tiếp để triển khai. Trong những trường hợp như vậy, khái niệm 'nhánh phát hành' đột nhiên mất đi ý nghĩa của nó. Và bất cứ khi nào nhóm của bạn quyết định không liên kết chi nhánh git với phiên bản phát hành, cam kết / đẩy trực tiếp để làm chủ trở thành một lựa chọn âm thanh một lần nữa: nó là nhánh mặc định bất cứ khi nào repo được sao chép, do đó tự động được cung cấp ngữ nghĩa được chấp nhận rộng rãi và được truyền đạt tốt thay đổi. Tuy nhiên, như câu trả lời được chấp nhận cho thấy, có lẽ bạn nên đi đầu với vai trò gán cho các nhánh bao gồm chủ và chỉ sử dụng các nhánh đó cho các vai trò cụ thể đó.
Cuối cùng, tôi sẽ tiến thêm một bước và đề nghị sử dụng tổng thể làm nhánh phát triển trong các dự án chỉ với một số ủy viên chính. Đó là trường hợp của nhóm của tôi và có lẽ giống với hầu hết các cửa hàng dịch vụ vi mô. Cam kết với chủ sẽ loại bỏ quá trình giao tiếp của các thay đổi và có khả năng tránh 'hợp nhất địa ngục' khi làm việc trên các tính năng trên nhiều lần chạy nước rút. Hơn nữa, mã trong nhánh chính thậm chí không phải 'hoạt động', quá trình xây dựng / kiểm tra tự động sẽ cho bạn biết điều gì đã sai và dù sao cũng dễ dàng kiểm tra lịch sử git và liên hệ với tác giả đã phá vỡ bản dựng / kiểm tra :-)
Tôi sẽ có một vị trí cấp tiến: chi nhánh trên mọi ý tưởng. Đầu tiên trong các chi nhánh git là giá rẻ, chi phí chính của một chi nhánh là ghi nhớ những gì được dành cho. Tôi cũng đồng ý rằng cam kết đầu tiên để làm chủ là một ứng cử viên phát hành. Tôi khuyên bạn nên bắt đầu với một bằng chứng của chi nhánh khái niệm. Khi bạn đã chứng minh khái niệm của mình, bạn có thể hợp nhất nó với nhánh phát triển trống hoặc viết lại tùy thuộc vào mức độ thử đầu tiên của bạn. từ thời điểm này, bạn phân nhánh từ phát triển cho mọi lỗi, tính năng, trừu tượng, v.v.