.sln 파일을 소스 제어에 커밋하는 것이 가장 좋은 방법입니까? 그렇게하는 것이 적절하거나 부적절합니까?
업데이트
답변에는 몇 가지 좋은 점이 있습니다. 응답 해 주셔서 감사합니다!
답변
다른 답변에서 솔루션 파일이 유용하고 공식 빌드에 사용되지 않더라도 커밋되어야한다는 것이 분명하다고 생각합니다. 정의 / 선언으로 이동과 같은 Visual Studio 기능을 사용하는 모든 사용자에게 편리합니다.
기본적으로 절대 경로 또는 기타 시스템 특정 아티팩트는 포함하지 않습니다. (안타깝게도 일부 추가 기능 도구 (예 : AMD CodeAnalyst)는이 속성을 제대로 유지하지 못합니다.) 프로젝트 파일 (C ++ 및 C # 모두)에서 상대 경로를 사용하는 데주의를 기울이면 해당 도구는 시스템과 무관합니다. 너무.
아마도 더 유용한 질문은 다음과 같습니다. 어떤 파일을 제외해야합니까? 내 VS 2008 프로젝트에 대한 내 .gitignore 파일의 내용은 다음과 같습니다.
*.suo
*.user
*.ncb
Debug/
Release/
CodeAnalyst/
(마지막 항목은 AMD CodeAnalyst 프로파일 러용입니다.)
VS 2010의 경우 다음도 제외해야합니다.
ipch/
*.sdf
*.opensdf
답변
예-항상 적절하다고 생각합니다. 사용자 별 설정은 다른 파일에 있습니다.
답변
네,해야합니다. 솔루션 파일에는 솔루션의 전체 구조에 대한 정보 만 포함됩니다. 정보는 솔루션 전체에 적용되며 프로젝트의 모든 개발자에게 공통적 일 수 있습니다.
사용자 별 설정은 포함되어 있지 않습니다.
답변
당신은 확실히 그것을 가져야합니다. 다른 사람들이 언급 한 이유 외에도 전체 프로젝트의 한 단계 빌드를 가능하게하는 것이 필요합니다.
답변
나는 일반적으로 솔루션 파일을 체크인해야한다는 데 동의하지만, 내가 일하는 회사에서 다른 일을했습니다. 우리는 상당히 큰 저장소를 가지고 있으며 개발자는 때때로 시스템의 다른 부분에서 작업합니다. 우리가 일하는 방식을 지원하기 위해 우리는 하나의 큰 솔루션 파일 또는 여러 개의 작은 파일을 가질 것입니다. 둘 다 몇 가지 단점이 있으며 개발자 측에서 수동 작업이 필요합니다. 이를 피하기 위해 우리는 모든 것을 처리하는 플러그인을 만들었습니다.
플러그인을 사용하면 각 개발자가 저장소에서 관련 프로젝트를 선택하기 만하면 작업 할 소스 트리의 하위 집합을 확인할 수 있습니다. 그런 다음 플러그인은 솔루션 파일을 생성하고 주어진 솔루션에 대해 즉시 프로젝트 파일을 수정합니다. 또한 참조를 처리합니다. 즉, 개발자가해야 할 일은 적절한 프로젝트를 선택하고 필요한 파일을 생성 / 수정하는 것입니다. 이를 통해 회사 표준을 보장하기 위해 다양한 기타 설정을 사용자 지정할 수 있습니다.
또한 플러그인을 사용하여 다양한 체크인 정책을 지원하므로 일반적으로 사용자가 결함이 있거나 규정을 준수하지 않는 코드를 저장소에 제출하는 것을 방지합니다.
답변
예, 커밋해야 할 사항은 다음과 같습니다.
- 솔루션 (* .sln),
- 프로젝트 파일,
- 모든 소스 파일,
- 앱 구성 파일
- 빌드 스크립트
커밋 하지 말아야 할 사항 은 다음과 같습니다.
- 솔루션 사용자 옵션 (.suo) 파일,
- 생성 된 파일 빌드 (예 : 빌드 스크립트 사용) [편집 :] -필요한 모든 빌드 스크립트와 도구를 버전 제어하에 사용할 수있는 경우에만 (빌드가 cvs 기록에서 인증되었는지 확인하기 위해)
다른 자동 생성 파일과 관련하여 별도의 스레드가 있습니다.
답변
예, 소스 제어의 일부 여야합니다. 응용 프로그램에서 프로젝트를 추가 / 제거 할 때마다 .sln이 업데이트되고 소스 제어하에 두는 것이 좋습니다. 애플리케이션 코드 2 버전을 다시 꺼내 직접 빌드를 수행 할 수 있습니다 (필요한 경우).
