Go 공급업체 디렉토리를 커밋할지 여부: 재현 가능한 빌드와 리포지토리 크기?

Go 종속성 관리를 위한 벤더링 관행

Go 개발에서는 종속성을 관리하는 것이 중요합니다. dep 도구를 사용하면 공급업체 디렉터리를 버전 관리에 커밋하는 것이 모범 사례인지 여부에 대한 의문이 제기됩니다.

공급업체 디렉터리 커밋

이 문제는 공식 dep FAQ에서 다룹니다. 질문:

장점:

• 재현 가능한 빌드: 이름 바꾸기, 삭제 또는 기록 덮어쓰기와 같은 업스트림 변경 사항에 관계없이 일관된 빌드를 보장합니다.
• 종속성 관리 감소: 복제, 병합 및 기타 저장소 작업 후에 dep verify를 실행할 필요가 없습니다.

단점:

• 더 큰 저장소 크기: 공급업체 디렉토리는 저장소의 크기를 늘리십시오.
• 차이 충돌: Gopkg.lock을 수정하면 공급업체 디렉토리가 변경되어 풀 요청에서 차등 충돌이 발생할 수 있습니다.

대안 : 수동으로 dep verify 실행

또는 모범 사례에서는 이후에 dep verify를 수동으로 실행하는 것이 좋습니다. 저장소 체크아웃. 이 접근 방식에는 다음과 같은 장점이 있습니다.

• 더 작은 저장소 크기: 공급업체 디렉토리가 커밋되지 않아 저장소의 전체 공간이 줄어듭니다.
• 더 깔끔한 diff: PR diff에는 종속성에 대한 변경 사항만 포함됩니다. Gopkg.lock의 정의, 공급업체의 소음 방지 디렉토리.

결론

공급업체 디렉토리를 커밋할지 여부는 특정 프로젝트 요구 사항에 따라 결정됩니다. 재현 가능한 빌드와 간소화된 종속성 관리를 위해서는 공급업체 디렉터리를 커밋하는 것이 좋습니다. 그러나 저장소 크기와 정리 diff의 우선순위가 더 높은 경우 체크아웃 후 수동으로 dep verify를 실행하는 것이 더 적합한 옵션일 수 있습니다.

위 내용은 Go 공급업체 디렉토리를 커밋할지 여부: 재현 가능한 빌드와 리포지토리 크기?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!