Go 코드를 GitHub에 결합하지 말자

Go는 코드를 가져올 위치를 네임스페이스로 사용해 중앙 패키지 관리 시스템 없이 라이브러리를 배포하고 가져올 수 있지만, 호스팅 주소를 그대로 쓰면 코드가 해당 제공업체에 결합됨 GitHub에서 GitLab으로 저장소를 옮길 때 코드의 기존 경로를 수정해야 하며, 수정하지 않으면 이전 버전을 가져오게 됨 저장소 위치 변경 작업이 부담스러워 GitLab, GitHub, Azure DevOps를 동시에 운영하고 세 서비스 비용을 모두 지불한 회사 사례가 있음 사용자 지정 도메인을 패키지 경로로 사용하면 연결 대상 저장소만 바꿀 수 있어, 호스팅을 이전해도 최종 사용자의 설치 명령을 유지할 수 있음 Go를 사용하는 상용 소프트웨어 개발팀은 불필요한 결합을 피하도록 내부 라이브러리와 패키지의 네임스페이스에 자체 도메인을 사용하는 것이 권장됨 저장소 주소를 네임스페이스로 쓸 때의 이점과 비용 Go에서 import "github.com/thetrueares/boneclone"처럼 저장소 위치를 경로로 지정하면 Git을 통해 코드를 가져옴 오픈 소스 라이브러리의 버그를 어디에 신고해야 하는지 쉽게 알 수 있음 중앙 패키지 관리 시스템 없이도 라이브러리를 쉽게 가져오고 배포할 수 있음 호스팅 위치를 그대로 네임스페이스로 쓰는 방식은 Go 커뮤니티에서 사실상 표준처럼 쓰이지만, 호스팅 제공업체 변경이 코드 변경으로 이어짐 GitLab 등으로 옮긴 뒤에도 기존 경로를 유지하면 이전 버전을 가져옴 경로 변경에 필요한 작업량 때문에 호스팅 제공업체를 바꾸기 어려워질 수 있음 한 회사는 코드 위치를 바꿀 시간이 없다는 이유로 GitLab, GitHub, Azure DevOps를 동시에 운영하고 세 호스팅 서비스 비용을 지불함 이 사례를 계기로 여러 Git 호스팅 플랫폼에 걸쳐 스켈레톤 코드를 복제하는 Boneclone이 만들어짐 자체 도메인으로 경로를 유지하는 방법 사용자 지정 도메인의 예로 go.iain.rocks, go.uber.org, go.mongodb.org가 있음 go.iain.rocks/boneclone을 github.com/thetrueares/boneclone에 연결하고, 이후 GitLab으로 옮길 때 연결 대상만 변경할 수 있음 최종 사용자는 같은 설치 명령을 계속 사용할 수 있음 Nginx 설정으로 일반 방문자와 Go 도구의 요청을 구분함 쿼리 문자열에 go-get=1이 없으면 요청 경로를 붙여 https://gi...