Tôi có nên giữ các tệp dự án của mình dưới quyền kiểm soát phiên bản không? [đóng cửa]


87

Tôi có nên giữ các tệp dự án như .project, .classpath, .settings của Eclipse, dưới quyền kiểm soát phiên bản (ví dụ: Subversion, GitHub, CVS, Mercurial, v.v.) không?



12
Vì vậy, rất mang tính xây dựng
QED

Câu trả lời:


93

Bạn muốn giữ quyền kiểm soát phiên bản bất kỳ tệp cài đặt di động nào ,
nghĩa là:
Bất kỳ tệp nào không có đường dẫn tuyệt đối trong đó.
Điều đó bao gồm:

  • .dự án,
  • .classpath ( nếu không sử dụng đường dẫn tuyệt đối , có thể sử dụng các biến IDE hoặc các biến môi trường người dùng)
  • Cài đặt IDE (đó là nơi tôi không đồng ý với câu trả lời 'được chấp nhận'). Các cài đặt đó thường bao gồm các quy tắc phân tích mã tĩnh cực kỳ quan trọng để thực thi nhất quán cho bất kỳ người dùng nào tải dự án này vào không gian làm việc của họ.
  • Các câu lệnh cài đặt cụ thể của IDE phải được viết trong một tệp README lớn (và tất nhiên là đã được phiên bản hóa).

Quy tắc chung cho tôi:
Bạn phải có thể tải một dự án vào không gian làm việc và có trong đó mọi thứ bạn cần để thiết lập nó đúng cách trong IDE của bạn và bắt đầu thực hiện trong vài phút.
Không có tài liệu bổ sung, trang wiki để đọc hoặc những gì không.
Tải nó lên, thiết lập nó, đi.


@Rich: cảm ơn bạn. Đối với những độc giả khác, hãy xem câu trả lời của Rich cho câu hỏi tương tự một năm sau: stackoverflow.com/questions/1429125/…
VonC,

3
giai đoạn quan trọng "... bắt đầu sau vài phút ..."
Eric Labashosky

3
Vì vậy, kho lưu trữ VC nên có các tệp cấu hình cho mọi IDE? NetBeans, Eclipse, Emacs, vi, bất cứ điều gì khác? Tôi đặc biệt không đồng ý với ý kiến ​​rằng các tệp này vì nhà phát triển phải chịu trách nhiệm thiết lập IDE của riêng họ.
RHSeeger

3
@RH - "... phải chịu trách nhiệm thiết lập IDE của riêng họ". Điều đó tốt thôi, cho đến khi một số tên hề quên thiết lập các thuộc tính kiểu mã Eclipse của chúng .... và kiểm tra các tệp nguồn có TAB trong đó. Grrrr !!
Stephen C

2
Tôi cũng không đồng ý - nếu bạn đang sử dụng CI, nhiều phiên bản, nền tảng, IDE, v.v. thì điều này phá vỡ DRY khá tệ. Esp. vì các plugin / cài đặt khác nhau có ảnh hưởng lớn đến những gì kết thúc ở đây.
jayshao

30

Các tệp .project và .classpath có. Tuy nhiên, chúng tôi không giữ cài đặt IDE của mình trong kiểm soát phiên bản. Có một số plugin không thực hiện tốt việc duy trì các cài đặt và chúng tôi nhận thấy rằng một số cài đặt không thực sự linh hoạt từ máy phát triển này sang máy khác. Vì vậy, thay vào đó, chúng tôi có một trang Wiki nêu bật các bước cần thiết để nhà phát triển thiết lập IDE của họ.


2
-1 Tôi khuyên bạn nên gửi báo cáo lỗi cho các plugin đó thay vì để chúng lãng phí thời gian của hàng nghìn người. Và sau đó, tôi sẽ đặt tất cả các tệp cài đặt ổn định dưới sự kiểm soát của phiên bản và cắt trang Wiki đó xuống.
Aaron Digulla

18

Đây là những gì tôi coi là các tệp được tạo và vì vậy tôi không bao giờ đặt chúng dưới sự kiểm soát của phiên bản. Chúng có thể khác nhau giữa các máy và nhà phát triển với nhà phát triển, chẳng hạn như khi mọi người cài đặt các phần bổ trợ Eclipse khác nhau.

Thay vào đó, tôi sử dụng một công cụ xây dựng (Maven) có thể tạo phiên bản ban đầu của những tệp này khi bạn thực hiện một thanh toán mới.


Nói chính xác: mvn eclipse: eclipse sẽ tạo ra .classpath và .project thích hợp. Bạn có thể chuyển nó -DdownloadSources = true và -DdownloadJavadocs = true.
Aleksandar Dimitrov

bạn cũng có thể định cấu hình plugin eclipse trong pom của mình để luôn tải xuống các nguồn và javadoc.
Chris Vest

1
-1 Điều này hoạt động miễn là bạn không bao giờ thay đổi cài đặt dự án trong IDE của mình. Và điều nguy hiểm là: Nếu bạn thay đổi chúng, bạn sẽ không nhận ra vì các tệp không được phiên bản. Vì vậy, tôi rất muốn bỏ phiếu điều này. Chỉ nên làm điều này cho những dự án thực sự đơn giản như những dự án bạn không có ý định chia sẻ với bất kỳ ai. Trong một nhóm, các mặc định thường không hoạt động và việc yêu cầu mỗi nhà phát triển thay đổi thiết lập của họ là một công thức chắc chắn cho sự hỗn loạn.
Aaron Digulla

Aaron, điều này hoạt động ngay cả khi bạn thay đổi tệp dự án trong IDE của mình. Điều gì xảy ra tiếp theo, đó là bạn không đưa các thay đổi của mình ra ngoài cho nhóm không nghi ngờ của bạn. Các dự án IDE có xu hướng chứa thông tin cụ thể của máy và nhà phát triển, điều này sẽ không phù hợp với tất cả mọi người. Tôi thấy rằng bạn càng sử dụng nhiều plug-in và việc sử dụng IDE của bạn càng phức tạp thì điều này càng trở nên tồi tệ hơn. Mọi người nên biết công cụ của họ hoạt động như thế nào và có quyền kiểm soát cấu hình của chúng. Tôi làm , tuy nhiên, đồng ý rằng phương pháp này là không phải không có thiết lập riêng của vấn đề.
Chris Vest

Ngoài ra, việc khắc phục các xung đột hợp nhất gây ra bởi các trình cắm chỉnh sửa các tệp này một cách vô ích sẽ trở nên cũ khá nhanh.
Chris Vest

7

Tôi đang bị giằng xé giữa hai lựa chọn ở đây.

Một mặt, tôi nghĩ rằng mọi người nên tự do sử dụng bộ công cụ phát triển mà họ có năng suất cao nhất, miễn là tất cả các tạo tác nguồn được lưu trữ trong kiểm soát phiên bản và tập lệnh xây dựng (ví dụ như ANT hoặc Maven) đảm bảo tuân thủ các tiêu chuẩn theo chỉ định chính xác JDK sẽ sử dụng, phiên bản nào của thư viện bên thứ ba phụ thuộc vào, chạy kiểm tra kiểu (ví dụ: kiểu kiểm tra) và chạy kiểm tra đơn vị, v.v.

Mặt khác, tôi nghĩ rất nhiều người sử dụng cùng một công cụ (ví dụ như Eclipse) và thường thì tốt hơn nhiều nếu có một số thứ được chuẩn hóa tại thời điểm thiết kế thay vì thời gian xây dựng - ví dụ: Checkstyle hữu ích hơn nhiều với tư cách là một plugin Eclipse hơn là một nhiệm vụ ANT hoặc Maven - tốt hơn là nên tiêu chuẩn hóa trên bộ công cụ phát triển và bộ bổ sung chung.

Tôi đã làm việc trong một dự án mà mọi người đều sử dụng chính xác cùng một JDK, cùng một phiên bản Maven, cùng một phiên bản Eclipse, cùng một bộ plugin Eclipse và cùng một tệp cấu hình (ví dụ: cấu hình Checkstyle, quy tắc định dạng mã, v.v.). Tất cả những thứ này đều được giữ trong quyền kiểm soát nguồn - .project, .classpath và mọi thứ trong thư mục .settings. Nó làm cho cuộc sống thực sự dễ dàng trong giai đoạn đầu của dự án khi mọi người liên tục điều chỉnh các phần phụ thuộc hoặc quy trình xây dựng. Nó cũng giúp ích rất nhiều khi thêm những người mới bắt đầu vào dự án.

Về mặt cân bằng, tôi nghĩ rằng nếu không có quá nhiều khả năng xảy ra chiến tranh tôn giáo, bạn nên chuẩn hóa bộ công cụ phát triển và plugin cơ bản và đảm bảo tuân thủ phiên bản trong các tập lệnh xây dựng của bạn (ví dụ: bằng cách chỉ định rõ ràng phiên bản Java). đừng nghĩ rằng có nhiều lợi ích khi lưu trữ JDK và cài đặt Eclipse trong điều khiển nguồn. Mọi thứ khác không phải là tạo tác có nguồn gốc - bao gồm các tệp dự án, cấu hình và tùy chọn plugin của bạn (đặc biệt là các quy tắc định dạng mã và kiểu) - sẽ đi vào kiểm soát nguồn.

Tái bút Nếu bạn sử dụng Maven, có một lập luận để nói rằng các tệp .project và .classpath là các tạo tác có nguồn gốc. Điều này chỉ đúng nếu bạn tạo chúng mỗi khi xây dựng và nếu bạn chưa bao giờ phải chỉnh sửa chúng bằng tay (hoặc vô tình thay đổi chúng bằng cách thay đổi một số tùy chọn) sau khi tạo chúng từ POM


6

Không, vì tôi chỉ kiểm soát phiên bản các tệp cần thiết để xây dựng phần mềm. Bên cạnh đó, các nhà phát triển cá nhân có thể có cài đặt dành riêng cho dự án của họ.


5

Không, tôi là người dùng Maven nặng và sử dụng plugin Q cho Eclipse để tạo và cập nhật .project và .classpath. Đối với những thứ khác, chẳng hạn như cài đặt cho các plugin, tôi thường đọc README hoặc Wiki-page về điều đó.

Ngoài ra, những người tôi đã làm việc với họ thích các IDE khác chỉ sử dụng Maven-plugin để tạo các tệp cần thiết để giữ cho IDE của họ (và chính họ) hài lòng.


5

Tôi cho rằng đây là tất cả ý kiến ​​- nhưng các phương pháp hay nhất trong nhiều năm chỉ ra rằng các tệp cụ thể cho một IDE nhất định không nên được lưu trữ trong kiểm soát nguồn, trừ khi toàn bộ tổ chức của bạn được chuẩn hóa trên một IDE và bạn không bao giờ có ý định chuyển đổi.

Dù bằng cách nào, bạn chắc chắn không muốn cài đặt người dùng được lưu trữ - và .project có thể chứa các cài đặt thực sự dành riêng cho nhà phát triển.

Tôi khuyên bạn nên sử dụng một cái gì đó như Maven hoặc Ant làm hệ thống xây dựng tiêu chuẩn hóa. Bất kỳ nhà phát triển nào cũng có thể nhận được một đường dẫn classpath được định cấu hình trong IDE của họ trong vài giây.


1

Có, ngoại trừ thư mục .settings. Cam kết các tệp khác hoạt động tốt cho chúng tôi. Có một câu hỏi tương tự ở đây .


1

Mặc dù tôi thường đồng ý về cách tiếp cận "không tạo tệp phiên bản", nhưng chúng tôi gặp sự cố với nó và phải chuyển lại.

Lưu ý: Tôi cũng quan tâm đến câu trả lời của VonC , đặc biệt là về điểm "đưa Eclipse lên trong vòng vài phút". Nhưng nó không mang tính quyết định đối với chúng tôi.

Bối cảnh của chúng tôi là Eclipse + Maven, sử dụng trình cắm thêm m2eclipse. Chúng tôi có một môi trường phát triển chung, với các thư mục chung càng nhiều càng tốt. Nhưng đôi khi xảy ra trường hợp ai đó thử một trình cắm thêm hoặc thay đổi một số thứ nhỏ trong cấu hình hoặc nhập không gian làm việc thứ hai cho một nhánh khác ...

Vấn đề của chúng tôi là việc tạo .project được thực hiện khi nhập một dự án trong Eclipse, nhưng không được cập nhật trong mọi trường hợp sau này . Thật đáng buồn, và có lẽ không phải là vĩnh viễn vì plugin m2eclipse sẽ được cải thiện, nhưng nó đúng vào lúc này. Vì vậy, chúng tôi kết thúc có các cấu hình khác nhau. Những gì chúng ta có ngày hôm nay là: một số bản chất đã được thêm vào nhiều dự án trên một số máy, sau đó chúng hoạt động khác nhiều :-(

Giải pháp duy nhất mà chúng tôi thấy là tạo phiên bản cho tệp .project (để tránh rủi ro, chúng tôi sẽ thực hiện tương tự đối với .classpath và .settings). Bằng cách đó, khi một nhà phát triển thay đổi pom của cô ấy, các tệp cục bộ sẽ được cập nhật bằng cách sử dụng m2eclipse, tất cả chúng được cam kết với nhau và các nhà phát triển khác sẽ thấy tất cả các thay đổi.

Lưu ý: trong trường hợp của chúng tôi, chúng tôi sử dụng tên tệp tương đối, vì vậy chúng tôi không có vấn đề gì khi chia sẻ các tệp đó.

Vì vậy, để trả lời câu hỏi của bạn, tôi nói có, hãy cam kết các tệp đó.


Tôi cũng thích:


"... thay đổi pom của cô ấy bằng cách sử dụng m2eclipse ..."? M2eclipse phải làm gì với tệp pom? Chắc chắn nó sử dụng nó, nhưng các thay đổi đối với pom phải độc lập với plugin.
RHSeeger

@RHSeeger Cảm ơn, tôi sẽ cải thiện sự rõ ràng về phần này trong câu trả lời của mình.
KLE

0

Có vẻ như các tệp dự án này có thể thay đổi theo thời gian khi bạn làm việc trong một dự án nên vâng, tôi đặt chúng dưới quyền kiểm soát phiên bản.


0

Đúng. Tất cả mọi thứ ngoại trừ xây dựng đầu ra.


0

Chúng tôi sử dụng IntelliJ IDEA và giữ phiên bản '.sample' của tệp dự án (.ipr) và mô-đun (.iml) dưới quyền kiểm soát phiên bản.

Điều quan trọng hơn ở đây là chia sẻ và tái sử dụng hơn là lập phiên bản, IMHO. Nhưng nếu bạn định chia sẻ các cấu hình này, thì nơi nào tốt hơn để đặt chúng ngoài kho lưu trữ, ngay bên cạnh mọi thứ khác.

Một số ưu điểm của tệp dự án được chia sẻ và được tạo phiên bản:

  • Bạn có thể kiểm tra bất kỳ thẻ / nhánh nào và bắt đầu làm việc nhanh chóng
  • Giúp nhà phát triển mới lần đầu tiên thiết lập môi trường phát triển và bắt kịp tốc độ
  • Điều này phù hợp tốt hơn với DRY, luôn luôn thỏa mãn sâu sắc. Trước đó, tất cả các nhà phát triển phải thiết lập những thứ này thỉnh thoảng, về cơ bản là thực hiện công việc lặp đi lặp lại. Tất nhiên ai cũng có những cách riêng để tránh lặp lại chính mình, nhưng nhìn tổng thể thì thấy có rất nhiều nỗ lực được nhân đôi.

Lưu ý rằng trong IDEA các tệp này chứa các cấu hình như: dirs "nguồn" và "nguồn kiểm tra" là gì; mọi thứ về các phụ thuộc bên ngoài (các lọ thư viện được đặt ở đâu, cũng như các nguồn hoặc javadocs liên quan); tùy chọn xây dựng, v.v. Đây là thứ không khác nhau giữa các nhà phát triển (tôi không đồng ý với điều này rất nhiều). IDEA lưu trữ nhiều cài đặt IDE cá nhân hơn ở những nơi khác, cũng như bất kỳ cấu hình plugin nào. (Tôi không biết rõ về Eclipse; điều này có thể khác hoặc không.)

Tôi đồng ý với câu trả lời này nói rằng:

Bạn phải có thể tải một dự án vào một không gian làm việc và có trong đó mọi thứ bạn cần để thiết lập nó đúng cách trong IDE của mình và bắt đầu trong vài phút. [...] Tải nó lên, thiết lập nó, đi.

Và chúng tôi có nó như thế này, nhờ các tệp dự án đã được phiên bản hóa.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.