programing

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

elseif 2023. 4. 29. 08:48

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

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

휴대용 설정 파일을 버전 제어 상태로 유지하려는 경우
의미:
절대 경로가 없는 모든 파일.
여기에는 다음이 포함됩니다.

  • .프로젝트.
  • .classpath (절대 경로가 사용되지 않는 경우, IDE 변수 또는 사용자 환경 변수를 사용하여 가능)
  • IDE 설정(이는 '승인된' 답변에 강하게 반대하는 부분입니다.)이러한 설정에는 정적 코드 분석 규칙이 포함되는 경우가 많으며, 이 규칙은 이 프로젝트를 작업 영역에 로드하는 모든 사용자에게 일관성 있게 적용하는 데 매우 중요합니다.
  • IDE 관련 설정 권장 사항은 큰 README 파일로 작성해야 합니다(물론 버전도 작성되어야 합니다).

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

.project 및 .classpath 파일 예.그러나 IDE 설정을 버전 제어 상태로 유지하지는 않습니다.설정 유지를 제대로 수행하지 못하는 플러그인이 있으며 일부 설정이 한 개발 시스템에서 다음 개발 시스템으로 이동하기에 적합하지 않습니다.대신 개발자가 IDE를 설정하는 데 필요한 단계를 강조하는 Wiki 페이지가 있습니다.

이러한 파일은 생성된 파일로 간주되므로 버전을 제어하지 않습니다.예를 들어 사람마다 다른 Eclipse 플러그인이 설치되어 있는 경우와 같이 시스템과 개발자마다 다를 수 있습니다.

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

나는 여기서 두 가지 선택지 사이에서 고민하고 있습니다.

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

반면에, 저는 많은 사람들이 동일한 도구를 사용한다고 생각합니다(예:Eclipse)와 함께 빌드 시간 대신 설계 시간에 표준화된 것이 훨씬 낫습니다. 예를 들어 Checkstyle은 ANT 또는 Maven 작업보다 Eclipse 플러그인으로 훨씬 유용합니다. 개발 도구 집합과 공통 플러그인 집합에서 표준화하는 것이 더 낫습니다.

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

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

추신: Maven을 사용하는 경우 .project 및 .classpath 파일이 파생 아티팩트라는 주장이 있습니다.이는 빌드를 수행할 때마다 생성하는 경우와 POM에서 생성한 후 수동으로 수정할 필요가 없는 경우(또는 일부 기본 설정을 변경하여 실수로 변경한 경우)에만 해당됩니다.

아니요, 소프트웨어를 빌드하는 데 필요한 버전 제어 파일만 사용하기 때문입니다.또한, 개별 개발자들은 그들만의 프로젝트별 설정을 가지고 있을 수 있습니다.

아니요, 저는 헤비 메이븐 사용자이며 .project 및 .classpath를 만들고 유지하는 Q for Eclipse 플러그인을 사용합니다.플러그인 설정과 같은 기타 사항에 대해서는 대개 README 또는 Wiki 페이지를 유지합니다.

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

이것은 모두 의견일 것입니다. 하지만 지난 수년간의 모범 사례는 전체 조직이 하나의 IDE에 표준화되어 있고 전환할 의사가 없는 한 특정 IDE에 특정 파일을 소스 제어에 저장해서는 안 된다는 것을 의미합니다.

어느 쪽이든 사용자 설정이 저장되지 않도록 해야 합니다. 그리고 .project에는 개발자별 설정이 포함될 수 있습니다.

메이븐이나 앤트 같은 것을 표준화된 빌드 시스템으로 사용하는 것을 추천합니다.모든 개발자는 몇 초 안에 IDE에 클래스 경로를 구성할 수 있습니다.

예, .settings 폴더를 제외합니다.다른 파일을 커밋하는 것은 우리에게 잘 맞습니다.여기에도 비슷한 질문이 있습니다.

일반적으로 "생성된 파일 버전 사용 안 함" 접근 방식에 동의하지만, 문제가 있어 다시 전환해야 합니다.

참고: 저는 또한 VonC의 답변, 특히 "몇 분 안에 이클립스를 일으켜라"는 점에 관심이 있습니다.하지만 그것은 우리에게 결정적이지 않습니다.

우리의 컨텍스트는 m2eclipse 플러그인을 사용하는 Eclipse+Maven입니다.가능한 한 공통 디렉토리를 사용하여 공통 개발 환경을 구축하고 있습니다.그러나 다른 사용자가 플러그인을 사용해 보거나 구성의 사소한 부분을 변경하거나 다른 분기에 대한 두 번째 작업 공간을 가져오는 경우가 있습니다.

문제는 Eclipse에서 프로젝트를 가져올 때 .project 생성이 수행되지만 나중에 모든 경우에 업데이트되지 않는다는 것입니다.슬프고, m2eclipse 플러그인이 개선될 것이기 때문에 영구적이지 않을 수도 있지만, 지금은 사실입니다.결국 다른 구성을 갖게 됩니다.오늘 우리가 가진 것은: 몇 가지 특성이 어떤 기계의 많은 프로젝트에 추가되었고, 그 다음에는 훨씬 다르게 동작한다는 것이었습니다. :-(

유일한 해결책은 .project 파일을 버전화하는 것입니다(위험을 피하기 위해 .classpath 및 .settings에 대해서도 동일한 방법을 사용합니다).그런 식으로 한 개발자가 폼을 변경하면 로컬 파일이 m2eclipse를 사용하여 업데이트되고, 모든 파일이 함께 커밋되며, 다른 개발자가 모든 변경 사항을 볼 수 있습니다.

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

여러분의 질문에 답하기 위해, 저는 "네"라고 대답합니다. 그 파일들을 커밋하세요.


저는 또한 좋아했습니다:

이 프로젝트 파일들은 프로젝트를 진행함에 따라 시간이 지남에 따라 변경될 수 있기 때문에 예, 버전 관리 하에 배치합니다.

네, 생산물만 빼고요

우리는 IntelliJ IDEA를 사용하며 프로젝트(.ipr) 및 모듈(.iml) 파일의 '.sample' 버전을 버전 관리 하에 둡니다.

여기서 좀 더 중요한 것은 버전 관리, IMHO보다 공유와 재사용입니다.그러나 이러한 구성을 공유하려면 저장소보다 다른 모든 구성 옆에 배치하는 것이 더 적합합니다.

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

  • 모든 태그/지점을 체크아웃하고 신속하게 작업을 시작할 수 있습니다.
  • 신규 개발자가 먼저 개발 환경을 설정하고 속도를 높일 수 있도록 지원
  • 이 방법은 DRY에 더 잘 밀착되어 항상 만족도가 높습니다.에 모든 개발자들은 이런 것들을 때때로 설정해야 했습니다. 기본적으로 반복적인 작업을 해야 했습니다.물론 모두가 반복되는 것을 피할 수 있는 작은 방법들이 있었지만, 팀 전체를 보면 중복된 노력이 많았습니다.

IDEA에서 이러한 파일에는 다음과 같은 구성이 포함되어 있습니다. "소스" 및 "테스트 소스" 디르란 무엇인가, 외부 종속성에 대한 모든 것(라이브러리 병 및 관련 소스 또는 javadoc), 빌드 옵션 등.이것은 개발자마다 다르지 않은 것입니다. (저는 이것에 매우 강하게 반대합니다.)IDEA는 플러그인 구성뿐만 아니라 더 많은 개인 IDE 설정을 다른 곳에 저장합니다. (나는 이클립스를 잘 알지 못합니다. 이것은 완전히 다를 수도 있고 그렇지 않을 수도 있습니다.)

저는 다음과 같은 답변에 동의합니다.

프로젝트를 작업 공간에 로드할 수 있어야 하며 IDE에서 프로젝트를 올바르게 설정하고 몇 분 안에 시작하는 데 필요한 모든 작업을 수행할 수 있어야 합니다. [...] 로드, 설정, 시작.

그리고 우리는 버전화된 프로젝트 파일 덕분에 이렇게 가지고 있습니다.

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