`dep`을 사용하여 Go 프로젝트에서 `vendor` 디렉토리를 커밋할지 말지?

Dep in Go 프로젝트를 통한 공급업체 디렉토리 관리

Go 개발에서 dep 도구를 통해 종속성을 관리하면 처리 모범 사례에 대한 의문이 생길 수 있습니다. 벤더 디렉토리. 그러한 질문 중 하나는 공급업체 디렉토리를 버전 관리에 적용하는 것이 바람직한지 여부입니다.

공식 Dep 문서에서 이 문제에 대한 지침을 제공합니다. FAQ 섹션에서는 공급업체 디렉토리를 직접 커밋하는 문제를 다룹니다. 부서에 따르면 결정은 개인 선호도와 우선순위에 따라 다릅니다.

공급업체 디렉토리 커밋의 장점:

• 재현 가능한 빌드: 공급업체 디렉터리를 커밋하면 이름 바꾸기, 삭제 등의 업스트림 변경 사항을 보호하여 재현 가능한 빌드가 보장됩니다. 또는 기록을 덮어씁니다.
• 감소된 종속성 관리: 공급업체 디렉터리를 커밋한 후에는 go get 또는 저장소와 같은 일반적인 작업에 따라 Gopkg.lock과 동기화하기 위한 추가 dep 확인 단계가 필요하지 않습니다.

공급업체 커밋의 단점 디렉터리:

• 더 큰 저장소 크기: 공급업체 디렉터리로 인해 저장소 크기가 크게 늘어날 수 있습니다. 그러나 prune 명령을 사용하면 이 문제를 완화하는 데 도움이 될 수 있습니다.
• PR 차이 변경 사항: Gopkg.lock 파일을 변경하면 공급업체 디렉터리 내의 파일에 대한 수정 사항을 포함하는 PR 차이가 발생할 수 있습니다. 특히 GitHub는 기본적으로 이러한 파일을 숨깁니다.

궁극적으로 공급업체 디렉터리를 커밋할지 여부는 특정 프로젝트 요구 사항 및 기본 설정에 따라 결정됩니다. 재현 가능한 빌드와 간소화된 종속성 관리가 저장소 크기 및 PR 차이점 명확성보다 더 중요한 경우 공급업체 디렉토리를 커밋하는 것이 선호되는 접근 방식일 수 있습니다.

위 내용은 `dep`을 사용하여 Go 프로젝트에서 `vendor` 디렉토리를 커밋할지 말지?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!