이것은 제가 참여하고있는 토론입니다. 더 많은 의견과 관점을 얻고 싶습니다.
DB 작업을 처리하기 위해 빌드 시간에 생성되는 클래스가 있습니다 (이 특정 경우에는 SubSonic을 사용하지만 질문에 대해 매우 중요하다고 생각하지 않습니다). 생성은 Visual Studio에서 사전 빌드 단계로 설정됩니다. 따라서 개발자 (또는 공식 빌드 프로세스)가 빌드를 실행할 때마다 이러한 클래스가 생성 된 다음 프로젝트로 컴파일됩니다.
이제 일부 사람들은 이러한 클래스를 소스 제어에 저장하면 코드가 자신의 환경에서 생성 된 것과 일치하지 않을 경우 혼란을 일으킬 수 있다고 주장합니다.
일반적으로 블랙 박스로 취급 되더라도 코드의 역사를 추적 할 수있는 방법을 갖고 싶습니다.
어떤 주장이나 반대 주장?
업데이트 : 나는 결정적인 대답이 하나 있다고 정말로 믿었 기 때문에이 질문을했습니다. 모든 답변을 살펴보면 그런 답변은 없다고 확신 할 수 있습니다. 결정은 둘 이상의 매개 변수를 기반으로해야합니다. 아래 답변을 읽으면이 문제를 결정할 때 스스로에게 물어봐야 할 질문 유형에 대한 매우 좋은 지침이 될 수 있습니다.
위에서 언급 한 이유 때문에이 시점에서 수락 된 답변을 선택하지 않겠습니다.
답변
소스 제어에 저장하는 것은 가치가있는 것보다 더 많은 문제입니다.
어떤 가치가 되려면 빌드를 할 때마다 커밋을해야합니다.
일반적으로 우리는 생성 된 코드 (idl, jaxb 등)를 내가 작업하는 소스 제어 외부에 두며 문제가되지 않았습니다.
답변
소스 코드 제어에 넣으십시오. 미래의 개발자가 작성한 모든 기록을 사용할 수 있다는 장점은 동기화 후 가끔 재 구축하는 사소한 고통보다 큽니다.
답변
내 개인 저장소의 소스 트리에 대한 변경 사항을 표시하고 싶을 때마다 모든 ‘생성 된 파일’이 변경된 것으로 표시되고 커밋이 필요합니다.
자동 생성 된 변경 사항이 아닌 수행 된 실제 업데이트 만 포함하는보다 깔끔한 수정 목록을 갖고 싶습니다.
그대로두고 빌드 후에 생성 된 각 파일에 ‘무시’를 추가합니다.
답변
이런 식으로보세요 : 개체 파일을 소스 제어로 확인합니까? 생성 된 소스 파일은 개체 파일, 라이브러리 및 실행 파일과 같은 빌드 아티팩트입니다. 동일하게 취급되어야합니다. 대부분은 생성 된 개체 파일과 실행 파일을 소스 제어로 검사해서는 안된다고 주장합니다. 생성 된 소스에 동일한 인수가 적용됩니다.
생성 된 파일의 기록 버전을 확인해야하는 경우 해당 소스의 기록 버전과 동기화하고 다시 빌드 할 수 있습니다.
모든 종류의 생성 된 파일을 소스 제어로 확인하는 것은 데이터베이스 비정규 화와 유사합니다. 있습니다 가끔 (일반적으로 성능)이 작업을 수행하는 이유는, 그러나 데이터가 비정규되면 정확성과 일관성을 유지하기 위해 더 힘들어 질수록이 큰 관심 만 수행해야합니다.
답변
생성 된 코드 (또는 다른 아티팩트)를 소스 제어에 추가하지 말아야합니다. 생성 된 코드가 주어진 입력에 대해 동일하면 비교하려는 버전을 확인하고 비교할 코드를 생성 할 수 있습니다.
답변
나는 DRY 원칙이라고 부릅니다. 빌드시 이러한 코드 파일을 생성하는 데 사용되는 “소스 파일”이 저장소에 이미있는 경우 동일한 코드를 “두 번”커밋 할 필요가 없습니다.
또한 언젠가 코드 생성이 중단되는 경우 이러한 방식으로 일부 문제를 방지 할 수 있습니다.
답변
아니요, 세 가지 이유가 있습니다.
-
소스 코드는 현재 또는 이전 시점을 기준으로 애플리케이션의 스냅 샷을 재현하는 데 필요하고 충분합니다. 그 이상도 이하도 아닙니다. 이것이 의미하는 것은 누군가가 체크인 한 모든 것에 대한 책임이 있다는 것입니다. 일반적으로 저는 제가 작성한 코드에 대해 책임을지는 것이 기쁩니다. 그러나 제가 작성한 코드의 결과로 생성 된 코드는 아닙니다.
-
나는 누군가가 현재 일 수도 있고 아닐 수도있는 중간 코드를 사용하여 기본 소스에서 빌드를 바로 가기하려고하는 유혹을 받고 싶지 않습니다 (더 중요한 것은 제가 책임을 받아들이고 싶지 않다는 것입니다.). 일부 사람들은 부분 빌드를 기반으로하는 중간 코드에서 충돌을 디버깅하는 데 의미없는 프로세스에 휩싸 이도록 유혹합니다.
-
일단 소스 제어에 들어가면 a. 거기있는 것, b. 그것은 현재이고 c. 다른 모든 것과 안정적으로 통합 할 수 있습니다. 여기에는 더 이상 사용하지 않을 때 제거하는 것도 포함됩니다. 그 책임이 적을수록 좋습니다.
