[ko] Translate community/developer-guide in korean

Signed-off-by: bluefriday <bluefriday86@gmail.com>
Signed-off-by: bluefriday86 <bluefriday86@gmail.com>
Signed-off-by: bluefriday <bluefriday86@gmail.com>

content/ko/docs/community/developers.md

@@ -0,0 +1,141 @@
+---
+title: "개발자 가이드"
+description: "헬름을 개발하는 사용자의 환경을 구성하기 위한 지침"
+weight: 1
+---
+
+이 가이드에서는 Helm에서 개발하기 위해 환경을 설정하는 방법을 설명한다. 
+
+## 전제 조건
+
+- Go 최신버전
+- kubectl 이 사용가능한 쿠버네티스 클러스터(선택사항)
+- 깃(Git)
+
+## 헬릉 구축하기
+
+우리는 프로그램을 구축하기 위해 Make를 사용한다. 시작하는 가장 간단한 방법은 다음과 같다.
+
+```console
+$ make
+```
+
+유의사항: `$ GOPATH / src / helm.sh / helm` 경로에서 실행하지 않으면 실패하게 된다. 
+`helm.sh` 디렉토리는 심볼릭 링크가 아니어야 한다. 
+그렇지 않으면 `build`가 관련 패키지를 찾지 못 한다.
+
+필요한 경우 먼저 종속성을 설치하고 `vendor/` 트리를 
+다시 빌드하고 구성을 확인한다. 그런 다음 `helm` 을 컴파일하여 
+`bin / helm` 에 배치합니다.
+
+모든 테스트를 실행하려면 (`vendor /` 에 대한 테스트를 실행하지 않고) `make test` 를 실행합니다.
+
+헬름을 로컬에서 실행하기 위해 사용자는 `bin/helm` 을 실행한다.
+
+- 헬름은 macOS 및 Alpine을 포함한 대부분의 Linux 배포에서 실행되는 것으로 알려져 있다.
+
+## 기여 가이드라인
+
+우리는 기여자를 환영한다. 이 프로젝트는 (a) 코드 품질이 높게 유지되고, 
+(b) 프로젝트가 일관되게 유지되고, (c) 기여가 오픈 소스 법적 요건을 
+따르도록 하기위해 몇 가지 지침을 설정했다. 우리의 의도는 기여자에게 
+부담을 주는 것이 아니라 사용자가 혜택을 받을 수 있도록 우아하고 
+고품질의 오픈 소스 코드를 구축하는 것이다.
+
+주요 기여 가이드를 읽고 숙지했는지 확인하도록 한다.
+
+https://github.com/helm/helm/blob/master/CONTRIBUTING.md
+
+### 코드의 구조
+
+Helm 프로젝트의 코드는 다음과 같이 구성된다.
+
+- 개별 프로그램은 `cmd /`에 위치 
+  `cmd/` 내부의 코드는 라이브러리 재사용을 위해 미설계
+- 공유 라이브러리는 `pkg/` 에 저장
+- `scripts/` 디렉토리에는 여러 유틸리티 스크립트가 포함. 
+  대부분은 CI/\CD 파이프 라인에서 사용
+
+Go 종속성 관리는 유동적이며 Helm의 수명주기 동안 
+변경 될 수 있다. 개발자는 종속성을 수동으로 관리하지 
+_않는것을_ 권장한다. 대신 프로젝트의 `Makefile` 에 
+의존하여 이를 수행하는 것이 좋다. Helm 3에서는 
+Go 버전 1.13 이상을 사용하는 것이 좋다.
+
+### 문서 작성하기
+
+Helm 3 이후로 문서는 자체 저장소로 이동되었다. 
+새로운 기능을 작성할 때 함께 제공되는 문서를 작성하여 
+[helm-www] (https://github.com/helm/helm-www) 레포지터리에 제출하자.
+
+### 깃 관례
+
+버전 제어 시스템으로는 깃을 사용한다. `master` 브랜치는 현재 개발 
+예정 브랜치의 홈 브랜치이다. 릴리스는 태그가 지정되며, 
+사용자가 헬름 v2 용 패치 작업을 하는 경우 `dev-v2` 브랜치는 
+헬름 2 릴리스가 잘려나간 기본 브랜치이다.
+
+GitHub PR (Pull Requests)을 통한 코드 변경을 허용한다. 
+이를 위한 작업 흐름은 다음과 같습니다.
+
+1. `$GOPATH/src` 디렉토리로 이동한 후에, `mkdir helm.sh; cd helm.sh` 을 수행하고,
+   `git clone` 으로 `github.com/helm/helm` 레포지터리를 복제
+2. 해당 레포지터리를 깃헙 계정으로 포크
+3. 레포지터리를 `$GOPATH/src/helm.sh/helm` 에 대한 원격 레포지터리로 추가
+4. 새로운 작업 브랜치를 만들고(`git checkout -b feat/my-feature`) 해당 브랜치에서
+   작업을 수행
+5. 리뷰를 위한 준비가 되면 브랜치를 깃헙으로 푸시한 다음 
+   새로운 풀 리퀘스트를 생성
+
+깃 커밋 메세지의 경우, 우리는 [유의적 커밋 메세지](https://karma-runner.github.io/0.13/dev/git-commit-msg.html)를 
+따른다.
+
+```
+fix(helm): add --foo flag to 'helm install'
+
+When 'helm install --foo bar' is run, this will print "foo" in the
+output regardless of the outcome of the installation.
+
+Closes #1234
+```
+
+일반적인 커밋 유형:
+
+- fix: 버그 또는 오류 수정
+- feat: 새로운 기능 추가
+- docs: 문서 변경
+- test: 테스트 개선
+- ref: 기존 코드 리팩터링
+
+일반적인 범위:
+
+- helm: 헬름 CLI
+- pkg/lint: 린트(lint) 패키지. 모든 패키지에 대하여 유사규칙을 따름
+- `*`: 두 개 이상의 범위
+
+더 보기:
+- [Deis 
+  가이드라인](https://github.com/deis/workflow/blob/master/src/contributing/submitting-a-pull-request.md)이 
+  이 섹션에서 영감을 받았다.
+- Karma Runner는 유의적 커밋 메세지에 대한 아이디어를 
+  [정의](https://karma-runner.github.io/0.13/dev/git-commit-msg.html)
+  한다.
+
+### Go 관례
+
+우리는 Go 코딩 스타일 표준을 매우 밀접하게 따른다. 일반적으로 `go fmt` 를 실행하여
+사용자의 코드를 더욱 아름답게 만들수 있다.
+
+또한 일반적으로 `go lint` 및 `gometalinter` 에서 권장하는 규칙을 따른다.
+스타일 적합성을 테스트 하려는 경우 `make test-style` 을 실행하라.
+
+더 보기:
+
+- Effective Go [포맷
+  소개](https://golang.org/doc/effective_go.html#formatting).
+- Go 위키에서 볼 수 있는 훌륭한 
+  [포맷](https://github.com/golang/go/wiki/CodeReviewComments) 기사
+
+`make test` 타겟을 실행하면 단위 테스트가 실행될 뿐만아니라 스타일 테스트도 실행된다.
+`make test` 대상이 문체 상의 이유로 실패하면 PR 은 병합할 준비가
+되지 않은 것으로 간주한다.