Tôi có nên lưu trữ mã đã tạo trong kiểm soát nguồn không

Đây là cuộc tranh luận mà tôi đang tham gia. Tôi muốn có thêm ý kiến ​​và quan điểm.

Chúng tôi có một số lớp được tạo ra trong thời gian xây dựng để xử lý các hoạt động DB (trong trường hợp cụ thể này là với SubSonic, nhưng tôi không nghĩ nó rất quan trọng đối với câu hỏi). Quá trình tạo được đặt như một bước xây dựng trước trong Visual Studio. Vì vậy, mỗi khi một nhà phát triển (hoặc quá trình xây dựng chính thức) chạy một bản dựng, các lớp này sẽ được tạo ra và sau đó được biên dịch thành dự án.

Bây giờ một số người đang tuyên bố rằng việc lưu các lớp này trong kiểm soát nguồn có thể gây ra nhầm lẫn, trong trường hợp mã bạn nhận được, không khớp với những gì đã được tạo trong môi trường của chính bạn.

Tôi muốn có một cách để theo dõi lịch sử của mã, ngay cả khi nó thường được coi là một hộp đen.

Bất kỳ đối số hoặc đối số phản bác?

Tôi sẽ không chọn một câu trả lời được chấp nhận vào thời điểm này vì những lý do đã đề cập ở trên.

Lưu nó trong kiểm soát nguồn là rắc rối hơn đáng giá.

Bạn phải thực hiện cam kết mỗi khi xây dựng để nó có giá trị bất kỳ.

Nói chung, chúng tôi để mã đã tạo (idl, jaxb, v.v.) bên ngoài kiểm soát nguồn nơi tôi làm việc và nó chưa bao giờ là vấn đề

Đặt nó trong kiểm soát mã nguồn. Lợi thế của việc có sẵn lịch sử của mọi thứ bạn viết cho các nhà phát triển trong tương lai vượt trội hơn so với việc thỉnh thoảng phải xây dựng lại sau khi đồng bộ hóa.

Mỗi khi tôi muốn hiển thị các thay đổi đối với cây nguồn trên repo cá nhân của mình, tất cả các 'tệp được tạo' sẽ hiển thị là đã thay đổi và cần sửa lại.

Tôi muốn có một danh sách các sửa đổi rõ ràng hơn, chỉ bao gồm các bản cập nhật thực đã được thực hiện chứ không phải các thay đổi được tạo tự động.

Bỏ chúng ra và sau đó sau khi xây dựng, hãy thêm 'bỏ qua' trên mỗi tệp được tạo.

Hãy nhìn nó theo cách này: bạn có kiểm tra các tệp đối tượng của mình vào kiểm soát nguồn không? Tệp nguồn được tạo là tạo tác xây dựng giống như tệp đối tượng, thư viện và tệp thực thi. Họ nên được đối xử như nhau. Hầu hết sẽ tranh luận rằng bạn không nên kiểm tra các tệp đối tượng đã tạo và tệp thực thi vào kiểm soát nguồn. Các đối số tương tự áp dụng cho nguồn được tạo.

Nếu bạn cần xem phiên bản lịch sử của tệp đã tạo, bạn có thể đồng bộ hóa với phiên bản lịch sử của các nguồn và tạo lại.

Kiểm tra các tệp được tạo thuộc bất kỳ loại nào trong kiểm soát nguồn cũng tương tự như việc không chuẩn hóa cơ sở dữ liệu. Đôi khi có những lý do để làm điều này (thường là vì hiệu suất), nhưng điều này chỉ nên được thực hiện một cách cẩn thận vì việc duy trì tính đúng đắn và nhất quán trở nên khó khăn hơn nhiều khi dữ liệu không chuẩn hóa.

Tôi muốn nói rằng bạn nên tránh thêm bất kỳ mã đã tạo nào (hoặc các tạo tác khác) vào kiểm soát nguồn. Nếu mã được tạo giống nhau đối với đầu vào đã cho thì bạn chỉ cần kiểm tra các phiên bản bạn muốn khác và tạo mã để so sánh.

Tôi gọi là nguyên tắc KHÔ. Nếu bạn đã có "tệp nguồn" trong kho lưu trữ được sử dụng để tạo các tệp mã này tại thời điểm xây dựng, thì không cần phải có cùng một mã được cam kết "hai lần".

Ngoài ra, bạn có thể ngăn chặn một số vấn đề theo cách này nếu ví dụ như việc tạo mã bị hỏng vào một ngày nào đó.

Không, vì ba lý do.

1. Mã nguồn là mọi thứ cần thiết và đủ để tái tạo ảnh chụp nhanh của ứng dụng của bạn tại thời điểm hiện tại hoặc trước đó - không hơn không kém. Một phần của điều này ngụ ý rằng ai đó chịu trách nhiệm về mọi thứ đã đăng ký. Nói chung, tôi rất vui khi chịu trách nhiệm về mã mà tôi viết, nhưng không phải mã được tạo ra do hậu quả của những gì tôi viết.

2. Tôi không muốn ai đó bị cám dỗ để cố gắng tắt một bản dựng từ các nguồn chính bằng cách sử dụng mã trung gian có thể hiện tại hoặc có thể không (và quan trọng hơn là tôi không muốn nhận trách nhiệm.) Và không phải vậy. khiến một số người bị cuốn vào một quy trình vô nghĩa về việc gỡ lỗi xung đột trong mã trung gian dựa trên các bản dựng từng phần.

3. Khi nó nằm trong quyền kiểm soát nguồn, tôi xin nhận trách nhiệm về a. nó đang ở đó, b. nó đang hiện hành, và c. nó được tích hợp đáng tin cậy với mọi thứ khác trong đó. Điều đó bao gồm việc loại bỏ nó khi tôi không còn sử dụng nó nữa. Càng ít trách nhiệm càng tốt.

Tôi thực sự không nghĩ rằng bạn nên kiểm tra chúng.

Chắc chắn rằng bất kỳ thay đổi nào trong mã được tạo đều sẽ là nhiễu - thay đổi giữa các môi trường hoặc thay đổi do kết quả của thứ khác - ví dụ như thay đổi trong DB của bạn. Nếu các tập lệnh tạo của DB của bạn (hoặc bất kỳ phần phụ thuộc nào khác) nằm trong quyền kiểm soát nguồn thì tại sao bạn cũng cần các tập lệnh được tạo?

Nguyên tắc chung là không , nhưng nếu mất thời gian để tạo mã (vì quyền truy cập DB, dịch vụ web, v.v.) thì bạn có thể muốn lưu một phiên bản đã lưu trong bộ nhớ cache trong điều khiển nguồn và đỡ phiền phức cho mọi người.

Dụng cụ của bạn cũng cần lưu ý điều này và xử lý việc kiểm xuất khỏi bộ điều khiển nguồn khi cần thiết, quá nhiều công cụ quyết định kiểm tra từ bộ điều khiển nguồn mà không có lý do.
Một công cụ tốt sẽ sử dụng phiên bản được lưu trong bộ nhớ cache mà không cần chạm vào nó (cũng như không sửa đổi các bước thời gian trên tệp).

Ngoài ra, bạn cần đặt cảnh báo lớn bên trong mã được tạo để mọi người không sửa đổi tệp, cảnh báo ở trên cùng là không đủ, bạn phải lặp lại nó hàng chục dòng.

Chúng tôi cũng không lưu trữ mã DB đã tạo: vì nó được tạo, bạn có thể lấy nó theo ý muốn ở bất kỳ phiên bản nhất định nào từ các tệp nguồn. Lưu trữ nó sẽ giống như lưu trữ bytecode hoặc tương tự.

Bây giờ, bạn cần đảm bảo có sẵn trình tạo mã được sử dụng ở một phiên bản nhất định! Các phiên bản mới hơn có thể tạo mã khác ...

Để nó ra.

Nếu bạn đang kiểm tra các tệp đã tạo, bạn đang làm sai. Có chuyện gì vậy có thể khác nhau, nó có thể là quá trình xây dựng của bạn là không hiệu quả, hay cái gì khác, nhưng tôi không thể nhìn thấy nó bao giờ là một ý tưởng tốt. Lịch sử phải được liên kết với các tệp nguồn, không phải các tệp được tạo.

Nó chỉ tạo ra một cơn đau đầu cho những người sau đó cố gắng giải quyết sự khác biệt, tìm các tệp không còn được tạo bởi bản dựng và sau đó xóa chúng, v.v.

Một thế giới đau đớn đang chờ đợi những người kiểm tra các tệp đã tạo!

Có một trường hợp đặc biệt mà bạn muốn kiểm tra các tệp đã tạo của mình: khi bạn có thể cần xây dựng trên các hệ thống mà các công cụ được sử dụng để tạo các tệp khác không khả dụng. Ví dụ cổ điển về điều này, và một ví dụ tôi làm việc, là mã Lex và Yacc. Bởi vì chúng tôi phát triển một hệ thống thời gian chạy phải xây dựng và chạy trên nhiều nền tảng và kiến ​​trúc khác nhau, chúng tôi chỉ có thể dựa vào các hệ thống đích để có trình biên dịch C và C ++, chứ không phải các công cụ cần thiết để tạo mã lexing / phân tích cú pháp cho định nghĩa giao diện của chúng tôi người phiên dịch. Vì vậy, khi chúng tôi thay đổi ngữ pháp của mình, chúng tôi kiểm tra mã đã tạo để phân tích cú pháp.

đến hơi muộn ... dù sao ...

Bạn có đặt tệp trung gian của trình biên dịch vào kiểm soát phiên bản nguồn không? Trong trường hợp tạo mã, theo định nghĩa mã nguồn là đầu vào của trình tạo trong khi mã được tạo có thể được coi là các tệp trung gian giữa nguồn "thực" và ứng dụng được xây dựng.

Vì vậy, tôi sẽ nói: không đặt mã được tạo dưới quyền kiểm soát phiên bản, mà đặt trình tạo và đầu vào của nó.

Cụ thể, tôi làm việc với một trình tạo mã mà tôi đã viết: Tôi chưa bao giờ phải duy trì mã nguồn được tạo dưới sự kiểm soát của phiên bản. Tôi thậm chí sẽ nói rằng vì trình tạo đã đạt đến một mức độ trưởng thành nhất định, tôi không phải quan sát nội dung của mã được tạo mặc dù đầu vào (ví dụ mô tả mô hình) đã thay đổi.

Trong một số dự án, tôi thêm mã đã tạo vào kiểm soát nguồn, nhưng nó thực sự phụ thuộc. Hướng dẫn cơ bản của tôi là nếu mã được tạo là một phần nội tại của trình biên dịch thì tôi sẽ không thêm nó. Nếu mã được tạo là từ một công cụ bên ngoài, chẳng hạn như SubSonic trong trường hợp này, thì tôi sẽ thêm if vào kiểm soát nguồn. Nếu bạn nâng cấp định kỳ thành phần thì tôi muốn biết những thay đổi trong nguồn được tạo trong trường hợp phát sinh lỗi hoặc sự cố.

Theo như mã đã tạo cần được kiểm tra, trường hợp xấu nhất là làm sai lệch các tệp theo cách thủ công và hoàn nguyên các tệp nếu cần. Nếu bạn đang sử dụng svn, bạn có thể thêm một hook pre-commit trong svn để từ chối một commit nếu tệp không thực sự thay đổi.

Công việc quản lý cấu hình (trong đó kiểm soát phiên bản chỉ là một phần) là có thể thực hiện những việc sau:

• Biết những thay đổi và sửa lỗi nào đã đi vào mỗi bản dựng được giao.
• Có thể sao chép chính xác bất kỳ bản dựng nào đã phân phối, bắt đầu từ mã nguồn ban đầu. Mã được tạo tự động không được tính là "mã nguồn" bất kể ngôn ngữ.

Điều đầu tiên đảm bảo rằng khi bạn nói với khách hàng hoặc người dùng cuối "lỗi mà bạn báo cáo tuần trước đã được sửa và tính năng mới đã được thêm vào" họ sẽ không quay lại hai giờ sau đó và nói "không có". Nó cũng đảm bảo rằng họ không nói "Tại sao nó lại làm X? Chúng tôi chưa bao giờ yêu cầu X".

Điều thứ hai có nghĩa là khi khách hàng hoặc người dùng cuối báo cáo lỗi trong một số phiên bản bạn đã phát hành một năm trước, bạn có thể quay lại phiên bản đó, tái tạo lỗi, sửa lỗi và chứng minh rằng đó là bản sửa lỗi của bạn đã loại bỏ lỗi thay vì một số xáo trộn của trình biên dịch và các bản sửa lỗi khác.

Điều này có nghĩa là trình biên dịch, thư viện, v.v. của bạn cũng cần phải là một phần của CM.

Vì vậy, bây giờ để trả lời câu hỏi của bạn: nếu bạn có thể làm tất cả những điều trên thì bạn không cần phải ghi lại bất kỳ biểu diễn trung gian nào, vì dù sao thì bạn cũng được đảm bảo nhận được cùng một câu trả lời. Nếu bạn không thể thực hiện tất cả những điều trên thì tất cả cược sẽ bị hủy vì bạn không bao giờ có thể đảm bảo làm cùng một điều hai lần và nhận được cùng một câu trả lời. Vì vậy, bạn cũng có thể đặt tất cả các tệp .o của mình dưới quyền kiểm soát phiên bản.

Nó thực sự phụ thuộc. Cuối cùng, mục tiêu là có thể tái tạo những gì bạn đã có nếu cần. Nếu bạn có thể tạo lại các tệp nhị phân của mình một cách chính xác, thì không cần phải lưu trữ chúng. nhưng bạn cần nhớ rằng để tạo lại nội dung của mình, bạn có thể sẽ cần cấu hình chính xác mà bạn đã làm với nó ngay từ đầu và điều đó không chỉ có nghĩa là mã nguồn của bạn mà còn cả môi trường xây dựng, IDE của bạn, thậm chí có thể là các thư viện khác , máy phát điện hoặc công cụ, trong cấu hình chính xác (phiên bản) bạn đã sử dụng.

Tôi đã gặp rắc rối trong các dự án khi chúng tôi nâng cấp môi trường xây dựng của mình lên các phiên bản mới hơn hoặc thậm chí lên các nhà cung cấp khác, nơi chúng tôi không thể tạo lại các tệp nhị phân chính xác mà chúng tôi đã có trước đây. Đây là một nỗi đau thực sự khi các tệp nhị phân được giải thích phụ thuộc vào một loại băm, đặc biệt là trong môi trường bảo mật và các tệp được tạo lại bằng cách nào đó khác nhau do nâng cấp trình biên dịch hoặc bất cứ điều gì.

Vì vậy, bạn sẽ lưu trữ mã đã tạo: Tôi sẽ nói không. Các tệp nhị phân hoặc phân phối được phát hành, bao gồm các công cụ mà bạn đã sao chép chúng với tôi sẽ lưu trữ. Và sau đó, không cần phải lưu trữ chúng trong kiểm soát nguồn, chỉ cần sao lưu tốt các tệp đó.

Câu trả lời đúng là "Nó phụ thuộc". Nó phụ thuộc vào nhu cầu của khách hàng là gì. Nếu bạn có thể khôi phục mã cho một bản phát hành cụ thể và chống chọi với bất kỳ kiểm tra bên ngoài nào mà không có nó, thì bạn vẫn chưa có cơ sở vững chắc. Với tư cách là nhà phát triển, chúng ta không chỉ cần quan tâm đến 'tiếng ồn', sự đau đớn và dung lượng ổ đĩa, mà còn thực tế là chúng ta được giao nhiệm vụ tạo ra tài sản trí tuệ và có thể có những phân nhánh pháp lý. Bạn có thể chứng minh với giám khảo rằng bạn có thể tạo lại một trang web chính xác như cách mà khách hàng đã nhìn thấy nó hai năm trước không?

Tôi không khuyên bạn nên lưu hoặc không lưu các tệp gen'd, cho dù bạn quyết định theo cách nào nếu bạn không liên quan đến các Chuyên gia về vấn đề chủ đề về quyết định có thể bạn đã sai.

Theo quan điểm của tôi.

Có những lập luận tốt cả cho và chống lại được trình bày ở đây. Đối với bản ghi, tôi xây dựng hệ thống tạo T4 trong Visual Studio và tùy chọn out-of-the-box mặc định của chúng tôi khiến mã được tạo được đăng ký. Bạn phải làm việc chăm chỉ hơn một chút nếu không muốn đăng ký.

Đối với tôi, cân nhắc chính là khác biệt đầu ra được tạo khi đầu vào hoặc bản thân trình tạo được cập nhật.

Nếu bạn chưa đăng ký đầu ra của mình, thì bạn phải chụp một bản sao của tất cả mã đã tạo trước khi nâng cấp trình tạo hoặc sửa đổi đầu vào để có thể so sánh mã đó với đầu ra từ phiên bản mới. Tôi nghĩ đây là một quá trình khá tẻ nhạt, nhưng với đầu ra đã được kiểm tra, việc khác biệt đầu ra mới với kho lưu trữ là một vấn đề đơn giản.

Tại thời điểm này, hợp lý để hỏi "Tại sao bạn quan tâm đến những thay đổi trong mã được tạo?" (Đặc biệt là so với mã đối tượng.) Tôi tin rằng có một vài lý do chính, xuất phát từ tình trạng hiện tại của nghệ thuật hơn là bất kỳ vấn đề cố hữu nào.

1. Bạn tạo mã viết tay kết hợp chặt chẽ với mã được tạo. Đó không phải là trường hợp nói chung với các tệp obj ngày nay. Khi mã được tạo thay đổi, thật đáng buồn là một số mã viết tay cần thay đổi để phù hợp. Những người thường không quan sát thấy mức độ tương thích ngược cao với các điểm mở rộng trong mã được tạo.

2. Mã được tạo chỉ đơn giản là thay đổi hành vi của nó. Bạn sẽ không chấp nhận điều này từ trình biên dịch, nhưng công bằng mà nói, trình tạo mã cấp ứng dụng đang nhắm mục tiêu đến một lĩnh vực vấn đề khác với nhiều giải pháp có thể chấp nhận hơn. Điều quan trọng là phải xem liệu những giả định bạn đưa ra về hành vi trước đây có bị phá vỡ hay không.

3. Bạn chỉ không tin tưởng 100% đầu ra của trình tạo của bạn từ khi phát hành đến khi phát hành. Có rất nhiều giá trị có được từ các công cụ của trình tạo ngay cả khi chúng không được xây dựng và duy trì với sự nghiêm ngặt của nhà cung cấp trình biên dịch của bạn. Bản phát hành 1.0 có thể đã hoàn toàn ổn định cho ứng dụng của bạn nhưng có thể bản 1.1 có một vài trục trặc cho trường hợp sử dụng của bạn bây giờ. Ngoài ra, bạn thay đổi các giá trị đầu vào và thấy rằng bạn đang thực hiện một phần mới của trình tạo mà bạn chưa sử dụng trước đây - có khả năng bạn sẽ ngạc nhiên với kết quả.

Về cơ bản, tất cả những điều này đều đi đến mức độ trưởng thành của công cụ - hầu hết các trình tạo mã ứng dụng dành cho doanh nghiệp không đạt được mức độ mà các trình biên dịch hoặc thậm chí các công cụ cấp lex / yacc đã có trong nhiều năm.

Cả hai bên đều có lập luận xác đáng và hợp lý, và rất khó để thống nhất về một điểm chung. Hệ thống kiểm soát phiên bản (VCS) theo dõi các tệp mà nhà phát triển đưa vào đó và có giả định rằng các tệp bên trong VCS được các nhà phát triển tạo thủ công và các nhà phát triển quan tâm đến lịch sử và sự thay đổi giữa bất kỳ bản sửa đổi nào của tệp. Giả định này cân bằng hai khái niệm, "Tôi muốn lấy tệp này khi tôi thanh toán." và "Tôi quan tâm đến sự thay đổi của tệp này."

Bây giờ, các lập luận của cả hai bên có thể được diễn đạt lại như thế này:

• "Tôi muốn nhận tất cả các tệp được tạo này khi tôi thanh toán, vì tôi không có công cụ để tạo chúng trong máy này."
• "Tôi không nên đưa chúng vào VCS, vì tôi không quan tâm đến sự thay đổi của tệp này."

May mắn thay, có vẻ như hai yêu cầu không mâu thuẫn về cơ bản. Với một số phần mở rộng của VCS hiện tại, có thể có cả hai. Nói cách khác, đó là một tình huống tiến thoái lưỡng nan giả. Nếu chúng ta suy ngẫm một chút, không khó để nhận ra rằng vấn đề bắt nguồn từ giả định VCS đang nắm giữ. Các VCS nên phân biệt các tệp do các nhà phát triển tạo thủ công với các tệp không được các nhà phát triển tạo thủ công mà chỉ xảy ra bên trong VCS này. Đối với loại tệp đầu tiên, chúng tôi thường gọi là tệp nguồn (mã), VCS hiện đã làm rất tốt. Đối với loại thứ hai, VCSs vẫn chưa có khái niệm như vậy, theo như tôi biết.

Tóm lược

Tôi sẽ lấy git làm một ví dụ để minh họa ý tôi muốn nói.

• git status sẽ không hiển thị các tệp được tạo theo mặc định.
• git commit nên bao gồm các tệp được tạo dưới dạng ảnh chụp nhanh.
• git diff sẽ không hiển thị các tệp được tạo theo mặc định.

PS

Git hooks có thể được sử dụng như một giải pháp thay thế, nhưng sẽ thật tuyệt nếu git hỗ trợ nó nguyên bản. gitignorekhông đáp ứng yêu cầu của chúng tôi, đối với các tệp bị bỏ qua sẽ không được đưa vào VCS.enter code here

Tôi sẽ tranh luận cho. Nếu bạn đang sử dụng quy trình tích hợp liên tục để kiểm tra mã, sửa đổi số bản dựng, xây dựng phần mềm và sau đó kiểm tra nó, thì đơn giản và dễ dàng hơn chỉ cần có mã đó như một phần của kho lưu trữ của bạn.

Ngoài ra, nó là một phần và phần của mọi "ảnh chụp nhanh" mà bạn lấy từ kho phần mềm của mình. Nếu nó là một phần của phần mềm, thì nó phải là một phần của kho lưu trữ.

Tôi sẽ nói rằng có bạn muốn đặt nó dưới sự kiểm soát nguồn. Từ quan điểm quản lý cấu hình MỌI THỨ được sử dụng để tạo ra một bản dựng phần mềm cần được kiểm soát để nó có thể được tạo lại. Tôi hiểu rằng mã đã tạo có thể dễ dàng được tạo lại, nhưng có thể đưa ra đối số rằng mã không giống nhau vì ngày / dấu thời gian sẽ khác nhau giữa hai bản dựng. Trong một số lĩnh vực như chính phủ, họ yêu cầu rất nhiều lần đây là những gì được thực hiện.

Nói chung, mã đã tạo không cần được lưu trữ trong điều khiển nguồn vì lịch sử sửa đổi của mã này có thể được truy tìm bằng lịch sử sửa đổi của mã đã tạo ra nó!

Tuy nhiên, có vẻ như OP đang sử dụng mã được tạo làm lớp truy cập dữ liệu của ứng dụng thay vì viết thủ công. Trong trường hợp này, tôi sẽ thay đổi quá trình xây dựng và cam kết mã cho kiểm soát nguồn vì nó là một thành phần quan trọng của mã thời gian chạy. Điều này cũng loại bỏ sự phụ thuộc vào công cụ tạo mã khỏi quá trình xây dựng trong trường hợp các nhà phát triển cần sử dụng phiên bản khác nhau của công cụ cho các nhánh khác nhau.

Có vẻ như mã chỉ cần được tạo một lần thay vì mọi bản dựng. Khi một nhà phát triển cần thêm / bớt / thay đổi cách một đối tượng truy cập vào cơ sở dữ liệu, mã sẽ được tạo lại, giống như thực hiện các sửa đổi thủ công. Điều này tăng tốc quá trình xây dựng, cho phép tối ưu hóa thủ công cho lớp truy cập dữ liệu và lịch sử của lớp truy cập dữ liệu được lưu giữ một cách đơn giản.

Tôi (rất tiếc) đã kết thúc việc đặt rất nhiều nguồn có nguồn gốc dưới sự kiểm soát của nguồn bởi vì tôi làm việc từ xa với những người không thể thiết lập môi trường xây dựng thích hợp hoặc những người không có kỹ năng thiết lập nó để nguồn gốc được xây dựng chính xác đúng. (Và khi nói đến công cụ tự động Gnu, bản thân tôi là một trong những người đó! Tôi không thể làm việc với ba hệ thống khác nhau, mỗi hệ thống hoạt động với một phiên bản công cụ tự động khác nhau — và chỉ phiên bản đó.)

Loại khó khăn này có lẽ áp dụng cho các dự án bán thời gian, tình nguyện, mã nguồn mở hơn là các dự án trả phí mà người thanh toán hóa đơn có thể đòi hỏi một môi trường xây dựng thống nhất.

Khi bạn làm điều này, về cơ bản bạn đang cam kết xây dựng các tệp dẫn xuất chỉ tại một trang web hoặc chỉ tại các trang web được định cấu hình đúng cách. Makefiles của bạn (hoặc bất cứ thứ gì) nên được thiết lập để thông báo nơi chúng đang chạy và nên từ chối lấy lại các nguồn trừ khi họ biết chúng đang chạy tại một trang web xây dựng an toàn.

Nếu nó là một phần của mã nguồn thì nó nên được đặt trong quyền kiểm soát nguồn bất kể ai hoặc cái gì tạo ra nó. Bạn muốn điều khiển nguồn của mình phản ánh trạng thái hiện tại của hệ thống mà không cần phải tạo lại nó.

Hoàn toàn có mã được tạo trong kiểm soát nguồn, vì nhiều lý do. Tôi đang nhắc lại những gì nhiều người đã nói, nhưng một số lý do tôi muốn làm điều đó là

1. Với các tệp mã trong kiểm soát nguồn, bạn sẽ có thể biên dịch mã mà không cần sử dụng bước tạo trước Visual Studio.
2. Khi bạn thực hiện so sánh đầy đủ giữa hai phiên bản, sẽ rất tốt nếu bạn biết mã được tạo có thay đổi giữa hai thẻ đó hay không mà không cần phải kiểm tra thủ công.
3. Nếu bản thân trình tạo mã thay đổi, thì bạn sẽ muốn đảm bảo rằng các thay đổi đối với mã được tạo sẽ thay đổi một cách thích hợp. tức là Nếu trình tạo của bạn thay đổi, nhưng đầu ra không được phép thay đổi, thì khi bạn chuyển sang cam kết mã của mình, sẽ không có sự khác biệt giữa những gì được tạo trước đó và những gì trong mã được tạo bây giờ.

Tôi sẽ để các tệp đã tạo ra khỏi cây nguồn, nhưng đặt nó trong một cây xây dựng riêng biệt.

ví dụ: quy trình làm việc là

1. kiểm tra / đăng xuất / sửa đổi / hợp nhất nguồn bình thường (w / o bất kỳ tệp nào được tạo)
2. Vào những dịp thích hợp, hãy kiểm tra cây nguồn thành cây sạch
3. Sau khi xây dựng, hãy kiểm tra tất cả các tệp "quan trọng" (tệp nguồn "thực", tệp thực thi + tệp nguồn được tạo) phải có cho mục đích kiểm tra / quản lý. Điều này cung cấp cho bạn lịch sử của tất cả mã được tạo thích hợp + tệp thực thi + bất kỳ thứ gì, gia số tại thời điểm liên quan đến bản phát hành / ảnh chụp nhanh thử nghiệm, v.v. và được tách riêng khỏi quá trình phát triển hàng ngày.

Có lẽ có những cách tốt trong Subversion / Mercurial / Git / etc để gắn lịch sử của các tệp nguồn thực ở cả hai nơi với nhau.

Có vẻ như cả hai bên đều có những ý kiến ​​rất mạnh mẽ và thuyết phục. Tôi khuyên bạn nên đọc tất cả các câu trả lời được bình chọn nhiều nhất, và sau đó quyết định đối số nào áp dụng cho trường hợp cụ thể của bạn.

CẬP NHẬT: Tôi đã hỏi câu hỏi này vì tôi thực sự tin rằng có một câu trả lời chắc chắn. Nhìn vào tất cả các câu trả lời, tôi có thể khẳng định chắc chắn rằng không có câu trả lời nào như vậy. Quyết định nên được thực hiện dựa trên nhiều hơn một tham số. Đọc các câu trả lời khác có thể cung cấp một hướng dẫn rất tốt cho các loại câu hỏi mà bạn nên tự hỏi khi phải quyết định về vấn đề này.