프로젝트 파일을 버전 관리하에 유지해야합니까?

프로젝트 파일을 버전 관리하에 유지해야합니까? [닫은]

---

Eclipse의 .project, .classpath, .settings와 같은 프로젝트 파일을 버전 제어 (예 : Subversion, GitHub, CVS, Mercurial 등)하에 유지해야합니까?

---

휴대용 설정 파일 을 버전 제어에 유지하고 싶습니다 .
즉 ,
절대 경로가없는 모든 파일을 의미 합니다.
그것은 포함:

• .계획,
• .classpath ( 사용 된 절대 경로가없는 경우 , IDE 변수 또는 사용자 환경 변수를 사용하여 가능)
• IDE 설정 ( '수락 된'답변에 강하게 동의하지 않는 곳). 이러한 설정에는 종종 이 프로젝트를 작업 공간에로드하는 모든 사용자에게 일관되게 적용하는 데 매우 중요한 정적 코드 분석 규칙 이 포함됩니다 .
• IDE 특정 설정 권장 사항은 큰 README 파일에 작성해야합니다 (물론 버전도 지정).

나를위한 경험 법칙 :
프로젝트를 작업 공간에로드 할 수 있어야하고 IDE에서 올바르게 설정하고 몇 분 안에 작업을 시작하는 데 필요한 모든 것이 있어야합니다.
추가 문서 나 읽을 위키 페이지가 없습니다.
로드, 설정, 이동.

---

.project 및 .classpath 파일 예. 그러나 IDE 설정을 버전 제어에 유지하지 않습니다. 설정을 유지하는 데 좋지 않은 플러그인이 있으며 일부 설정은 한 개발 시스템에서 다음 시스템으로 이식성이 매우 낮다는 것을 발견했습니다. 따라서 대신 개발자가 IDE를 설정하는 데 필요한 단계를 강조하는 Wiki 페이지가 있습니다.

---

이것들은 내가 생성 된 파일이라고 생각하는 것이므로 버전 관리하에 두지 않습니다. 예를 들어 사람들이 다른 Eclipse 플러그인을 설치 한 경우에는 시스템마다, 개발자마다 다를 수 있습니다.

대신 새 체크 아웃을 할 때 이러한 파일의 초기 버전을 생성 할 수있는 빌드 도구 (Maven)를 사용합니다.

---

나는 여기서 두 가지 옵션 사이에서 갈등을 겪고 있습니다.

한편으로는 모든 소스 아티팩트가 버전 제어에 저장되고 빌드 스크립트 (예 : ANT 또는 Maven)가 표준 준수를 보장하는 한 모든 사람이 가장 생산적인 개발 도구 세트를 자유롭게 사용할 수 있어야한다고 생각합니다. 사용할 JDK, 의존 할 타사 라이브러리의 버전, 스타일 검사 (예 : checkstyle) 실행 및 단위 테스트 실행 등을 정확하게 지정합니다.

반면에 저는 많은 사람들이 동일한 도구 (예 : Eclipse)를 사용한다고 생각하며 종종 빌드 시간 대신 디자인 타임에 표준화하는 것이 훨씬 낫습니다. 예를 들어 Checkstyle은 다음과 같은 것보다 Eclipse 플러그인으로 훨씬 더 유용합니다. ANT 또는 Maven 작업-개발 도구 세트와 공통 플러그인 세트를 표준화하는 것이 좋습니다.

나는 모든 사람들이 정확히 동일한 JDK, 동일한 버전의 Maven, 동일한 버전의 Eclipse, 동일한 Eclipse 플러그인 세트 및 동일한 구성 파일 (예 : Checkstyle 프로필, 코드 포맷터 규칙 등)을 사용하는 프로젝트에서 작업했습니다. 이 모든 것들은 .project, .classpath 및 .settings 폴더의 모든 것이 소스 제어에 보관되었습니다. 사람들이 의존성 또는 빌드 프로세스를 지속적으로 조정하는 프로젝트의 초기 단계에서 삶을 정말 쉽게 만들었습니다. 또한 프로젝트에 새로운 스타터를 추가 할 때 큰 도움이되었습니다.

균형 적으로 종교 전쟁의 가능성이 너무 많지 않다면 기본 개발 도구 및 플러그인 세트를 표준화하고 빌드 스크립트에서 버전 준수를 보장해야합니다 (예 : Java 버전을 명시 적으로 지정). JDK와 Eclipse 설치를 소스 제어에 저장하는 것이 많은 이점이 있다고 생각하지 마십시오. 프로젝트 파일, 구성 및 플러그인 환경 설정 (특히 코드 포맷터 및 스타일 규칙)을 포함하여 파생 된 아티팩트가 아닌 다른 모든 것은 소스 제어로 이동해야합니다.

PS Maven을 사용하는 경우 .project 및 .classpath 파일이 파생 된 아티팩트라는 주장이 있습니다. 이는 빌드 할 때마다 생성하고 POM에서 생성 한 후 수동으로 조정 (또는 일부 환경 설정을 변경하여 실수로 변경) 한 적이없는 경우에만 해당됩니다.

---

아니요, 소프트웨어를 빌드하는 데 필요한 버전 제어 파일 만 있기 때문입니다. 게다가 개별 개발자는 자신의 프로젝트 별 설정을 가질 수 있습니다.

---

아니요, 저는 Maven 사용자이며 .project 및 .classpath를 업데이트하고 유지하는 Eclipse 용 Q 플러그인을 사용합니다 . 플러그인 설정과 같은 다른 사항에 대해서는 일반적으로 README 또는 Wiki 페이지를 관리합니다.

또한 다른 IDE를 선호하는 사람들은 Maven 플러그인을 사용하여 IDE (및 자체)를 행복하게 유지하는 데 필요한 파일을 생성합니다.

---

이것은 모두 의견이라고 생각합니다.하지만 수년에 걸친 모범 사례는 전체 조직이 하나의 IDE에서 표준화되고 전환 할 의도가없는 경우 특정 IDE에 특정한 파일을 소스 제어에 저장해서는 안된다는 것을 나타냅니다.

어느 쪽이든 사용자 설정이 저장되는 것을 원하지 않습니다. .project에는 실제로 개발자에 특정한 설정이 포함될 수 있습니다.

Maven 또는 Ant와 같은 것을 표준화 된 빌드 시스템으로 사용하는 것이 좋습니다. 모든 개발자는 몇 초 안에 IDE에 구성된 클래스 경로를 얻을 수 있습니다.

---

예, .settings 폴더를 제외하고. 다른 파일을 커밋하는 것이 우리에게 효과적입니다. 여기에 비슷한 질문이 있습니다 .

---

일반적으로 "생성 된 파일의 버전을 작성하지 않음"접근 방식에 동의하지만 문제가있어 다시 전환해야합니다.

참고 : VonC의 답변 , 특히 "몇 분 안에 Eclipse 시작"요점에 대해 관심이 있습니다. 그러나 그것은 우리에게 결정적이지 않습니다.

컨텍스트는 m2eclipse 플러그인을 사용하는 Eclipse + Maven입니다. 우리는 가능한 한 공통 디렉토리가있는 공통 개발 환경을 가지고 있습니다. 그러나 때때로 누군가가 플러그인을 시도하거나 구성에서 작은 사항을 변경하거나 다른 분기에 대한 두 번째 작업 공간을 가져 오는 경우가 있습니다.

우리의 문제는 Eclipse에서 프로젝트를 가져올 때 .project 생성이 완료되지만 나중에 모든 경우에 업데이트되지 는 않는다는 것입니다 . 슬프고 m2eclipse 플러그인이 개선 될 것이기 때문에 영구적 인 것은 아니지만 지금은 사실입니다. 그래서 우리는 다른 구성을 갖게됩니다. : 우리가 오늘 가지고하는 것이 었 몇 가지 본성이 후 많은 다르게 행동 일부 시스템에서 많은 프로젝트에 추가 된 :-(

우리가 보는 유일한 해결책은 .project 파일의 버전을 지정하는 것입니다 (위험을 피하기 위해 .classpath 및 .settings에 대해 동일한 작업을 수행합니다). 이렇게하면 한 개발자가 자신의 pom을 변경하면 로컬 파일이 m2eclipse를 사용하여 업데이트되고 모두 함께 커밋되고 다른 개발자는 모든 변경 사항을 볼 수 있습니다.

참고 : 우리의 경우에는 상대 파일 이름을 사용하므로 해당 파일을 공유하는 데 문제가 없습니다.

따라서 귀하의 질문에 답하기 위해 예라고 대답합니다. 해당 파일을 커밋합니다.

---

나는 또한 좋아했다 :

• 부자 판매자의 답변

---

이러한 프로젝트 파일은 프로젝트에서 작업 할 때 시간이 지남에 따라 변경 될 수 있으므로 예, 버전 관리하에 배치합니다.

---

예. 빌드 출력을 제외한 모든 것.

---

IntelliJ IDEA를 사용하고 프로젝트 (.ipr) 및 모듈 (.iml) 파일의 '.sample'버전을 버전 제어하에 유지합니다.

여기서 좀 더 큰 것은 버전 관리, IMHO보다 공유 및 재사용 입니다. 그러나 이러한 구성을 공유하려는 경우 저장소보다 다른 모든 항목 바로 옆에 배치하는 것이 더 좋은 곳입니다.

공유 및 버전 관리 프로젝트 파일의 몇 가지 장점 :

• 태그 / 브랜치를 확인하고 빠르게 작업을 시작할 수 있습니다.
• Makes it easier for a new developer to first set up the development environment and get up to speed
• This better adheres to DRY, which is always deeply satisfying. Before this, all developers had to set these things up every now and then, essentially doing repeated work. Of course everyone had their own little ways to avoid repeating themselves, but looking at the team as a whole, there was a lot of duplicated effort.

Note that in IDEA these files contain configurations such as: what are the "source" and "test source" dirs; everything about external dependencies (where are library jars located, as well as related sources or javadocs); build options, etc. This is stuff that does not vary from developer to developer (I disagree with this quite strongly). IDEA stores more personal IDE settings elsewhere, as well as any plugin configurations. (I don't know Eclipse that well; this may or may not be quite different.)

I agree with this answer that says:

You must be able to load a project into a workspace and have in it everything you need to properly set it up in your IDE and get going in minutes. [...] Load it up, set it up, go.

And we have it like this, thanks to versioned project files.

참고URL : https://stackoverflow.com/questions/116121/should-i-keep-my-project-files-under-version-control