|
|
|
|
@ -15,13 +15,15 @@ card:
|
|
|
|
|
[새 기능 문서화](/docs/contribute/new-content/new-features/)를 참고한다.
|
|
|
|
|
{{< /note >}}
|
|
|
|
|
|
|
|
|
|
새 콘텐츠 페이지를 기여하거나 기존 콘텐츠 페이지를 개선하려면, 풀 리퀘스트(PR)를 연다. [시작하기 전에](/ko/docs/contribute/new-content/#before-you-begin) 섹션의 모든 요구 사항을 준수해야 한다.
|
|
|
|
|
|
|
|
|
|
변경 사항이 작거나, git에 익숙하지 않은 경우, [GitHub을 사용하여 변경하기](#github을-사용하여-변경하기)를 읽고 페이지를 편집하는 방법을 알아보자.
|
|
|
|
|
|
|
|
|
|
변경 사항이 많으면, [로컬 포크에서 작업하기](#fork-the-repo)를 읽고 컴퓨터에서 로컬로 변경하는 방법을 배운다.
|
|
|
|
|
새 콘텐츠 페이지를 기여하거나 기존 콘텐츠 페이지를 개선하려면, 풀 리퀘스트(PR)를 연다.
|
|
|
|
|
[시작하기 전에](/ko/docs/contribute/new-content/#before-you-begin) 섹션의
|
|
|
|
|
모든 요구 사항을 준수해야 한다.
|
|
|
|
|
|
|
|
|
|
변경 사항이 적거나, git에 익숙하지 않은 경우,
|
|
|
|
|
[GitHub을 사용하여 변경하기](#github을-사용하여-변경하기)를 읽고 페이지를 편집하는 방법을 알아보자.
|
|
|
|
|
|
|
|
|
|
변경 사항이 많으면, [로컬 포크에서 작업하기](#fork-the-repo)를 읽고
|
|
|
|
|
컴퓨터에서 로컬로 변경하는 방법을 배운다.
|
|
|
|
|
|
|
|
|
|
<!-- body -->
|
|
|
|
|
|
|
|
|
|
@ -61,7 +63,7 @@ class tasks,tasks2 white
|
|
|
|
|
class id1 k8s
|
|
|
|
|
{{</ mermaid >}}
|
|
|
|
|
|
|
|
|
|
***그림 - GitHub 상에서 PR을 여는 단계***
|
|
|
|
|
그림 - GitHub 상에서 PR을 여는 단계
|
|
|
|
|
|
|
|
|
|
1. 이슈가 있는 페이지에서, 오른쪽 상단에 있는 연필 아이콘을 선택한다.
|
|
|
|
|
페이지 하단으로 스크롤 하여 **페이지 편집하기** 를 선택할 수도 있다.
|
|
|
|
|
@ -91,7 +93,8 @@ class id1 k8s
|
|
|
|
|
- **Allow edits from maintainers** 체크박스는 선택된 상태로 둔다.
|
|
|
|
|
|
|
|
|
|
{{< note >}}
|
|
|
|
|
PR 설명은 리뷰어가 변경 사항을 이해하는 데 유용한 방법이다. 자세한 내용은 [PR 열기](#open-a-pr)를 참고한다.
|
|
|
|
|
PR 설명은 리뷰어가 변경 사항을 이해하는 데 유용한 방법이다.
|
|
|
|
|
자세한 내용은 [PR 열기](#open-a-pr)를 참고한다.
|
|
|
|
|
{{</ note >}}
|
|
|
|
|
|
|
|
|
|
7. **Create pull request** 를 선택한다.
|
|
|
|
|
@ -120,7 +123,8 @@ GitHub 사용자 이름을 코멘트로 남긴다.
|
|
|
|
|
git에 익숙하거나, 변경 사항이 몇 줄보다 클 경우,
|
|
|
|
|
로컬 포크로 작업한다.
|
|
|
|
|
|
|
|
|
|
컴퓨터에 [git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git)이 설치되어 있는지 확인한다. git UI 애플리케이션을 사용할 수도 있다.
|
|
|
|
|
컴퓨터에 [git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git)이 설치되어 있는지 확인한다.
|
|
|
|
|
git UI 애플리케이션을 사용할 수도 있다.
|
|
|
|
|
|
|
|
|
|
아래 그림은 로컬 포크에서 작업할 때의 단계를 나타낸다. 상세 사항도 소개되어 있다.
|
|
|
|
|
|
|
|
|
|
@ -151,7 +155,8 @@ class 1,2,3,3a,4,5,6 grey
|
|
|
|
|
class S,T spacewhite
|
|
|
|
|
class changes,changes2 white
|
|
|
|
|
{{</ mermaid >}}
|
|
|
|
|
***그림 - 로컬 포크에서 변경 사항 작업하기***
|
|
|
|
|
|
|
|
|
|
그림 - 로컬 포크에서 변경 사항 작업하기
|
|
|
|
|
|
|
|
|
|
### kubernetes/website 리포지터리 포크하기
|
|
|
|
|
|
|
|
|
|
@ -201,7 +206,10 @@ class changes,changes2 white
|
|
|
|
|
이를 통해 변경을 시작하기 전에 로컬 리포지터리가 최신 상태인지 확인한다.
|
|
|
|
|
|
|
|
|
|
{{< note >}}
|
|
|
|
|
이 워크플로는 [쿠버네티스 커뮤니티 GitHub 워크플로](https://github.com/kubernetes/community/blob/master/contributors/guide/github-workflow.md)와 다르다. 포크에 업데이트를 푸시하기 전에 로컬의 `main` 복사본을 `upstream/main` 와 병합할 필요가 없다.
|
|
|
|
|
이 워크플로는
|
|
|
|
|
[쿠버네티스 커뮤니티 GitHub 워크플로](https://github.com/kubernetes/community/blob/master/contributors/guide/github-workflow.md)
|
|
|
|
|
와 다르다.
|
|
|
|
|
포크에 업데이트를 푸시하기 전에 로컬의 `main` 복사본을 `upstream/main` 와 병합할 필요가 없다.
|
|
|
|
|
{{< /note >}}
|
|
|
|
|
|
|
|
|
|
### 브랜치 만들기
|
|
|
|
|
@ -211,14 +219,16 @@ class changes,changes2 white
|
|
|
|
|
- 기존 콘텐츠를 개선하려면, `upstream/main` 를 사용한다.
|
|
|
|
|
- 기존 기능에 대한 새로운 콘텐츠를 작성하려면, `upstream/main` 를 사용한다.
|
|
|
|
|
- 현지화된 콘텐츠의 경우, 현지화 규칙을 사용한다. 자세한 내용은 [쿠버네티스 문서 현지화](/ko/docs/contribute/localization_ko/)를 참고한다.
|
|
|
|
|
- 다가오는 쿠버네티스 릴리스의 새로운 기능에 대해서는 기능 브랜치(feature branch)를 사용한다. 자세한 정보는 [릴리스 문서화](/docs/contribute/new-content/new-features/)를 참고한다.
|
|
|
|
|
- 다가오는 쿠버네티스 릴리스의 새로운 기능에 대해서는 기능 브랜치(feature branch)를 사용한다.
|
|
|
|
|
자세한 정보는 [릴리스 문서화](/docs/contribute/new-content/new-features/)를 참고한다.
|
|
|
|
|
- 콘텐츠 재구성과 같이 여러 SIG Docs 기여자들이 협업하는 장기적인 작업에는,
|
|
|
|
|
해당 작업을 위해 작성된 특정 기능 브랜치를
|
|
|
|
|
사용한다.
|
|
|
|
|
|
|
|
|
|
브랜치 선택에 도움이 필요하면, 슬랙 채널 `#sig-docs` 에 문의한다.
|
|
|
|
|
|
|
|
|
|
2. 1단계에서 식별된 브랜치를 기반으로 새 브랜치를 작성한다. 이 예에서는 기본 브랜치가 `upstream/main` 라고 가정한다.
|
|
|
|
|
2. 1단계에서 식별된 브랜치를 기반으로 새 브랜치를 작성한다.
|
|
|
|
|
이 예에서는 기본 브랜치가 `upstream/main` 라고 가정한다.
|
|
|
|
|
|
|
|
|
|
```bash
|
|
|
|
|
git checkout -b <my_new_branch> upstream/main
|
|
|
|
|
@ -268,7 +278,8 @@ class changes,changes2 white
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
{{< note >}}
|
|
|
|
|
커밋 메시지에 [GitHub 키워드](https://help.github.com/en/github/managing-your-work-on-github/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword)를 사용하지 말자. 나중에 풀 리퀘스트 설명에 추가할
|
|
|
|
|
커밋 메시지에 [GitHub 키워드](https://help.github.com/en/github/managing-your-work-on-github/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword)를 사용하지 말자.
|
|
|
|
|
나중에 풀 리퀘스트 설명에 추가할
|
|
|
|
|
수 있다.
|
|
|
|
|
{{< /note >}}
|
|
|
|
|
|
|
|
|
|
@ -280,39 +291,34 @@ class changes,changes2 white
|
|
|
|
|
|
|
|
|
|
### 로컬에서 변경 사항 미리보기 {#preview-locally}
|
|
|
|
|
|
|
|
|
|
변경 사항을 푸시하거나 풀 리퀘스트를 열기 전에 변경 사항을 로컬에서 미리 보는 것이 좋다. 미리보기를 사용하면 빌드 오류나 마크다운 형식 문제를 알아낼 수 있다.
|
|
|
|
|
변경 사항을 푸시하거나 풀 리퀘스트를 열기 전에 변경 사항을 로컬에서 미리 보는 것이 좋다.
|
|
|
|
|
미리보기를 사용하면 빌드 오류나 마크다운 형식 문제를 알아낼 수 있다.
|
|
|
|
|
|
|
|
|
|
website의 컨테이너 이미지를 만들거나 Hugo를 로컬에서 실행할 수 있다. 도커 이미지 빌드는 느리지만 [Hugo 단축코드](/docs/contribute/style/hugo-shortcodes/)를 표시하므로, 디버깅에 유용할 수 있다.
|
|
|
|
|
website의 컨테이너 이미지를 만들거나 Hugo를 로컬에서 실행할 수 있다.
|
|
|
|
|
도커 이미지 빌드는 느리지만 [Hugo 단축코드](/docs/contribute/style/hugo-shortcodes/)를 표시하므로,
|
|
|
|
|
디버깅에 유용할 수 있다.
|
|
|
|
|
|
|
|
|
|
{{< tabs name="tab_with_hugo" >}}
|
|
|
|
|
{{% tab name="Hugo 컨테이너" %}}
|
|
|
|
|
|
|
|
|
|
{{< note >}}
|
|
|
|
|
아래 명령은 도커를 기본 컨테이너 엔진으로 사용한다. 이 동작을 무시하려면 `CONTAINER_ENGINE` 환경 변수를 설정한다.
|
|
|
|
|
아래 명령은 도커를 기본 컨테이너 엔진으로 사용한다.
|
|
|
|
|
이 동작을 무시하려면 `CONTAINER_ENGINE` 환경 변수를 설정한다.
|
|
|
|
|
{{< /note >}}
|
|
|
|
|
|
|
|
|
|
1. 로컬에서 이미지를 빌드한다.
|
|
|
|
|
_Hugo 도구 자체에 대한 변경을 테스트하는 경우에만 이 단계가 필요하다._
|
|
|
|
|
|
|
|
|
|
```bash
|
|
|
|
|
# docker 사용(기본값)
|
|
|
|
|
make container-image
|
|
|
|
|
|
|
|
|
|
### 또는 ###
|
|
|
|
|
|
|
|
|
|
# podman 사용
|
|
|
|
|
CONTAINER_ENGINE=podman make container-image
|
|
|
|
|
```shell
|
|
|
|
|
# 터미널에서 명령 실행 (필요에 따라)
|
|
|
|
|
make container-serve
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
2. 로컬에서 `kubernetes-hugo` 이미지를 빌드한 후, 사이트를 빌드하고 서비스한다.
|
|
|
|
|
2. 컨테이너에서 Hugo를 시작한다.
|
|
|
|
|
|
|
|
|
|
```bash
|
|
|
|
|
# docker 사용(기본값)
|
|
|
|
|
```shell
|
|
|
|
|
# 터미널에서 실행
|
|
|
|
|
make container-serve
|
|
|
|
|
|
|
|
|
|
### 또는 ###
|
|
|
|
|
|
|
|
|
|
# podman 사용
|
|
|
|
|
CONTAINER_ENGINE=podman make container-serve
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
3. 웹 브라우저에서 `https://localhost:1313` 로 이동한다. Hugo는
|
|
|
|
|
@ -326,18 +332,19 @@ website의 컨테이너 이미지를 만들거나 Hugo를 로컬에서 실행할
|
|
|
|
|
|
|
|
|
|
또는, 컴퓨터에 `hugo` 명령을 설치하여 사용한다.
|
|
|
|
|
|
|
|
|
|
1. [`website/netlify.toml`](https://raw.githubusercontent.com/kubernetes/website/main/netlify.toml)에 지정된 [Hugo](https://gohugo.io/getting-started/installing/) 버전을 설치한다.
|
|
|
|
|
1. [`website/netlify.toml`](https://raw.githubusercontent.com/kubernetes/website/main/netlify.toml)에 지정된
|
|
|
|
|
[Hugo](https://gohugo.io/getting-started/installing/) 버전을 설치한다.
|
|
|
|
|
|
|
|
|
|
2. website 리포지터리를 업데이트하지 않았다면, `website/themes/docsy` 디렉터리가 비어 있다.
|
|
|
|
|
테마의 로컬 복제본이 없으면 사이트를 빌드할 수 없다. website 테마를 업데이트하려면, 다음을 실행한다.
|
|
|
|
|
테마의 로컬 복제본이 없으면 사이트를 빌드할 수 없다. website 테마를 업데이트하려면, 다음을 실행한다.
|
|
|
|
|
|
|
|
|
|
```bash
|
|
|
|
|
```shell
|
|
|
|
|
git submodule update --init --recursive --depth 1
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
3. 터미널에서, 쿠버네티스 website 리포지터리로 이동하여 Hugo 서버를 시작한다.
|
|
|
|
|
|
|
|
|
|
```bash
|
|
|
|
|
```shell
|
|
|
|
|
cd <path_to_your_repo>/website
|
|
|
|
|
hugo server --buildFuture
|
|
|
|
|
```
|
|
|
|
|
@ -354,6 +361,7 @@ website의 컨테이너 이미지를 만들거나 Hugo를 로컬에서 실행할
|
|
|
|
|
### 포크에서 kubernetes/website로 풀 리퀘스트 열기 {#open-a-pr}
|
|
|
|
|
|
|
|
|
|
아래 그림은 당신의 포크에서 K8s/website 저장소로 PR을 여는 단계를 보여 준다. 상세 사항은 아래에 등장한다.
|
|
|
|
|
|
|
|
|
|
<!-- See https://github.com/kubernetes/website/issues/28808 for live-editor URL to this figure -->
|
|
|
|
|
<!-- You can also cut/paste the mermaid code into the live editor at https://mermaid-js.github.io/mermaid-live-editor to play around with it -->
|
|
|
|
|
|
|
|
|
|
@ -379,7 +387,8 @@ classDef white fill:#ffffff,stroke:#000,stroke-width:px,color:#000,font-weight:b
|
|
|
|
|
class 1,2,3,4,5,6,7,8 grey
|
|
|
|
|
class first,second white
|
|
|
|
|
{{</ mermaid >}}
|
|
|
|
|
***그림 - 당신의 포크에서 K8s/website 저장소로 PR을 여는 단계***
|
|
|
|
|
|
|
|
|
|
그림 - 당신의 포크에서 K8s/website 저장소로 PR을 여는 단계
|
|
|
|
|
|
|
|
|
|
1. 웹 브라우저에서 [`kubernetes/website`](https://github.com/kubernetes/website/) 리포지터리로 이동한다.
|
|
|
|
|
2. **New Pull Request** 를 선택한다.
|
|
|
|
|
@ -387,29 +396,36 @@ class first,second white
|
|
|
|
|
4. **head repository** 드롭다운 메뉴에서, 포크를 선택한다.
|
|
|
|
|
5. **compare** 드롭다운 메뉴에서, 브랜치를 선택한다.
|
|
|
|
|
6. **Create Pull Request** 를 선택한다.
|
|
|
|
|
7. 풀 리퀘스트에 대한 설명을 추가한다.
|
|
|
|
|
`. 풀 리퀘스트에 대한 설명을 추가한다.
|
|
|
|
|
|
|
|
|
|
- **Title**(50자 이하): 변경 사항에 대한 의도를 요약한다.
|
|
|
|
|
- **Description**: 변경 사항을 자세히 설명한다.
|
|
|
|
|
- 관련된 GitHub 이슈가 있는 경우, `Fixes #12345` 또는 `Closes #12345` 를 설명에 포함한다. 이렇게 하면 GitHub의 자동화 기능이 PR을 병합한 후 언급된 이슈를 닫는다. 다른 관련된 PR이 있는 경우, 이들 PR도 연결한다.
|
|
|
|
|
- 구체적인 내용에 대한 조언이 필요한 경우, 원하는 질문을 리뷰어가 생각해볼 수 있도록 설명에 포함한다.
|
|
|
|
|
|
|
|
|
|
8. **Create pull request** 버튼을 선택한다.
|
|
|
|
|
- 관련된 GitHub 이슈가 있는 경우, `Fixes #12345` 또는 `Closes #12345` 를 설명에 포함한다.
|
|
|
|
|
이렇게 하면 GitHub의 자동화 기능이 PR을 병합한 후 언급된 이슈를 닫는다.
|
|
|
|
|
다른 관련된 PR이 있는 경우, 이들 PR도 연결한다.
|
|
|
|
|
- 구체적인 내용에 대한 조언이 필요한 경우,
|
|
|
|
|
원하는 질문을 리뷰어가 생각해볼 수 있도록 설명에 포함한다.
|
|
|
|
|
|
|
|
|
|
7. **Create pull request** 버튼을 선택한다.
|
|
|
|
|
|
|
|
|
|
축하한다! 여러분의 풀 리퀘스트가 [풀 리퀘스트](https://github.com/kubernetes/website/pulls)에 열렸다.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
PR을 연 후, GitHub는 자동 테스트를 실행하고 [Netlify](https://www.netlify.com/)를 사용하여 미리보기를 배포하려고 시도한다.
|
|
|
|
|
PR을 연 후, GitHub는 자동 테스트를 실행하고
|
|
|
|
|
[Netlify](https://www.netlify.com/)를 사용하여 미리보기를 배포하려고 시도한다.
|
|
|
|
|
|
|
|
|
|
- Netlify 빌드가 실패하면, 자세한 정보를 위해 **Details** 를 선택한다.
|
|
|
|
|
- Netlify 빌드가 성공하면, **Details** 를 선택하면 변경 사항이 적용된 쿠버네티스 website의 커밋하기 직전의 버전(staged version)이 열린다. 리뷰어가 변경 사항을 확인하는 방법이다.
|
|
|
|
|
- Netlify 빌드가 성공하면, **Details** 를 선택하면 변경 사항이 적용된 쿠버네티스 website의 커밋하기
|
|
|
|
|
직전의 버전(staged version)이 열린다. 리뷰어가 변경 사항을 확인하는 방법이다.
|
|
|
|
|
|
|
|
|
|
또한 GitHub는 리뷰어에게 도움을 주기 위해 PR에 레이블을 자동으로 할당한다. 필요한 경우 직접 추가할 수도 있다. 자세한 내용은 [이슈 레이블 추가와 제거](/ko/docs/contribute/review/for-approvers/#이슈-레이블-추가와-제거)를 참고한다.
|
|
|
|
|
또한 GitHub는 리뷰어에게 도움을 주기 위해 PR에 레이블을 자동으로 할당한다. 필요한 경우 직접 추가할 수도 있다.
|
|
|
|
|
자세한 내용은 [이슈 레이블 추가와 제거](/ko/docs/contribute/review/for-approvers/#이슈-레이블-추가와-제거)를 참고한다.
|
|
|
|
|
|
|
|
|
|
### 로컬에서 피드백 해결
|
|
|
|
|
|
|
|
|
|
1. 변경한 후, 이전 커밋을 수정한다.
|
|
|
|
|
|
|
|
|
|
```bash
|
|
|
|
|
```shell
|
|
|
|
|
git commit -a --amend
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
@ -421,7 +437,8 @@ PR을 연 후, GitHub는 자동 테스트를 실행하고 [Netlify](https://www.
|
|
|
|
|
3. `git push origin <my_new_branch>` 를 사용해서 변경 사항을 푸시하고 Netlify 테스트를 다시 실행한다.
|
|
|
|
|
|
|
|
|
|
{{< note >}}
|
|
|
|
|
수정하는 대신 `git commit -m` 을 사용하는 경우, 병합하기 전에 [커밋을 스쿼시](#커밋-스쿼시하기)해야 한다.
|
|
|
|
|
수정하는 대신 `git commit -m` 을 사용하는 경우,
|
|
|
|
|
병합하기 전에 [커밋을 스쿼시](#커밋-스쿼시하기)해야 한다.
|
|
|
|
|
{{< /note >}}
|
|
|
|
|
|
|
|
|
|
#### 리뷰어의 변경
|
|
|
|
|
@ -430,35 +447,38 @@ PR을 연 후, GitHub는 자동 테스트를 실행하고 [Netlify](https://www.
|
|
|
|
|
|
|
|
|
|
1. 원격 포크에서 커밋을 가져오고 작업 브랜치를 리베이스한다.
|
|
|
|
|
|
|
|
|
|
```bash
|
|
|
|
|
```shell
|
|
|
|
|
git fetch origin
|
|
|
|
|
git rebase origin/<your-branch-name>
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
2. 리베이스한 후, 포크에 새로운 변경 사항을 강제로 푸시한다.
|
|
|
|
|
|
|
|
|
|
```bash
|
|
|
|
|
```shell
|
|
|
|
|
git push --force-with-lease origin <your-branch-name>
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
#### 충돌 병합 및 리베이스
|
|
|
|
|
|
|
|
|
|
{{< note >}}
|
|
|
|
|
자세한 내용은 [Git 브랜치 - 기본 브랜치와 병합](https://git-scm.com/book/en/v2/Git-Branching-Basic-Branching-and-Merging#_basic_merge_conflicts), [고급 병합](https://git-scm.com/book/en/v2/Git-Tools-Advanced-Merging)을 참조하거나, 슬랙 채널 `#sig-docs` 에서 도움을 요청한다.
|
|
|
|
|
자세한 내용은 [Git 브랜치 - 기본 브랜치와 병합](https://git-scm.com/book/en/v2/Git-Branching-Basic-Branching-and-Merging#_basic_merge_conflicts),
|
|
|
|
|
[고급 병합](https://git-scm.com/book/en/v2/Git-Tools-Advanced-Merging)을 참조하거나,
|
|
|
|
|
슬랙 채널 `#sig-docs` 에서 도움을 요청한다.
|
|
|
|
|
{{< /note >}}
|
|
|
|
|
|
|
|
|
|
다른 기여자가 다른 PR에서 동일한 파일에 대한 변경 사항을 커밋하면, 병합 충돌이 발생할 수 있다. PR의 모든 병합 충돌을 해결해야 한다.
|
|
|
|
|
다른 기여자가 다른 PR에서 동일한 파일에 대한 변경 사항을 커밋하면, 병합 충돌이 발생할 수 있다.
|
|
|
|
|
PR의 모든 병합 충돌을 해결해야 한다.
|
|
|
|
|
|
|
|
|
|
1. 포크를 업데이트하고 로컬 브랜치를 리베이스한다.
|
|
|
|
|
|
|
|
|
|
```bash
|
|
|
|
|
```shell
|
|
|
|
|
git fetch origin
|
|
|
|
|
git rebase origin/<your-branch-name>
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
그런 다음 포크에 변경 사항을 강제로 푸시한다.
|
|
|
|
|
|
|
|
|
|
```bash
|
|
|
|
|
```shell
|
|
|
|
|
git push --force-with-lease origin <your-branch-name>
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
@ -477,7 +497,8 @@ PR을 연 후, GitHub는 자동 테스트를 실행하고 [Netlify](https://www.
|
|
|
|
|
|
|
|
|
|
이 명령의 결과에 여러 파일이 충돌된 것으로 표시된다.
|
|
|
|
|
|
|
|
|
|
4. 충돌하는 각 파일을 열고 충돌 마커(`>>>`,`<<<` 그리고 `===`)를 찾는다. 충돌을 해결하고 충돌 마커를 삭제한다.
|
|
|
|
|
4. 충돌한 각 파일을 열고 충돌 마커(`>>>`,`<<<` 그리고 `===`)를 찾는다.
|
|
|
|
|
충돌을 해결하고 충돌 마커를 삭제한다.
|
|
|
|
|
|
|
|
|
|
{{< note >}}
|
|
|
|
|
자세한 내용은 [충돌이 표시되는 방법](https://git-scm.com/docs/git-merge#_how_conflicts_are_presented)을 참고한다.
|
|
|
|
|
@ -485,12 +506,13 @@ PR을 연 후, GitHub는 자동 테스트를 실행하고 [Netlify](https://www.
|
|
|
|
|
|
|
|
|
|
5. 변경 세트에 파일을 추가한다.
|
|
|
|
|
|
|
|
|
|
```bash
|
|
|
|
|
```shell
|
|
|
|
|
git add <filename>
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
6. 리베이스를 계속한다.
|
|
|
|
|
|
|
|
|
|
```bash
|
|
|
|
|
```shell
|
|
|
|
|
git rebase --continue
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
@ -500,7 +522,7 @@ PR을 연 후, GitHub는 자동 테스트를 실행하고 [Netlify](https://www.
|
|
|
|
|
|
|
|
|
|
8. 브랜치를 포크에 강제로 푸시한다.
|
|
|
|
|
|
|
|
|
|
```bash
|
|
|
|
|
```shell
|
|
|
|
|
git push --force-with-lease origin <your-branch-name>
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
@ -509,10 +531,13 @@ PR을 연 후, GitHub는 자동 테스트를 실행하고 [Netlify](https://www.
|
|
|
|
|
### 커밋 스쿼시하기
|
|
|
|
|
|
|
|
|
|
{{< note >}}
|
|
|
|
|
자세한 내용은 [Git 도구 - 히스토리 다시 쓰기](https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History)를 참고하거나, 슬랙 채널 `#sig-docs` 에서 도움을 요청한다.
|
|
|
|
|
자세한 내용은 [Git 도구 - 히스토리 다시 쓰기](https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History)를 참고하거나,
|
|
|
|
|
슬랙 채널 `#sig-docs` 에서 도움을 요청한다.
|
|
|
|
|
{{< /note >}}
|
|
|
|
|
|
|
|
|
|
PR에 여러 커밋이 있는 경우, PR을 병합하기 전에 해당 커밋을 단일 커밋으로 스쿼시해야 한다. PR의 **Commits** 탭에서 또는 `git log` 명령을 로컬에서 실행하여 커밋 수를 확인할 수 있다.
|
|
|
|
|
PR에 여러 커밋이 있는 경우, PR을 병합하기 전에 해당 커밋을 단일 커밋으로 스쿼시해야 한다.
|
|
|
|
|
PR의 **Commits** 탭에서 또는 `git log` 명령을 로컬에서 실행하여
|
|
|
|
|
커밋 수를 확인할 수 있다.
|
|
|
|
|
|
|
|
|
|
{{< note >}}
|
|
|
|
|
여기서는 `vim` 을 커맨드 라인 텍스트 편집기로 사용하는 것을 가정한다.
|
|
|
|
|
@ -520,15 +545,16 @@ PR에 여러 커밋이 있는 경우, PR을 병합하기 전에 해당 커밋을
|
|
|
|
|
|
|
|
|
|
1. 대화식 리베이스를 시작한다.
|
|
|
|
|
|
|
|
|
|
```bash
|
|
|
|
|
```shell
|
|
|
|
|
git rebase -i HEAD~<number_of_commits_in_branch>
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
커밋을 스쿼시하는 것은 일종의 리베이스이다. git의 `-i` 스위치는 리베이스를 대화형으로 할 수 있게 한다. `HEAD~<number_of_commits_in_branch>` 는 리베이스를 위해 살펴볼 커밋 수를 나타낸다.
|
|
|
|
|
커밋을 스쿼시하는 것은 일종의 리베이스이다. git의 `-i` 스위치는 리베이스를 대화형으로 할 수 있게 한다.
|
|
|
|
|
`HEAD~<number_of_commits_in_branch>` 는 리베이스를 위해 살펴볼 커밋 수를 나타낸다.
|
|
|
|
|
|
|
|
|
|
출력은 다음과 비슷하다.
|
|
|
|
|
|
|
|
|
|
```bash
|
|
|
|
|
```none
|
|
|
|
|
pick d875112ca Original commit
|
|
|
|
|
pick 4fa167b80 Address feedback 1
|
|
|
|
|
pick 7d54e15ee Address feedback 2
|
|
|
|
|
@ -540,7 +566,9 @@ PR에 여러 커밋이 있는 경우, PR을 병합하기 전에 해당 커밋을
|
|
|
|
|
# 이 행들은 순서를 바꿀 수 있다. 이들은 위에서 아래로 실행된다.
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
출력의 첫 번째 섹션에는 리베이스의 커밋이 나열된다. 두 번째 섹션에는 각 커밋에 대한 옵션이 나열되어 있다. `pick` 단어를 바꾸면 리베이스가 완료되었을 때 커밋 상태가 변경된다.
|
|
|
|
|
출력의 첫 번째 섹션에는 리베이스의 커밋이 나열된다.
|
|
|
|
|
두 번째 섹션에는 각 커밋에 대한 옵션이 나열되어 있다.
|
|
|
|
|
`pick` 단어를 바꾸면 리베이스가 완료되었을 때 커밋 상태가 변경된다.
|
|
|
|
|
|
|
|
|
|
리베이스를 하는 목적인 `squash` 와 `pick` 에 집중한다.
|
|
|
|
|
|
|
|
|
|
@ -552,7 +580,7 @@ PR에 여러 커밋이 있는 경우, PR을 병합하기 전에 해당 커밋을
|
|
|
|
|
|
|
|
|
|
다음의 원본 텍스트를 변경한다.
|
|
|
|
|
|
|
|
|
|
```bash
|
|
|
|
|
```none
|
|
|
|
|
pick d875112ca Original commit
|
|
|
|
|
pick 4fa167b80 Address feedback 1
|
|
|
|
|
pick 7d54e15ee Address feedback 2
|
|
|
|
|
@ -560,13 +588,14 @@ PR에 여러 커밋이 있는 경우, PR을 병합하기 전에 해당 커밋을
|
|
|
|
|
|
|
|
|
|
아래와 같이 변경한다.
|
|
|
|
|
|
|
|
|
|
```bash
|
|
|
|
|
```none
|
|
|
|
|
pick d875112ca Original commit
|
|
|
|
|
squash 4fa167b80 Address feedback 1
|
|
|
|
|
squash 7d54e15ee Address feedback 2
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
이것은 커밋 `4fa167b80 Address feedback 1` 과 `7d54e15ee Address feedback 2` 를 `d875112ca Original commit` 으로 스쿼시한다. 타임라인의 일부로 `d875112ca Original commit` 만 남긴다.
|
|
|
|
|
이것은 커밋 `4fa167b80 Address feedback 1` 과 `7d54e15ee Address feedback 2` 를 `d875112ca Original commit` 으로 스쿼시한다.
|
|
|
|
|
타임라인의 일부로 `d875112ca Original commit` 만 남긴다.
|
|
|
|
|
|
|
|
|
|
3. 파일을 저장하고 종료한다.
|
|
|
|
|
|
|
|
|
|
@ -578,14 +607,15 @@ PR에 여러 커밋이 있는 경우, PR을 병합하기 전에 해당 커밋을
|
|
|
|
|
|
|
|
|
|
## 다른 리포지터리에 기여하기
|
|
|
|
|
|
|
|
|
|
[쿠버네티스 프로젝트](https://github.com/kubernetes)에는 50개 이상의 리포지터리가 포함되어 있다. 이러한 리포지터리에는 사용자용 도움말 텍스트, 오류 메시지, API 레퍼런스 또는 코드 주석과 같은 문서가 포함되어 있다.
|
|
|
|
|
[쿠버네티스 프로젝트](https://github.com/kubernetes)에는 50개 이상의 리포지터리가 포함되어 있다.
|
|
|
|
|
이러한 리포지터리에는 사용자용 도움말 텍스트, 오류 메시지, API 레퍼런스
|
|
|
|
|
또는 코드 주석과 같은 문서가 포함되어 있다.
|
|
|
|
|
|
|
|
|
|
개선하려는 텍스트가 보이면, GitHub을 사용하여 쿠버네티스 조직의 모든 리포지터리를 검색한다.
|
|
|
|
|
이를 통해 어디에 이슈나 PR을 제출할지를 파악할 수 있다.
|
|
|
|
|
|
|
|
|
|
각 리포지터리에는 고유한 프로세스와 절차가 있다. 여러분이 이슈를
|
|
|
|
|
제기하거나 PR을 제출하기 전에, 그 리포지터리의 `README.md`, `CONTRIBUTING.md` 그리고
|
|
|
|
|
`code-of-conduct.md`(만약 이들 문서가 있다면)를 읽어본다.
|
|
|
|
|
각 리포지터리에는 고유한 프로세스와 절차가 있다. 여러분이 이슈를 제기하거나 PR을 제출하기 전에,
|
|
|
|
|
그 리포지터리의 `README.md`, `CONTRIBUTING.md` 그리고 `code-of-conduct.md`(만약 이들 문서가 있다면)를 읽어본다.
|
|
|
|
|
|
|
|
|
|
대부분의 리포지터리에는 이슈와 PR 템플릿이 사용된다. 팀의 프로세스에 대한
|
|
|
|
|
느낌을 얻으려면 열린 이슈와 PR을 살펴보자. 이슈나 PR을 제출할 때
|
|
|
|
|
|
Yoon Seo-Yul