Git 소스 제어 하에서 지속적으로 변화하는 IntelliJ IDEA 프로젝트 파일을 처리하는 방법은 무엇입니까?

Git 소스 제어 하에서 지속적으로 변화하는 IntelliJ IDEA 프로젝트 파일을 처리하는 방법은 무엇입니까?

우리 팀의 모든 사람들은 IntelliJ IDEA를 사용하며, 빌드 구성, 설정 및 검사를 공유할 수 있도록 프로젝트 파일(.ipr 및 .iml)을 소스 제어에 넣는 것이 유용합니다.또한 TeamCity와의 지속적인 통합 서버에서 이러한 검사 설정을 사용할 수 있습니다. (소스 제어가 아닌 .gitignore 파일에 사용자별 작업 공간 .iws 파일이 있습니다.)

그러나 IDEA에서 거의 모든 작업을 수행할 때 이러한 파일은 조금씩 변경됩니다.IDEA의 이슈 데이터베이스(IDEA-64312)에 문제가 있으므로 아마도 이것을 IDEA의 버그로 간주할 수도 있지만, 가까운 미래에 우리가 함께 살아야 할 문제입니다.

얼마 전까지는 서브버전을 사용하다가 최근에는 Git로 바꿨습니다.우리는 이제 막 프로젝트 파일의 변경 목록을 만드는 데 익숙해졌는데, 이 목록은 무시하고 다른 사람과 공유하고 싶은 프로젝트 파일 변경 사항이 없으면 체크인하지 않았습니다.그러나 Git를 사용하면 (우리가 조사하고 있는 바에 따르면) 지속적인 분기가 가능하며, 분기 간 전환은 프로젝트 파일이 항상 수정되는 문제입니다.종종 변경사항에 병합할 수 있으며 새 분기에 적용 중인 프로젝트 파일 변경사항을 처리하려고 시도합니다.그러나 새 분기가 프로젝트 파일을 변경한 경우(예: 다른 분기에 아직 없는 새 모듈에서 작업 중인 경우), Git는 분기가 변경되고 로컬로 변경된 경우 파일에서 병합하는 것이 의미가 없다는 오류를 발생시킬 뿐이며, 그 요점을 이해할 수 있습니다.명령줄에서 "git checkout" 명령어에 "-f"를 사용하여 로컬 변경사항을 삭제하고 지점의 변경사항을 대신 사용할 수 있지만 (1) IDEA(10.5.1)의 Git checkout GUI 명령어는 찾을 수 있는 옵션으로 제공되지 않으므로 정기적으로 명령줄로 전환해야 합니다.그리고 (2) 우리는 그 깃발을 사용하고 Git에게 우리의 지역 변경사항을 버리라고 말하는 습관을 갖고 싶은지 확신할 수 없습니다.

다음은 이 문제를 해결해야 하는 옵션에 대한 몇 가지 생각입니다.

1. 프로젝트 파일을 소스 제어에서 완전히 제거합니다.그것들을 .gitignore에 넣고 다른 곳에 소스 제어에 넣거나 다른 이름으로 그것들을 다른 방법으로 각 사람과 TeamCity에 배포합니다.우리 팀의 규모가 작아서 이 옵션을 고려할 수는 있지만, 별로인 것 같습니다.
2. 특정 시간에 어떤 파일이 어떤 분기에 있는지 확실히 관리하기 위해 계속 사용합니다.그 일환으로 각 개발자가 시스템에 각 프로젝트의 복사본을 두 개 이상 보유하도록 권장할 수 있습니다. 따라서 각 개발자가 서로 다른 프로젝트 파일 집합을 가진 다른 지점에서 체크아웃할 수 있습니다.
3. 모듈(.iml) 파일이 소스 제어에 없고 .gitignore 파일에 있는 프로젝트(.ipr)만 소스 제어에 있습니다..ipr에서 정기적으로 자체적으로 전환되는 것처럼 보이는 주요 사항은 공유 빌드 구성의 순서입니다. 그러나 이러한 설정 방법에 대한 정보를 별도로 공유할 수도 있습니다.하지만 IDEA가 특히 새로운 체크아웃에서 파일의 일부만 가지고 있는 이런 종류의 일을 어떻게 처리하는지 잘 모르겠습니다.

Git와 IDEA가 모두 가지고 있는 것처럼 보이는 거대한 커스터마이징 가능성을 다루면서 우리가 놓친 명백한(또는 명백하지 않은) 솔루션이 있기를 바랍니다.하지만 이 문제를 안고 있는 팀은 우리만 있을 수 없는 것 같습니다.스택 오버플로와 유사한 질문에는 3495191, 1000512 및 3873872가 있습니다. 하지만 정확히 동일한 문제이기 때문에 잘 모르겠습니다. 제가 설명한 다양한 접근 방식, 해당 질문에 대한 답변에 나열된 접근 방식 또는 권장하는 접근 방식에 대해 누군가가 장단점을 제시할 수 있을 것입니다.

IDEA의 디렉터리 기반 프로젝트 구조를 사용할 수 있습니다. 여기서 설정은 .ipr 파일이 아닌 .idea 디렉터리에 저장됩니다.버전 제어에 저장된 내용을 보다 세부적으로 제어할 수 있습니다..iml 파일은 여전히 존재하기 때문에 파일의 임의 변경 사항을 해결하지는 못하지만(소스 제어에서 벗어날 수도 있습니까?), 코드 스타일 및 검사 프로필과 같은 것들은 각각 .idea 디렉터리 아래에 있는 자체 파일에 있기 때문에 공유하는 것이 쉽습니다.

공식 문서 작성자: http://devnet.jetbrains.com/docs/DOC-1186

IntelliJ IDEA 프로젝트 형식(.ipr 파일 기반 또는 .idea 디렉터리 기반)에 따라 다음 IntelliJ IDEA 프로젝트 파일을 버전 제어 아래에 두어야 합니다.

.ipr 파일 기반 형식

프로젝트 .ipr 파일 및 모든 .iml 모듈 파일을 공유합니다. .iws 파일은 사용자별 설정을 저장하므로 공유하지 않습니다.

.dll 디렉터리 기반 형식

사용자별 설정을 저장하는 workspace.xml 및 tasks.xml 파일을 제외한 프로젝트 루트의 .idea 디렉터리 아래에 있는 모든 파일을 공유하고 모든 .iml 모듈 파일도 공유합니다.

나는 그것을 .gitignore에 넣었습니다.

#Project
workspace.xml
tasks.xml

공식적인 답변을 이용할 수 있습니다.현대식(그리고 이제 기본값)을 사용한다고 가정합니다..idea폴더 프로젝트 형식:

• 모든 항목 추가...
• 제외하고.idea/workspace.xml(사용자에 따라 다름)
• 제외하고.idea/tasks.xml(사용자에 따라 다름)
• 암호/키/등을 포함할 수 있는 일부 다른 파일 제외(자세한 내용은 위 링크 참조)

이 샘플 .gitignore 파일은 유용한 참조 자료가 될 수 있지만, 위의 링크를 읽어 이러한 항목이 표시되는 이유를 이해하고 필요한지 여부를 결정해야 합니다.

개인적으로 나는 또한 무시합니다..idea/find.xml파일은 검색 작업을 수행할 때마다 변경되는 것처럼 보입니다.

소스 제어에서 workspace.xml(+.gitignore에 추가)을 제거했습니다.

우리 팀은 경로 특정 IntelliJ 파일을 체크인하지 않습니다.우리는 사람들이 IDE를 사용하고 프로젝트를 설정하는 방법을 알고 있다고 가정합니다.IntelliJ 파일은 '무시' 변경 목록에 들어갑니다.

업데이트:

메이븐과 메이븐의 기본 디렉터리 구조를 사용하고 있기 때문에 대답이 더 쉬워졌습니다.

IntelliJ에게 의 모든 파일을 무시하도록 요청해야 합니다./.svn,/.idea그리고./target폴더.개인의 경로 정보와 관련된 모든 정보는 다음에 저장됩니다./.idea.

다른 모든 것은 서브버전이나 깃에 전념하기에 공정한 게임입니다.

우리 팀이 사용한 또 다른 접근 방식을 공유하기 위해:IDE 관련 파일을 IntelliJ가 인식하지 못하는 다른 위치로 이동하고 GIT가 무시하는 원하는 '활성' 위치로 복사하는 스크립트를 만들기만 하면 됩니다.

이 방법의 이점은 버전 제어를 통해 IDE 설정을 공유하는 옵션을 유지했다는 것입니다.유일한 단점은 스크립트를 실행할 시기를 결정해야 한다는 것입니다(워크스페이스 클론당 한 번 또는 변경할 시기). 빌드 프로세스 또는 병합 후 후크에 스크립트를 통합하여 이를 자동화할 수 있습니다.

이 접근 방식은 IntelliJ가 특정 위치에서만 설정 파일을 검색하므로 프레임워크 구성 파일에도 적용됩니다.사실 우리는 Grails.properties 파일을 같은 방식으로 무시했기 때문에 개발자들이 실수로 로컬 구성 변경 사항을 체크인하지 않습니다.

언급URL : https://stackoverflow.com/questions/7060727/how-to-deal-with-intellij-idea-project-files-under-git-source-control-constantly