IDE 프로젝트의 리포지토리에 포함해야 할 내용

이 경우 Netbeans에서 생성 된 프로젝트를 추가하고 싶지만이 질문은 대부분의 IDE에서 일반적입니다. 간단히, 저장소에 무엇을 포함시켜야합니까? 예를 들어 Netbeans는 nbproject 폴더를 생성하고 eclipse는 .settings 폴더를 생성합니다. 저장소에 폴더를 포함시켜야하는 경우 프로젝트 별 설정을 포함하거나 포함하지 않을 때의 장점 / 단점은 무엇입니까?

이 경우 개인 프로젝트이므로 다른 사람들이 작업을 시작할 것이라고는 생각하지 않지만 최소한의 프로젝트 설정을 추가하여 프로젝트 자체가 다른 컴퓨터에서 작업을 쉽게 시작할 수 있도록하는 것이 좋습니다.

실제로는 데이터가 무엇인지에 달려 있으며 경우에 따라 개별 파일에 대해서도 사례별로 결정해야합니다. 해당 파일의 내용을 살펴보십시오. 더 자주 당신은 그들이 무엇을 의미하는지 말할 수 있습니다. IDE 창의 위치 및 크기와 같은 것은 소스 제어에서 원하지 않는 것입니다.

그러나 일부 IDE 프로젝트 파일은 중요한 프로젝트 메타 데이터입니다. Netbeans를 잘 모르지만 Eclipse의 경우 .project 파일은 IDE에 프로젝트 이름, Java 웹 프로젝트 등을 알려주며 .classpath 파일에는 소스 폴더 및 라이브러리에 대한 정보가 들어 있습니다. .settings 디렉토리의 일부 파일도 마찬가지로 중요 할 수 있습니다. 예를 들어 org.eclipse.core.resources.prefs에는 어떤 파일에 어떤 인코딩을 사용해야하는지에 대한 정보가 들어 있습니다.

프로젝트 메타 데이터로서,이 내용은 소스 제어에서 버전을 지정할 가치가 있습니다.

일부 IDE는 다른 IDE에서 프로젝트 메타 데이터를 가져올 수 있습니다. 특정 IDE에 묶이지 않은 형태로 작성하는 것이 더 좋습니다.

Java의 경우 Maven 과 같은 것이 있습니다. 프로젝트 구조에 강력한 규칙을 적용하고 프로젝트 메타 데이터 (예 : 라이브러리 종속성)를 한 지점 (프로젝트의 기본 디렉토리 및 물론 소스 제어에있는 pom.xml이라는 파일)으로 지정할 수 있습니다. Maven 구성에서 IDE 프로젝트 파일을 생성하는 플러그인과 프로젝트 빌드 프로세스를 자동화하거나 다른 작업을 수행 할 수있는 플러그인이 있습니다. 때로는 불필요하게 복잡 해져서 배우는 데 시간이 걸리는 것처럼 느껴지지만 일반적으로 이점은 그만한 가치가 있습니다.

이것은 실제로 저장소에 어떤 종류의 정보를 갖고 싶은지에 달려 있습니다. 커밋 할 때 열어서 편집 한 파일에 대한 모든 것을 원하고 리포지토리를 사용하는 유일한 사람이라면 모든 것을 커밋하지만 다른 컴퓨터에서는 작동하지 않을 수 있습니다. .

동일한 IDE를 사용하지 않는 다른 사람들과 코드를 공유하려면 프로젝트 별 구현없이 코드 자체를 커밋하십시오.

모든 사람이 동일한 IDE를 사용한다는 것을 알고 있다면 컴퓨터에 국한되지 않은 것, 즉 IDE 자체에 대한 설정 파일 / 폴더, 프로젝트를 이미 가져올 수있는 기능을 포함 할 수 있습니다. IDE는 그것을 기대합니다.

개발 을 돕고 빌드 / 릴리스 또는 프로젝트 자체에 쓸모없는 아티팩트는 포함 되지 않아야 합니다. 리포지토리는 깨끗하고 깔끔해야하며 사용자 환경이 아닌 프로젝트와 관련된 것들만 있어야 합니다 . 레포는 당신의 습관을 알아 차려야합니다. 두 번째로 비슷한 일을 할 때 불필요하게 버그를 일으킬 것입니다 git status... 하지만 절대 변경하지 않았습니다 ... 아아 무시합니다.

좀 더 실용적인 예를 들어 보겠습니다 ( git여기서는 도구로 사용 하겠습니다).

메인 리포지토리 내의 (재귀 적) 서브 모듈이 IDE 관련 항목 (메인 프로젝트 환경을 방해 할 수도 있음)을 갖기를 원하지 않을 것입니다. 다른 사람 (또는 당신)이 작성한 코드이기 때문에 현재 프로젝트 내에서 사용합니다. 개발 된 환경이 아닙니다. 아마 다른 사람에게도 그렇게하고 싶지 않을 것입니다.

다른 컴퓨터에서 설정을 사용하려면 IDE 내부를 파고 그것을 지원하는 것이 무엇인지 확인하십시오. 이맥스 init와 이맥스 서버도 있습니다. 또는 .sh설정을 자동으로 수행하는 사용자 정의 매크로 또는 스크립트 ( )를 만들 수 있습니다 .

개인 프로젝트 인 경우 설정을 소스 제어에 저장한다고 말합니다. 개인적으로 개발 환경을 다시 설정하는 것보다 프로젝트에 대한 동기 부여를 해치는 것은 없습니다.

더 많은 사람들이 참여할 때, 나는 이런 것들을 소스 컨트롤에 넣지 않습니다. 우리 팀에는 IntelliJ, Sublime Text 및 Eclipse가 혼합되어 있습니다. IDE 파일은 혼란을 유발하고 사용하지 않는 IDE를 위해 다른 사람들이 해당 파일을 커밋합니다.

또한 프로젝트는 IDE에 의존해서는 안됩니다. 빌드 서버는 제품을 컴파일하기 위해 Eclipse를 부팅하지 않으므로 IDE가 없어야합니다. 더 작은 점은 프로젝트 내에서 개인 조직을 제거하는 것입니다. 예를 들어 IntelliJ에서는 프로젝트 내에서 많은 모듈을 사용하고 싶습니다. IntelliJ를 사용하는 다른 사람은 .iml (모듈) 파일을 저장하지 않기 때문에 이에 대해 걱정하지 않습니다.

팀이 동일한 IDE를 사용하는 것이 더 좋지만 누군가 절대 경로를 사용했기 때문에 잘못된 .classpath 항목을 커밋합니다. 이제 IDE를 사용하는 모든 사람이 그것에 대해 걱정합니다.

물론 단점은 누군가 프로젝트를 체크 아웃 할 때 더 많은 설정이 있다는 것입니다. 그만한 가치가 있다고 생각합니다. 우리는 의존성 관리를 위해 Ivy 를 사용 하고 설정, 의존성 등에 관한 정보를 가지고 있습니다. 이러한 초기 비용에도 불구하고 IDE 설정을 소스 제어에서 벗어나는 것이 가치가 있다고 생각합니다.