Có bao giờ OK để cam kết mã không làm việc?

Có phải là ý tưởng tốt để yêu cầu chỉ cam kết mã làm việc?

Cam kết này không cần phải để kho lưu trữ ở trạng thái hoạt động như:

• ... Chúng tôi đang trong giai đoạn thiết kế ban đầu, mã chưa ổn định.
• ... Bạn là nhà phát triển duy nhất trong dự án. Bạn biết tại sao mọi thứ không hoạt động. Hơn nữa, bạn sẽ không dừng công việc của bất kỳ ai bằng cách cam kết mã bị hỏng.
• ... mã hiện không hoạt động. Chúng tôi sẽ tạo ra một sự thay đổi lớn cho nó. Chúng ta hãy cam kết, để có một điểm trở lại nếu mọi thứ trở nên xấu xí.

• ... chuỗi này dài, không có vấn đề gì nếu mã bị hỏng tồn tại trong nhánh cục bộ. I E

  1. Tập tin có sẵn
  2. khu vực tổ chức
  3. cam kết tại chi nhánh địa phương
  4. cam kết trong chi nhánh tính năng cá nhân từ xa
  5. hợp nhất với developchi nhánh từ xa
  6. hợp nhất với masterchi nhánh từ xa
  7. hợp nhất với releasechi nhánh từ xa

• ... Cam kết sớm, cam kết thường xuyên.

Vì vậy, trong câu hỏi được liên kết ở trên, phần lớn các câu trả lời nói rằng việc cam kết mã không thể biên dịch là không có vấn đề trong các nhánh cục bộ và tính năng. Tại sao? Giá trị của một cam kết bị phá vỡ là gì?

Đã thêm: Có một vài ý kiến ​​được bình chọn cao, nói rằng trên một địa phương, người ta có thể làm bất cứ điều gì mình muốn. Tuy nhiên, tôi không quan tâm đến khía cạnh kỹ thuật của câu hỏi. Thay vào đó, tôi muốn tìm hiểu các thực tiễn tốt nhất - những thói quen, rằng những người đã làm việc nhiều năm trong ngành, có năng suất cao nhất.

Tôi ngạc nhiên với số lượng lớn các câu trả lời tuyệt vời! Họ đưa tôi đến kết luận rằng tôi không đủ giỏi trong việc sử dụng các chi nhánh để tổ chức mã của mình.

Một trong những triết lý phân nhánh (phần Phát triển Chiến lược phân nhánh và Chính sách quy tắc trong Chiến lược phân nhánh SCM nâng cao - cũng đọc các thực tiễn tốt nhất của Perforce , đó là pdf nhưng đi sâu vào một số chi tiết khác) là bạn phân nhánh về chính sách không tương thích.

Chính sách về dòng mã xác định việc sử dụng hợp pháp và đăng ký được phép cho dòng mã và là hướng dẫn sử dụng thiết yếu cho SCM của dòng mã. Ví dụ: chính sách của một bộ luật phát triển nên nói rằng nó không được phát hành; tương tự như vậy, chính sách của một dòng mã phát hành nên hạn chế các thay đổi đối với các sửa lỗi đã được phê duyệt. Chính sách này cũng có thể mô tả cách ghi lại các thay đổi đang được kiểm tra, cần xem xét lại những gì, yêu cầu kiểm tra nào và kỳ vọng về tính ổn định của dòng mã sau khi đăng ký. Chính sách là một thành phần quan trọng cho quy trình phát triển phần mềm có thể thực thi được lập thành tài liệu và một dòng mã không có chính sách, theo quan điểm của SCM, nằm ngoài tầm kiểm soát.

(từ Thực tiễn tốt nhất của Perforce)

Giả sử bạn có các nhánh 'phát hành' (hoặc 'chính') từ đó bản phát hành được tạo và 'thân cây' (hoặc 'dev') nơi các nhà phát triển kiểm tra mã làm việc. Đây là những chính sách của các chi nhánh. Lưu ý 'mã làm việc' là một phần của chính sách nhánh 'dev', người ta không bao giờ nên cam kết mã bị hỏng với nhánh dev. Thường có những thứ như máy chủ CI được nối với các nhánh này và kiểm tra mã bị hỏng thành dev có thể làm rối nhánh của mọi người và phá vỡ bản dựng.

Tuy nhiên, có những lúc thích hợp để kiểm tra một phần mã không hoạt động. Trong những trường hợp này, người ta nên phân nhánh - một chính sách không tương thích với trung kế. Trong nhánh mới này, người ta có thể quyết định chính sách ('mã bị hỏng là ok') và sau đó cam kết mã với nó.

Có một quy tắc đơn giản để xác định xem một dòng mã có nên được phân nhánh hay không: nó nên được phân nhánh khi người dùng của nó cần các chính sách đăng ký khác nhau. Ví dụ: nhóm phát hành sản phẩm có thể cần chính sách đăng ký thực thi kiểm tra nghiêm ngặt, trong khi đó nhóm phát triển có thể cần chính sách cho phép kiểm tra thường xuyên các thay đổi được kiểm tra một phần. Chính sách phân kỳ này gọi cho một nhánh mã. Khi một nhóm phát triển không muốn thấy một nhóm khác

(từ Thực tiễn tốt nhất của Perforce)

Nhận ra rằng điều này đến từ một máy chủ trung tâm dựa trên SCM với tư duy mạnh mẽ của công ty. Ý tưởng cốt lõi vẫn tốt. Chúng thường được nghĩ đến ngầm - bạn không kiểm tra mã dev chưa được kiểm tra vào nhánh phát hành. Đó là một chính sách.

Vì vậy, chi nhánh, nói rằng chi nhánh này có thể có mã bị hỏng và cam kết đi.

Một trong những triết lý được Linus Torvalds đề xuất là lập trình sáng tạo nên giống như một loạt các thí nghiệm. Bạn có một ý tưởng, và làm theo nó. Nó không phải lúc nào cũng hoạt động, nhưng ít nhất bạn đã thử nó. Bạn muốn khuyến khích các nhà phát triển thử các ý tưởng sáng tạo và để thực hiện điều đó, phải rẻ khi thử nghiệm thử nghiệm đó và giá rẻ để phục hồi. Đây là sức mạnh thực sự của git cam kết là rất rẻ (nhanh chóng và dễ dàng). Nó mở ra mô hình sáng tạo này cho phép các nhà phát triển thử những thứ mà họ có thể không có. Đây là sự giải phóng của git.

Có, miễn là nó không phải là một nhánh phát hành.

Trong các nhánh cá nhân, mọi thứ diễn ra và sau đó có thể bị loại bỏ nếu thử nghiệm không hoạt động. Đó là một trong những lợi ích chính của DVCS: tự do

Giá trị của việc cam kết mã bị hỏng?: Cộng tác và thử nghiệm

Vâng, nó ổn và nó là thứ tôi làm rất nhiều.

Điểm của việc cam kết mã không thể biên dịch (ít nhất là trong các nhánh) là đôi khi mã của bạn đang được thực hiện, nhưng công việc được thực hiện cho đến nay rất đáng để lưu và / hoặc chia sẻ với người khác

Thực tiễn của tôi là:

• viết bài kiểm tra trước
• wip (công việc đang tiến hành) cam kết là tốt
• cam kết thường xuyên (nhiều trong vòng một ngày) và sớm (lưu các bước 'làm việc')
• đẩy sau mỗi lần xác nhận (trong trường hợp ổ cứng của bạn gặp sự cố / xe buýt đâm vào bạn).
• luôn làm việc trong các chi nhánh đầu tiên
• khi có thể chỉ hợp nhất trong mã làm việc để làm chủ
• rebase tương tác trong git để squash wips trước khi hợp nhất tổng thể

Vấn đề chính và có lẽ là vấn đề bạn đang gặp phải là khi bạn có một tính năng cơ bản hoạt động và rất cần cho doanh nghiệp (và do đó cần phải ở trong 'bậc thầy') nhưng có một số thử nghiệm thất bại. Một lựa chọn ở đây có thể là làm một bài kiểm tra đang chờ xử lý cho phép bạn tiến về phía trước ngay bây giờ. Tuy nhiên, điều này đầy nguy hiểm vì thử nghiệm có thể không bao giờ được sửa chữa và nó có thể thiết lập một mô hình trong các lĩnh vực khác chỉ đơn giản là 'chờ xử lý' các thử nghiệm bị hỏng thay vì sửa chúng.

Một lựa chọn khác là tạm thời sử dụng và triển khai chi nhánh. Điều này có thể giúp đỡ trong một số tình huống nhất định nhưng thường không được khuyến nghị và không bền vững.

Có lẽ lựa chọn tốt nhất là về cơ bản thực hiện một cách tiếp cận chuyên nghiệp hơn để phát triển phần mềm và thực sự yêu cầu các bài kiểm tra làm việc cho bất kỳ mã cam kết nào. Đây thường là phần 'khó' trong phát triển phần mềm, không phải là mã hóa mà nhiều người tưởng tượng. Một cách tiếp cận tốt hơn có thể sẽ yêu cầu ước tính ban đầu tốt hơn, phân bổ tài nguyên, cài đặt ưu tiên, v.v., cộng với, trong quá trình phát triển Agile, cho phép đủ thời gian và sử dụng đủ kỷ luật để khắc phục mọi vấn đề cả tại thời điểm chúng xảy ra và trong các phiên chỉ điểm.

Tập trung vào những gì 'hoàn thành' có nghĩa là - nó có nghĩa là mã VÀ các bài kiểm tra được viết, đã được tái cấu trúc và hoạt động. Nếu bạn nghe thấy các bình luận như "hầu hết đã được thực hiện, chỉ cần viết / sửa / kiểm tra lại cấu trúc, thì nó KHÔNG được thực hiện. Nói một tính năng được thực hiện mà không hoàn thiện về mặt kỹ thuật là một trong những lỗi phổ biến nhất của các lập trình viên cơ sở.

Giá trị của bất kỳ cam kết nào, bị hỏng hay không, là mã được cam kết với một máy chủ. Trong môi trường chuyên nghiệp, máy chủ đó là bản sao lưu an toàn, dự phòng và đang chạy. Nếu tôi làm việc cả ngày, cam kết là một hình thức đảm bảo mã của tôi tồn tại bất cứ điều gì xảy ra với máy cục bộ của tôi. Đĩa cứng chết. Máy tính xách tay bị mất hoặc bị đánh cắp. Sao lưu của máy chủ kho lưu trữ sẽ có sẵn ngay cả khi tòa nhà bị cháy.

Hãy suy nghĩ về nó theo cách này. Là một nhà phát triển, một trong những điều gây rối nhất mà bạn làm là ngăn chặn các nhà phát triển khác trong nhóm của bạn thực hiện các nhiệm vụ của họ.

Triết lý chỉ cam kết mã làm việc đến từ các nhóm phát triển làm việc trên cùng một thân cây trong kho lưu trữ. Bây giờ có vẻ điên rồ, nhưng 10 năm trước, đây là cách làm việc bình thường. Một nhánh sẽ xuất hiện khi bạn muốn tạo một bản phát hành ổn định, nhưng suy nghĩ của một nhà phát triển làm việc trong một nhánh để thực hiện một tính năng mới gần như chưa từng nghe thấy.

Nếu môi trường của bạn có nghĩa là các cam kết của bạn không ngay lập tức ảnh hưởng đến các nhà phát triển khác, thì hãy cam kết thường xuyên. nó mang lại cho bạn sự bảo mật hơn trong mã của bạn, giúp dễ dàng khắc phục lỗi mã hơn và nhiều hệ thống kiểm soát nguồn cung cấp cho bạn một số bảo vệ mã đối với mã đã cam kết (mặc dù không phải tất cả).

Bây giờ, đảm bảo rằng việc hợp nhất của bạn với các chi nhánh được chia sẻ với các nhà phát triển khác có hiệu quả và bất kỳ mã nào bạn quảng bá đến cấp độ biên dịch này, vượt qua tất cả các bài kiểm tra đơn vị và kiểm tra độ tỉnh dựa trên nhóm khác ... đó là điều cần thiết nếu bạn không muốn tiếp tục mua bia trong quán rượu ...

Trước khi bạn bắt đầu giáo điều về cách làm việc với kiểm soát phiên bản của mình, bạn nên suy nghĩ về lý do tại sao bạn làm việc với kiểm soát phiên bản.

Cam kết kiểm soát phiên bản đóng băng trạng thái mã của bạn để tham khảo trong tương lai - mọi thứ khác đều nằm ngoài điều này. Nhìn vào diffs và tạo các bản vá chỉ là xem cách mã thay đổi giữa các snapshot. Chi nhánh và thẻ chỉ là cách tổ chức ảnh chụp nhanh. Chia sẻ mã với các nhà phát triển khác chỉ để họ nhìn vào một ảnh chụp nhanh cụ thể.

Khi nào bạn nên cam kết? Khi có cơ hội hợp lý, bạn sẽ xem xét trạng thái mã của mình (hoặc thông điệp cam kết giải thích về sự thay đổi) trong tương lai.

Git cung cấp cho bạn rất nhiều sự linh hoạt về cách tổ chức ảnh chụp nhanh của bạn. Không có kho lưu trữ trung tâm để bạn có thể chia sẻ mã của mình với các nhà phát triển khác mà không cần đẩy trạng thái của mình sang kho lưu trữ 'chính'. Bạn có thể dễ dàng tạo, hợp nhất và xóa các nhánh để tách biệt các chi tiết của một tập hợp các trạng thái khỏi tường thuật của mã chính. Bạn có thể cam kết tại địa phương, để giúp bạn hoàn tác theo sự phát triển hiện tại của mình và sau đó gộp mọi thứ thành một cam kết duy nhất trước khi đẩy nó ra cho người khác xem. Bạn có thể gắn thẻ các bản sửa đổi cụ thể để dễ dàng tìm thấy sau này.

HÔN . Những gì hoạt động tốt nhất cho một nhà phát triển trong giai đoạn đầu phát triển của một dự án nhỏ sẽ hoàn toàn khác so với những gì bạn cần làm khi bạn có hàng trăm nhà phát triển làm việc trên một hệ thống quan trọng, có tuổi đời hàng thập kỷ. Trong bất kỳ quy trình phát triển phần mềm nào, bạn nên tránh tạo ra các tạo phẩm không cần thiết chỉ đơn giản vì ai đó bảo bạn làm điều đó.

Xây dựng / phát hành chi nhánh

Bạn không bao giờ nên cố tình cam kết mã bị hỏng cho một nhánh xây dựng. Bất kỳ chi nhánh nào đang được tích hợp liên tục hoặc từ đó phát hành hoặc xây dựng hàng ngày phải luôn luôn ở trạng thái có thể tin cậy được.

Các chi nhánh khác: Lưu bang thường xuyên

Đối với các nhánh riêng hoặc tính năng, các mục tiêu thường khác nhau. Việc kiểm tra mã thường xuyên (dù có hoạt động hay không) có thể được mong muốn. Nói chung, bạn sẽ muốn cam kết bất cứ lúc nào bạn có thể cần tua lại về trạng thái hiện tại.

Xem xét các ví dụ này khi trạng thái lưu cung cấp một lợi ích đáng kể:

• Bạn có thể thực hiện một cam kết ngay trước khi bạn chạy một tìm kiếm và thay thế toàn cầu để bạn có thể hoàn nguyên cây của mình trong một thao tác nếu có sự cố.
• Bạn có thể thực hiện một loạt các cam kết tạm thời trong khi tái cấu trúc một đoạn mã phức tạp để bạn có thể chia đôi hoặc tua lại nếu cuối cùng bạn phá vỡ một cái gì đó trong quy trình.
• Bạn có thể thực hiện một cam kết, bắt đầu một nhánh mới hoặc tạo một thẻ khi bạn muốn thử một cái gì đó thử nghiệm trong khi có thể trở lại trạng thái của cây làm việc hiện tại bất cứ lúc nào.

Cam kết một số mã cơ sở bị hỏng là được miễn là nó là cục bộ.

Tại sao?

• Điều cần thiết là sử dụng cam kết như một điểm lưu trong sự phát triển của bạn
• Nó cho bạn thấy một mô hình suy nghĩ được sử dụng trong khi phát triển sản phẩm.
• Nó không phá vỡ sự hợp tác .

Tuy nhiên, khi có một nhóm lập trình viên, triết lý của nhà lập trình là tối quan trọng và thay thế các hành vi cam kết cá nhân. Một số nhà lập trình quyết định ghi nhật ký tất cả tiến trình trong khi những nhà khác quyết định chỉ cam kết mã giải quyết một tính năng. Trong trường hợp này, giá trị ( chi phí , từ quan điểm quản lý phần mềm) của một cam kết bị hỏng là rất nghiêm trọng:

1. thời gian được sử dụng cho các tính năng khác hiện đang dành để sửa lỗi ...
2. cắt giảm phát triển không được đáp ứng ...
3. sản phẩm không được vận chuyển đúng thời gian

Các điểm khác có thể được thêm vào ba tầng này theo cấp số nhân của chúng theo cấp số nhân vào một cuộc khủng hoảng của công ty ... tất nhiên, đây phải là một tác động của việc phạm phải thói quen kinh niên của mã xấu.

Tôi không nghĩ rằng việc chấp nhận mã bị hỏng là ổn.

Chuyện gì sẽ xảy ra nếu

• Một sửa chữa nóng khẩn cấp là cần thiết. Mã cơ sở là trong một trạng thái bị hỏng. Bạn buộc phải quay lại, sửa chữa và triển khai.

• Một số người khác bắt đầu làm việc trong cùng một chi nhánh mà không biết rằng bạn đã phạm phải mã bị hỏng. Họ có thể đang theo đuổi một "cá trích đỏ" nghĩ rằng những thay đổi của họ đã phá vỡ thứ gì đó.

• Bạn quyết định rời khỏi công ty, đi nghỉ hoặc không thể đi làm vì bất kỳ lý do gì. Các đồng nghiệp của bạn sẽ phải đào sâu để tìm ra những gì bị hỏng và tại sao nó đã được cam kết trong trạng thái bị hỏng.

• Ai đó triển khai 'mã bị hỏng' của bạn? Đây có thể là một 'trò chơi kết thúc' nếu bạn đang làm việc với dữ liệu cá nhân hoặc trên một nhà cung cấp thanh toán.

Trả lời @WarrenT

Tôi đồng ý với bạn rằng trong một thế giới lý tưởng nơi mọi người làm việc trong một nhánh tính năng, cam kết mã không hoạt động có thể hoạt động. Tôi đã làm việc trong các dự án lớn và thậm chí sau đó có những trường hợp nhiều người phải làm việc trong một nhánh tính năng duy nhất. Tôi cũng đã thấy mọi người cam kết mã 'không hoạt động' cho chi nhánh chính vì việc phát hành còn vài tuần nữa và họ đã lên kế hoạch sửa nó vào ngày hôm sau. Tất cả những điều này là ứng cử viên cho một thảm họa và tôi tin tưởng mạnh mẽ rằng chúng nên được tránh bằng mọi giá.

Một số câu hỏi để giúp bạn xác định xem có ổn không khi cam kết mã không hoạt động:

1. Bạn đang làm việc quá sức?
2. Làm đồng đội của bạn liên tục phá vỡ các bản dựng?
3. Là cơ sở mã của bạn là một mớ hỗn độn và dường như không thể tồi tệ hơn?

Nếu bạn nói có với bất kỳ điều nào ở trên, thì có, bạn có thể cam kết mã không hoạt động.

Chỉ cần nhớ sửa nó càng sớm càng tốt, bao gồm nó với bất kỳ bài kiểm tra đơn vị áp dụng nào và xin lỗi vì đã phá vỡ bản dựng.