Eclipse의 .project, .classpath, .settings와 같은 프로젝트 파일을 버전 제어 (예 : Subversion, GitHub, CVS, Mercurial 등)하에 유지해야합니까?
답변:
휴대용 설정 파일 을 버전 제어에 유지하고 싶습니다 .
즉 ,
절대 경로가없는 파일입니다.
그것은 포함:
나를위한 경험 법칙 :
프로젝트를 작업 공간으로로드 할 수 있어야하고 IDE에서 올바르게 설정하고 몇 분 안에 작업을 시작하는 데 필요한 모든 것이 있어야합니다.
추가 문서 나 읽을 위키 페이지가 없습니다.
로드, 설정, 이동.
.project 및 .classpath 파일 예. 그러나 IDE 설정을 버전 제어에 유지하지 않습니다. 설정을 유지하는 데 좋지 않은 플러그인이 있으며 일부 설정은 한 개발 시스템에서 다음 시스템으로 이식성이 매우 낮다는 것을 발견했습니다. 따라서 대신 개발자가 IDE를 설정하는 데 필요한 단계를 강조하는 Wiki 페이지가 있습니다.
이것들은 내가 생성 된 파일이라고 생각하는 것이므로 버전 관리하에 두지 않습니다. 예를 들어 사람들이 다른 Eclipse 플러그인을 설치 한 경우에는 시스템마다, 개발자마다 다를 수 있습니다.
대신 새 체크 아웃을 할 때 이러한 파일의 초기 버전을 생성 할 수있는 빌드 도구 (Maven)를 사용합니다.
나는 여기서 두 가지 옵션 사이에서 갈등을 겪고 있습니다.
한편으로는 모든 소스 아티팩트가 버전 제어에 저장되고 빌드 스크립트 (예 : ANT 또는 Maven)가 표준 준수를 보장하는 한 모든 사람이 가장 생산적인 개발 도구 세트를 자유롭게 사용할 수 있어야한다고 생각합니다. 사용할 JDK, 의존 할 타사 라이브러리의 버전, 스타일 검사 (예 : checkstyle) 실행 및 단위 테스트 실행 등을 정확하게 지정합니다.
반면에 저는 많은 사람들이 동일한 도구 (예 : 이클립스)를 사용한다고 생각하며 빌드 타임 대신 디자인 타임에 표준화하는 것이 훨씬 낫다고 생각합니다. 예를 들어 Checkstyle은 이클립스 플러그인보다 훨씬 더 유용합니다. ANT 또는 Maven 작업-개발 도구 세트와 공통 플러그인 세트를 표준화하는 것이 좋습니다.
나는 모든 사람들이 정확히 동일한 JDK, 동일한 버전의 Maven, 동일한 버전의 Eclipse, 동일한 Eclipse 플러그인 세트 및 동일한 구성 파일 (예 : Checkstyle 프로필, 코드 포맷터 규칙 등)을 사용하는 프로젝트에서 작업했습니다. 이 모든 것들은 .project, .classpath 및 .settings 폴더의 모든 것이 소스 제어에 보관되었습니다. 사람들이 의존성 또는 빌드 프로세스를 지속적으로 조정하는 프로젝트의 초기 단계에서 삶을 정말 쉽게 만들었습니다. 또한 프로젝트에 새로운 스타터를 추가 할 때 큰 도움이되었습니다.
균형 적으로 종교 전쟁의 가능성이 너무 많지 않다면 기본 개발 도구 및 플러그인 세트를 표준화하고 빌드 스크립트에서 버전 준수를 보장해야합니다 (예 : Java 버전을 명시 적으로 지정). JDK와 Eclipse 설치를 소스 제어에 저장하는 것이 많은 이점이 있다고 생각하지 마십시오. 프로젝트 파일, 구성 및 플러그인 환경 설정 (특히 코드 포맷터 및 스타일 규칙)을 포함하여 파생 된 아티팩트가 아닌 다른 모든 것은 소스 제어로 이동해야합니다.
추신 : Maven을 사용하는 경우 .project 및 .classpath 파일이 파생 된 아티팩트라는 주장이 있습니다. 이는 빌드 할 때마다 생성하고 POM에서 생성 한 후 수동으로 조정 (또는 일부 환경 설정을 변경하여 실수로 변경) 한 적이없는 경우에만 해당됩니다.
아니요, 저는 Maven 사용자이며 .project 및 .classpath를 업데이트하고 업데이트하는 Eclipse 용 Q 플러그인을 사용합니다 . 플러그인 설정과 같은 다른 사항에 대해서는 일반적으로 README 또는 Wiki 페이지를 관리합니다.
또한 다른 IDE를 선호하는 사람들은 Maven 플러그인을 사용하여 IDE (및 자체)를 행복하게 유지하는 데 필요한 파일을 생성합니다.
일반적으로 "생성 된 파일의 버전을 작성하지 않음"접근 방식에 동의하지만 문제가있어 다시 전환해야합니다.
참고 : 저는 VonC의 답변 , 특히 "몇 분 안에 Eclipse 시작"지점에 관심이 있습니다. 그러나 그것은 우리에게 결정적이지 않습니다.
컨텍스트는 m2eclipse 플러그인을 사용하는 Eclipse + Maven입니다. 우리는 가능한 한 공통 디렉토리가있는 공통 개발 환경을 가지고 있습니다. 그러나 때때로 누군가가 플러그인을 시도하거나 구성에서 작은 사항을 변경하거나 다른 브랜치의 두 번째 작업 공간을 가져 오는 경우가 있습니다.
우리의 문제는 Eclipse에서 프로젝트를 가져올 때 .project 생성이 수행되지만 나중에 모든 경우에 업데이트되지 않는다는 것입니다 . 슬프고 m2eclipse 플러그인이 개선 될 것이므로 영구적 인 것은 아니지만 지금은 사실입니다. 그래서 우리는 다른 구성을 갖게됩니다. : 우리가 오늘 가지고하는 것이 었 몇 가지 본성이 후 많은 다르게 행동 일부 시스템에서 많은 프로젝트에 추가 된 :-(
우리가 볼 수있는 유일한 해결책은 .project 파일의 버전을 지정하는 것입니다 (위험을 피하기 위해 .classpath 및 .settings에 대해 동일한 작업을 수행합니다). 이렇게하면 한 개발자가 자신의 pom을 변경하면 로컬 파일이 m2eclipse를 사용하여 업데이트되고 모두 함께 커밋되고 다른 개발자가 모든 변경 사항을 볼 수 있습니다.
참고 : 우리의 경우 상대 파일 이름을 사용하므로 해당 파일을 공유하는 데 문제가 없습니다.
따라서 귀하의 질문에 답하기 위해 예라고 대답합니다. 해당 파일을 커밋합니다.
나는 또한 좋아했다 :
이러한 프로젝트 파일은 프로젝트에서 작업 할 때 시간이 지남에 따라 변경 될 수 있으므로 예, 버전 관리하에 배치합니다.
IntelliJ IDEA를 사용하고 프로젝트 (.ipr) 및 모듈 (.iml) 파일의 '.sample'버전을 버전 관리하에 유지합니다.
여기서 좀 더 큰 것은 버전 관리, IMHO보다 공유 및 재사용 입니다. 그러나 이러한 구성을 공유하려는 경우 저장소보다 다른 모든 구성 바로 옆에 배치하는 것이 더 좋습니다.
공유 및 버전 관리 프로젝트 파일의 몇 가지 장점 :
IDEA에서 이러한 파일에는 다음과 같은 구성이 포함되어 있습니다. "소스"및 "테스트 소스"디렉토리는 무엇입니까? 외부 의존성에 대한 모든 것 (어디에 라이브러리 jar, 관련 소스 또는 javadocs가 있는가) 빌드 옵션 등. 이것은 개발자마다 다르지 않은 것입니다 (저는 이것에 매우 동의 하지 않습니다 ). IDEA는 플러그인 구성뿐 아니라 더 많은 개인 IDE 설정을 다른 곳에 저장합니다. (저는 Eclipse를 잘 모릅니다. 이것은 상당히 다를 수도 있고 아닐 수도 있습니다.)
나는 다음과 같은 대답에 동의합니다 .
프로젝트를 작업 공간에로드 할 수 있어야하며 IDE에서 올바르게 설정하고 몇 분 안에 작업을 시작하는 데 필요한 모든 것이 있어야합니다. [...]로드, 설정, 이동.
그리고 우리는 버전이 지정된 프로젝트 파일 덕분에 이렇게 만들었습니다.