Tôi nên bao gồm những gì trong repositiory của tôi từ các dự án IDE

Tôi muốn thêm một dự án trong trường hợp này được tạo trong Netbeans nhưng câu hỏi này là chung cho hầu hết các IDE. Nó đơn giản, những gì tôi nên bao gồm trong kho lưu trữ của tôi. Ví dụ: Netbeans tạo thư mục nbproject, nhật thực tạo thư mục .sinstall, v.v. Tôi nên đưa chúng vào kho lưu trữ của mình, những lợi thế / bất lợi của việc bao gồm hoặc không bao gồm các cài đặt cụ thể của dự án.

Trong trường hợp này, đó là một dự án cá nhân vì vậy tôi không tưởng tượng rằng những người khác sẽ bắt đầu làm việc với nó, nhưng sẽ rất tốt nếu thêm tối thiểu các cài đặt dự án để bản thân dự án sẽ dễ dàng bắt đầu làm việc trên các máy khác nhau.

Nó thực sự phụ thuộc vào dữ liệu đó là gì và nên được quyết định theo từng trường hợp, thậm chí có thể cho các tệp riêng lẻ. Hãy xem nội dung của những tập tin đó. Thường xuyên hơn không bạn có thể nói những gì họ có nghĩa. Những thứ như vị trí và kích thước của các cửa sổ của IDE là thứ bạn không muốn trong kiểm soát nguồn.

Nhưng một số tệp dự án IDE là siêu dữ liệu dự án quan trọng. Tôi không biết rõ về Netbeans, nhưng đối với nhật thực, tệp .project cho IDE biết tên của dự án là gì, đó là một dự án web Java, v.v. và tệp. Classpath chứa thông tin về các thư mục và thư viện nguồn. Một số tệp trong thư mục .sinstall có thể quan trọng như nhau, ví dụ: org.eclipse.core.resource.prefs chứa thông tin về mã hóa nào sẽ được sử dụng cho các tệp nào.

Là siêu dữ liệu dự án, công cụ này rất xứng đáng được phiên bản trong kiểm soát nguồn.

Một số IDE có thể nhập siêu dữ liệu dự án từ các IDE khác. Sẽ tốt hơn nữa nếu có nó ở dạng không gắn với một IDE cụ thể.

Đối với Java, có một thứ như vậy: Maven . Nó áp đặt các quy ước mạnh mẽ về cấu trúc của dự án và cho phép bạn chỉ định siêu dữ liệu dự án (chẳng hạn như phụ thuộc thư viện) trong một điểm (một tệp có tên pom.xml nằm trong thư mục chính của dự án và, tất nhiên, trong kiểm soát nguồn). Có các plugin sau đó tạo các tệp dự án IDE từ cấu hình Maven và các plugin khác có thể tự động hóa quá trình xây dựng dự án hoặc làm bất cứ điều gì. Đôi khi nó cảm thấy như nó làm cho mọi thứ phức tạp không cần thiết và phải mất một thời gian để tìm hiểu, nhưng những lợi ích nói chung là đáng giá.

Điều này thực sự phụ thuộc vào loại thông tin bạn muốn có trên kho lưu trữ. Nếu bạn muốn mọi thứ ngay lập tức với các tệp bạn đã mở và đang chỉnh sửa tại thời điểm cam kết và bạn là người duy nhất sử dụng kho lưu trữ, hãy tiếp tục và cam kết tất cả, nhưng biết rằng nó có thể không hoạt động trên máy khác .

Nếu bạn muốn có thể chia sẻ mã của mình với những người khác, những người có thể không sử dụng cùng một IDE, thì bạn chỉ cần tự cam kết mã mà không có bất kỳ triển khai cụ thể nào của dự án.

Nếu bạn biết rằng mọi người đều sử dụng cùng một IDE, thì có lẽ bạn có thể bao gồm mọi thứ không phải là máy tính cụ thể, đó là bất kỳ tệp / thư mục cài đặt nào cho chính IDE, theo cách đó họ có thể có khả năng nhập dự án như IDE mong đợi nó.

Các tạo phẩm giúp phát triển và không có ích cho việc xây dựng / phát hành hoặc bản thân dự án không nên được đưa vào. Repo nên sạch sẽ và gọn gàng và chỉ có những thứ có liên quan đến dự án chứ không phải môi trường của bạn . Các repo nên ẩn danh thói quen của bạn. Và thứ hai, nó sẽ khiến bạn không cần thiết khi làm điều gì đó giống như git status... nhưng hey tôi không bao giờ thực hiện bất kỳ thay đổi nào ... ahh bỏ qua điều đó.

Hãy để tôi đưa ra một ví dụ thực tế hơn (tôi sẽ sử dụng gitở đây như một công cụ):

Bạn sẽ không bao giờ muốn một mô hình con (đệ quy) bên trong repo chính của mình để có một nội dung cụ thể IDE (nó cũng có thể can thiệp vào môi trường dự án chính) bởi vì tất cả những gì bạn quan tâm là mã được viết bởi người khác (hoặc bạn) và sử dụng bên trong dự án hiện tại. Không phải môi trường mà nó được phát triển. Bạn có thể không muốn làm điều đó với người khác.

Để có thể sử dụng cài đặt của bạn trên các máy khác nhau, tôi khuyên bạn nên đào sâu vào IDE của mình và xem nó hỗ trợ gì cho những thứ đó. Emacs có initvà máy chủ Emacs cũng vậy. Hoặc bạn có thể tạo macro hoặc tập lệnh tùy chỉnh ( .sh) để thiết lập tự động.

Nếu đó là một dự án cá nhân, tôi nói lưu trữ các cài đặt trong kiểm soát nguồn. Cá nhân, không có gì giết chết động lực của tôi cho một dự án hơn là thiết lập lại môi trường phát triển.

Khi có nhiều người tham gia, tôi sẽ không kiểm soát những thứ này. Trong nhóm của tôi, chúng tôi có một hỗn hợp IntelliJ, Sublime Text và Eclipse đang được sử dụng. Các tệp IDE chỉ cần thêm lộn xộn và dẫn đến các cam kết với các tệp đó từ những người khác đối với một IDE mà bạn không sử dụng.

Ngoài ra, dự án của bạn không nên phụ thuộc vào IDE. Một máy chủ xây dựng sẽ không khởi động được Eclipse để biên dịch sản phẩm của bạn, vì vậy nó sẽ không có IDE. Một điểm nhỏ hơn: nó loại bỏ tổ chức cá nhân trong dự án. Ví dụ, trong IntelliJ tôi thích sử dụng nhiều mô-đun trong dự án của chúng tôi. Không ai khác sử dụng IntelliJ lo lắng về điều này vì chúng tôi không lưu trữ các tệp .iml (mô-đun).

Nếu nhóm của bạn đang sử dụng cùng một IDE thì tốt hơn, nhưng sau đó ai đó phạm phải một mục nhập. Classpath xấu vì họ đã sử dụng một đường dẫn tuyệt đối. Bây giờ mọi người sử dụng IDE lo lắng về nó.

Chắc chắn, nhược điểm là có nhiều thiết lập hơn khi ai đó kiểm tra dự án. Tôi nghĩ nó đáng giá. Chúng tôi sử dụng Ivy để quản lý phụ thuộc và có thông tin về thiết lập, phụ thuộc, v.v. Mặc dù chi phí này tăng lên, tôi nghĩ rằng nó đáng để giữ các cài đặt IDE ngoài tầm kiểm soát nguồn.