Git 소스 제어 하에서 IntelliJ IDEA 프로젝트 파일을 처리하는 방법은 끊임없이 변경됩니까?

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

그러나 IDEA에서 거의 모든 작업을 수행하면 해당 파일이 약간 변경됩니다. IDEA의 문제 데이터베이스 ( IDEA-64312 )에 문제가 있으므로 IDEA의 버그로 간주 될 수 있지만 가까운 미래에 우리가 살아야 할 문제 일 것입니다.

최근까지 Subversion을 사용하고 있었지만 최근에 Git으로 전환했습니다. 우리는 다른 사람들과 공유하고 싶었던 프로젝트 파일 변경 사항이 없다면 무시하고 체크인하지 않은 프로젝트 파일의 변경 목록을 사용하는 데 익숙했습니다. 그러나 Git을 사용하면 실질적인 힘은 (우리가 탐구하는 것에서) 지속적으로 분기하는 것이 좋습니다. 분 기간 전환은 항상 프로젝트 파일이 수정되어 어려움을 겪습니다. 종종 변경 사항을 병합하여 새 브랜치에 적용되는 프로젝트 파일 변경 사항을 처리하려고 할 때가 있습니다. 그러나 새 브랜치가 프로젝트 파일을 변경 한 경우 (예 : 브랜치가 아직 다른 브랜치에없는 새 모듈에서 작업하는 경우) git은 오류를 발생시킵니다. 브랜치에 변경 사항이 있고 로컬에 변경 사항이 있으면 파일을 병합하는 것이 합리적이며 그 점을 이해할 수 있습니다. 명령 행에서 "git checkout"명령에 "-f"를 사용하여 로컬 변경 사항을 강제로 버리고 대신 지점을 사용하도록 할 수 있지만 (1) IDEA의 Git Checkout GUI 명령 (10.5.1) 우리가 찾을 수있는 옵션으로 그것을 가지고 있지 않은 것 같습니다. 따라서 정기적으로 명령 줄로 전환해야합니다. (2) 우리는 그것을 사용하는 습관을 갖고 싶어하지 않습니다. 플래그를 지정하고 Git에게 로컬 변경 사항을 버리라고 지시합니다.

그래서, 우리는 이것을 다루어야하는 옵션들에 대해 생각할 것입니다 :

1. 프로젝트 파일을 소스 제어에서 완전히 제거하십시오. 그것들을 .gitignore에 넣고 다른 방법으로 다른 사람이나 다른 이름으로 소스 컨트롤에 넣어서 다른 방법으로 각 사람과 TeamCity에 배포하십시오. 우리 팀의 규모가 작기 때문에이 옵션은 충분히 고려할 수 있지만 그리 좋지는 않습니다.
2. 주어진 시간에 어떤 브랜치에 어떤 파일이 있는지 관리하려고 계속 노력하십시오. 이 과정에서 각 개발자가 시스템에 각 프로젝트의 사본을 두 개 이상 갖도록 권장 할 수 있으므로 각기 다른 프로젝트 파일 세트를 사용하여 각기 다른 지점에 체크 아웃 할 수 있습니다.
3. 소스 제어 및 .gitignore 파일에없는 모듈 (.iml) 파일을 사용하여 소스 제어에 프로젝트 (.ipr) 만 사용하십시오. .ipr에서 정기적으로 자체적으로 전환되는 주된 것은 공유 빌드 구성의 순서이지만, 설정 방법에 대해 별도로 정보를 공유 할 수 있습니다. IDEA가 파일, 특히 새로운 체크 아웃의 일부 파일 만 갖는 이런 종류의 문제를 어떻게 처리하는지 잘 모르겠습니다.

우리가 놓친 명백한 (또는 명백하지 않은) 해결책이 있기를 바라고 생각합니다. 아마도 Git과 IDEA가 가지고있는 거대한 사용자 정의 가능성을 다룰 것입니다. 그러나 우리 가이 문제를 가진 유일한 팀이 될 수 없었던 것 같습니다. Stack Overflow와 비슷한 질문에는 3495191 , 1000512 및 3873872 가 포함되지만 정확히 같은 문제인지 알지 못하며 누군가가 내가 접근 한 다양한 접근법에 대한 장단점을 생각해 낼 수 있습니다. 해당 질문에 대한 답변에 제시된 접근 방식 또는 권장되는 접근 방식

IDEA의 디렉토리 기반 프로젝트 구조를 사용할 수 있습니다 . 여기서 설정은 .ipr 파일 대신 .idea 디렉토리에 저장됩니다. 버전 관리에 저장된 내용을보다 세밀하게 제어 할 수 있습니다. .iml 파일은 여전히 ​​존재하므로 무작위 변경 사항을 해결하지는 못하지만 (소스 제어에서 벗어날 수 있습니까?) 코드 스타일 및 검사 프로파일과 같은 것을 공유하는 것은 쉽습니다. 자체 파일의 .idea 디렉토리에 있습니다.

공식 DOC에서 : http://devnet.jetbrains.com/docs/DOC-1186

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

.ipr 파일 기반 형식

프로젝트 .ipr 파일 및 모든 .iml 모듈 파일을 공유하십시오. .iws 파일은 사용자 별 설정을 저장하므로 공유하지 마십시오.

.idea 디렉토리 기반 형식

사용자 별 설정을 저장하는 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에 추가됨).

Google 팀은 경로 별 IntelliJ 파일을 체크인하지 않습니다. 사람들은 IDE 사용법과 프로젝트 설정 방법을 알고 있다고 가정합니다. IntelliJ 파일은 '무시 된'변경 목록으로 이동합니다.

최신 정보:

Maven과 기본 디렉토리 구조를 사용하고 있기 때문에 대답이 더 쉽습니다.

IntelliJ에 모두에서 파일 무시하도록 요청해야한다 /.svn, /.idea및 /target폴더를. 개인의 경로 정보와 관련된 모든 것은에 저장됩니다 /.idea.

그 밖의 모든 것은 Subversion 또는 Git에 최선을 다하는 공정한 게임입니다.

우리 팀이 사용한 다른 접근 방식을 공유하기 위해 : Intel 관련 IDE가 인식하지 못하는 다른 위치로 IDE 관련 파일을 옮기고 GIT에서 무시되는 원하는 '활성'위치로 복사하는 스크립트를 작성하십시오.

이 방법의 장점은 버전 제어를 통해 IDE 설정을 공유하는 옵션을 유지한다는 것입니다. 유일한 단점은 스크립트를 실행할시기 (아마도 작업 공간 복제 당 한 번 또는 변경이 필요한 경우)를 결정해야하며 빌드 프로세스 또는 병합 후 후크에 스크립트를 통합하여이를 자동화 할 수 있습니다.

이 방법은 IntelliJ가 설정 파일의 특정 위치 만 검색하므로 프레임 워크 구성 파일에도 적용됩니다. 실제로 Grails .properties 파일을 동일한 방식으로 무시했기 때문에 개발자가 실수로 로컬 구성 변경을 체크인하지 않습니다.