Tôi tò mò muốn biết thực tiễn tốt nhất hiện hành là gì. Các cam kết git nên được thi hành sao cho dự án ở trạng thái hoạt động (xây dựng đúng, tất cả các bài kiểm tra vượt qua, v.v.), hoặc cam kết mã bị hỏng OK?
Ví dụ: nếu bạn từ bỏ yêu cầu này, bạn có thể linh hoạt hơn với các cam kết (sử dụng chúng như các khối logic, mặc dù ứng dụng không ở trạng thái hoạt động, v.v.). Tuy nhiên, nếu bạn thi hành nó, bạn sẽ có được sự linh hoạt để có thể chọn bất kỳ cam kết nào được đưa ra sau này ...
Câu trả lời:
Tôi thường tuân theo quy tắc này:
masterchi nhánh phải rời khỏi dự án trong trạng thái làm việc;developnhánh chính nên để dự án ở trạng thái làm việc (và nó phải xây dựng ít nhất);Sử dụng bản sao cục bộ của kho lưu trữ cho bất cứ điều gì làm cho bạn thoải mái trong khi phát triển.
Tôi cam kết mã bị hỏng thường xuyên và khi tôi sẵn sàng cung cấp mã cho các nhà phát triển khác, tôi sử dụng một tính năng tuyệt vời:
git rebase -i HEAD~4
Điều này cho phép tôi nén trung gian của mình (trong trường hợp này là 4 trong số chúng), có thể bị hỏng, cam kết thành một cam kết tốt. Bạn sẽ được trình bày với một trình soạn thảo cho phép bạn chọn cách các cam kết đó được nén. Thông thường, tôi đã đánh dấu lần cam kết đầu tiên là 'chọn' cam kết và đánh dấu 'quả bí' của người khác.
Sau đó, tôi có thể thúc đẩy một cam kết nguyên tử đó, hoặc trên thực tế những gì tôi làm nếu tính năng mới của tôi thực sự sẵn sàng, là sử dụng 'git cvsexportcommit' để đưa tác phẩm của tôi vào repo CVS hiện có.
rebaseđó khá gây tranh cãi: Thou Shalt Not Lie: git rebase, sửa đổi, squash, và những lời nói dối khác
Hai trong số những lợi ích tuyệt vời của kiểm soát phiên bản là nó cho phép các nhà phát triển khôi phục các phiên bản trước đó của công việc và cho phép các nhà phát triển thử các thay đổi khác nhau, có thể xung đột cùng một lúc. Kiểm soát phiên bản cho phép các nhà phát triển tự do thử các ý tưởng có thể thất bại.
Các nhà phát triển nên được khuyến khích để phân nhánh và cam kết công việc của họ thường xuyên, cho dù nó có xây dựng hay không. Từ chối cho phép các cam kết phân nhánh hoặc bị hỏng là cản trở các nhà phát triển của bạn và sử dụng kém các công cụ của bạn.
Điều đó nói rằng, đó là một thực tiễn tuyệt vời để yêu cầu cam kết với các chi nhánh nhất định luôn được xây dựng. Nhiều tổ chức đi xa hơn và cấm các nhà phát triển cam kết với một số chi nhánh nhất định. Ví dụ: các nhà phát triển có thể được yêu cầu hợp nhất công việc của họ trở lại nhánh phát triển chính, nhưng chỉ nhà phát triển chính mới có thể được phép hợp nhất những thay đổi đó từ phát triển sang nhánh sản xuất.
Chúng tôi thường theo cả hai cách tiếp cận. Trong kho lưu trữ cục bộ trên hộp của tôi, tôi cam kết tất cả những gì tôi muốn. Khi đến lúc phải chuyển sang repo trung tâm của đội tôi, trước tiên tôi thực hiện một rebase tương tác và đưa các cam kết của mình vào các gói logic. Thông thường, một cam kết cho mỗi câu chuyện, với id câu chuyện (hoặc khiếm khuyết) được bao gồm trong nhận xét (chúng tôi là một cửa hàng dựa trên kanban).
Sau đó, trên bản repro trung tâm của chúng tôi, chúng tôi có Jenkins lắng nghe và nó khởi động bản dựng và tất cả các bài kiểm tra. Nếu bất cứ điều gì thất bại, chúng tôi thường cho phép mọi người thử và sửa lỗi bản dựng với một cam kết khác. Nếu nó không được tốt, việc hoàn nguyên cam kết bị lỗi là điều dễ thực hiện.
Vì git commitchỉ ảnh hưởng đến bản sao kho lưu trữ của riêng bạn, nên không cần dự án ở trạng thái hoạt động sau mỗi lần xác nhận. Hãy tiếp tục và cam kết bất cứ khi nào bạn muốn lưu công việc bạn đã làm. Có lẽ một nguyên tắc nhỏ là một cam kết phù hợp khi bạn có thể mô tả những thay đổi bạn đã thực hiện trong thông điệp cam kết.
Nó git pushảnh hưởng đến những người dùng khác. Chính sách cho những gì nên được thúc đẩy là một vấn đề để nhóm phát triển của bạn quyết định. Việc đẩy mã không hoạt động lên nhánh chính có lẽ là không, nhưng có lẽ không nên đẩy mã không hoạt động lên một nhánh riêng (miễn là không ai khác sẽ cố gắng xây dựng từ nhánh đó).
Chúng tôi đang sử dụng luồng git tại nơi làm việc và chúng tôi cũng cam kết mã chưa hoàn thành hoặc bị hỏng - vì nó chỉ rơi vào các nhánh địa phương hoặc từ xa được thực hiện cho vấn đề cụ thể đó. Chỉ khi tác vụ kết thúc, nó sẽ được hợp nhất vào nhánh phát triển (đại diện cho bản sao làm việc hiện tại trong mô hình dòng chảy). Bằng cách đó, chúng tôi cũng có thể hợp tác về mã (một số đồng nghiệp ở thành phố khác, bao gồm cả người dẫn đầu dự án) và giúp đỡ lẫn nhau.
Tuy nhiên, nó phụ thuộc vào cách bạn và đồng nghiệp đang nghĩ. Cá nhân, tôi nghĩ rằng các cam kết chi nhánh là ổn, vì bạn có thể cần một lịch sử thay đổi với một bộ tái cấu trúc lớn hơn hoặc tương tự.
Cuối cùng, tùy thuộc vào bạn và những người bạn làm việc cùng hoặc vì, vì git không áp đặt bất kỳ quy tắc nào.
Thực hành của tôi là để tránh bất kỳ cam kết nào cố ý làm cho hệ thống tồi tệ hơn đáng kể. Mỗi cam kết nên được tái cấu trúc hoặc thực hiện một số yêu cầu. Nếu tôi thực hiện một cam kết xấu và phát hiện ra nó trước khi tôi đẩy nó thì tôi sẽ sửa đổi hoặc phản đối để loại bỏ nó khỏi lịch sử.
Tôi nghĩ rằng điều này làm cho việc đọc nhật ký git trong yêu cầu kéo dễ dàng hơn, vì mỗi cam kết sẽ tự đứng vững như là một cấu trúc lại hoặc thực hiện một số yêu cầu. Thêm mã chết sẽ được đưa vào cuộc sống trong tương lai gần được tính là tái cấu trúc. Đây là những "khối logic" của tôi.
Bạn vẫn có thể linh hoạt với cách bạn cấu trúc các cam kết của mình. Chẳng hạn, bạn có thể viết các bài kiểm tra trước nhưng đánh dấu tất cả chúng là bỏ qua trong lần xác nhận đầu tiên, để bộ kiểm tra của bạn không báo cáo lỗi, và sau đó bỏ qua chúng khi thực hiện xong.
Giả sử bạn đang sử dụng các chi nhánh và thông điệp cam kết tốt, cam kết mã "bị hỏng" trên một chi nhánh với thông điệp cam kết rõ ràng sẽ ổn, miễn là nhóm của bạn đồng ý rằng đó là một cách làm việc tốt.
Bạn cũng sao chép kho lưu trữ git cục bộ, vì vậy bạn cũng có thể có một nhánh cục bộ với các xác nhận cục bộ không được đẩy về nguồn gốc nơi bạn đang thực hiện mã "bị hỏng" khi bạn đi cùng; sau đó, khi bạn có tất cả hoạt động, bạn có thể hợp nhất nó vào chủ hoặc một số nhánh khác và xóa nhánh làm việc của bạn với các cam kết "bị hỏng" khác nhau.
Đối với tôi, tất cả là về việc đồng ý với nhóm của bạn những gì được chấp nhận; một số đội sẽ không chấp nhận mã bị hỏng ngay cả trên một nhánh, những đội khác thì không.