From ec7230bee6b6a621c9c6c3dd4f8eac5ccb83b335 Mon Sep 17 00:00:00 2001 From: hwahyeon Date: Fri, 9 Feb 2024 15:20:40 +0900 Subject: [PATCH] Fix typos, literal translations and grammatical errors --- .../2-github-basics/translations/README.ko.md | 30 +++++++++---------- 1 file changed, 15 insertions(+), 15 deletions(-) diff --git a/1-getting-started-lessons/2-github-basics/translations/README.ko.md b/1-getting-started-lessons/2-github-basics/translations/README.ko.md index 2a86bd3a..0e57c3a1 100644 --- a/1-getting-started-lessons/2-github-basics/translations/README.ko.md +++ b/1-getting-started-lessons/2-github-basics/translations/README.ko.md @@ -18,7 +18,7 @@ ### 작업 필요 -시작하기 전에 Git이 설치되어 있는지 확인해야합니다. 터미널에서 작업: +시작하기 전에 Git이 설치되어 있는지 확인해야 합니다. 터미널에서 작업: `git --version` 만약 Git이 설치되어 있지 않다면, [Git 내려받습니다](https://git-scm.com/downloads). 그리고, 터미널에서 로컬 Git 프로필을 설정합니다: @@ -42,7 +42,7 @@ GitHub 계정, (Visual Studio Code와 같은) 코드 에디터가 필요하며, ## 코드 관리 -일부 코드 프로젝트에 포함된 폴더가 로컬에 있고 버전 제어 시스템인 git을 사용하여 진행 상황을 추적하려고 한다고 가정해보겠습니다. 어떤 사람들은 git을 사용하여 미래의 자신에게 연애 편지를 쓰는 것과 비교합니다. 며칠, 몇 주 또는 몇 달 후에 커밋 메시지를 읽으면 그 때 결정을 한 이유를 기억하거나 변경점을 "롤백"할 수 있습니다. 즉, 좋은 "커밋 메시지"를 작성할 때입니다. +일부 코드 프로젝트에 포함된 폴더가 로컬에 있고 버전 제어 시스템인 git을 사용하여 진행 상황을 추적하려고 한다고 가정해보겠습니다. 어떤 사람들은 git을 사용하여 미래의 자신에게 연애편지를 쓰는 것과 비교합니다. "커밋 메시지"를 잘 작성한다면, 며칠, 몇 주 또는 몇 달 후에 커밋 메시지를 읽게 됐을 때, 왜 그런 결정을 내렸었는지 떠올릴 수 있거나 변경 사항을 "롤백(되돌리기)"할 수 있습니다. ### 작업: 저장소 만들고 코드 커밋하기 @@ -80,7 +80,7 @@ GitHub 계정, (Visual Studio Code와 같은) 코드 에디터가 필요하며, modified: file2.txt ``` - 일반적으로 `git status` 명령은 어떤 파일이 저장소에 _저장_ 될 준비가 되었는 지 또는 유지하고 싶은 변경점이 있는 지 등을 알려줍니다. + 일반적으로 `git status` 명령은 어떤 파일이 저장소에 _저장_ 될 준비가 되었는지 또는 유지하고 싶은 변경점이 있는지 등을 알려줍니다. 1. **추적할 파일 추가하기** @@ -96,7 +96,7 @@ GitHub 계정, (Visual Studio Code와 같은) 코드 에디터가 필요하며, git commit -m "first commit" ``` - 이렇게하면 모든 파일이 커밋되고, "first commit" 메시지가 추가됩니다. 향후 커밋 메시지의 경우 변경점을 전달하기 위해 설명을 구체적으로 작성해야합니다. + 이렇게 하면 모든 파일이 커밋되고, "first commit" 메시지가 추가됩니다. 향후 커밋 메시지의 경우 변경점을 전달하기 위해 설명을 구체적으로 작성해야 합니다. 1. **GitHub와 로컬 Git 저장소 연결하기**. Git 저장소는 장치에 존재하기에 좋지만, 어느 시점에서 파일을 어딘가에 백업하고 다른 사람이 저장소에서 함께 작업하도록 초대하고 싶습니다. 그렇게 하기에 좋은 곳 중 하나는 GitHub입니다. 이미 GitHub에 저장소를 만들었으므로 로컬 Git 저장소를 GitHub에 연결할 뿐입니다. `git remote add` 명령을 수행합니다. 다음 명령을 입력합니다: @@ -116,7 +116,7 @@ GitHub 계정, (Visual Studio Code와 같은) 코드 에디터가 필요하며, "main" 브랜치는 GitHub로 커밋이 보내집니다. -1. **더 많은 변경점 추가하기**. 계속 작업하여 GitHub로 푸시하려면 다음 세 가지 명령을 사용하면됩니다: +1. **더 많은 변경점 추가하기**. 계속 작업하여 GitHub로 푸시하려면 다음 세 가지 명령을 사용하면 됩니다: ```bash git add . @@ -147,20 +147,20 @@ GitHub에 코드를 올리는 주 이유는 다른 개발자와 협력할 수 저장소에서, `Insights> Community`로 이동하여 프로젝트에 권장되는 커뮤니티 표준과 어떻게 비교되는지 확인합니다. -다음은 GitHub 저장소를 개선 할 수있는 몇 가지 사항입니다: +다음은 GitHub 저장소를 개선할 수 있는 몇 가지 사항입니다: - **설명**. 프로젝트에 설명을 추가했습니까? - **README**. README를 추가했습니까? GitHub는 [README](https://docs.github.com/articles/about-readmes/) 작성에 대한 지침을 제공합니다. - **기여 가이드**. [기여 가이드](https://docs.github.com/articles/setting-guidelines-for-repository-contributors/), - **Code of Conduct**. [Code of Conduct](https://docs.github.com/articles/adding-a-code-of-conduct-to-your-project/), - **라이선스**. 아마도, 가장 중요한 [라이선스](https://docs.github.com/articles/adding-a-license-to-a-repository/)도 가지고 있습니까? -이러한 모든 리소스는 새로운 팀원을 온보딩하는 데 도움이 됩니다. 그리고 일반적으로 새로운 기여자들이 여러분의 프로젝트가 시간을 보내기에 적합한 장소인지 확인하기 위해 코드를 보기 전 살펴 보는 것입니다. +이러한 모든 리소스는 새로운 팀원을 온보딩하는 데 도움이 됩니다. 그리고 일반적으로 새로운 기여자들이 여러분의 프로젝트가 시간을 보내기에 적합한 장소인지 확인하기 위해 코드를 보기 전 살펴보는 것입니다. ✅ README 파일은 준비하는 데 시간이 걸리지만 바쁜 관리자들은 종종 무시합니다. 특히 설명적인 예를 찾을 수 있습니까? Note: 몇 가지 [tools to help create good READMEs](https://www.makeareadme.com/)를 시도해 볼 수 있습니다. ### 작업: 코드 병합하기 -문서를 제공하면 사람들이 프로젝트에 기여하는 데 도움이 됩니다. 찾고있는 기여 유형과 프로세스 작동 방식을 설명합니다. 기여자는 GitHub의 저장소에 기여할 수 있도록 일련의 단계를 거쳐야합니다: +문서를 제공하면 사람들이 프로젝트에 기여하는 데 도움이 됩니다. 찾고 있는 기여 유형과 프로세스 작동 방식을 설명합니다. 기여자는 GitHub의 저장소에 기여할 수 있도록 일련의 단계를 거쳐야 합니다: 1. **저장소 포크하기** 아마도 사람들이 당신의 프로젝트를 _fork_ 하기를 원할 것입니다. 포크는 자신의 GitHub 프로필에 저장소 복제본을 만드는 걸 의미합니다. 1. **복제하기**. 프로젝트를 로컬 컴퓨터에 복제합니다. @@ -194,23 +194,23 @@ GitHub에 코드를 올리는 주 이유는 다른 개발자와 협력할 수 도와주고 있는 저장소의 관리자뿐만 아니라 당신을 위해서, 커밋에 좋은 이름을 부여해야 합니다. -1. **`main` 브랜치에서 작업하기**. 어느 시점에서 작업을 마치고 `main` 브랜치의 작업과 병합하려고 합니다. 그동안 `main` 브랜치가 변경되었을 수 있으므로, 먼저 다음 명령을 사용하여 최신 버전으로 업데이트해야합니다: +1. **`main` 브랜치에서 작업하기**. 어느 시점에서 작업을 마치고 `main` 브랜치의 작업과 병합하려고 합니다. 그동안 `main` 브랜치가 변경되었을 수 있으므로, 먼저 다음 명령을 사용하여 최신 버전으로 업데이트해야 합니다: ```bash git switch main git pull ``` - 이 시점에서 Git이 변경 사항을 쉽게 _결합_ 할 수 없는 _충돌_ 상황이 작업 브랜치에서 발생하는지 확인하려고합니다. 따라서 다음 명령을 실행합니다: + 이 시점에서 Git이 변경 사항을 쉽게 _결합_ 할 수 없는 _충돌_ 상황이 작업 브랜치에서 발생하는지 확인하려고 합니다. 따라서 다음 명령을 실행합니다: ```bash git switch [branch_name] git merge main ``` - 이렇게하면 `main` 에서 브랜치로 모든 변경점을 가져올 수 있으며 계속 진행할 수 있습니다. 그렇지 않은 경우에는 VS Code는 Git이 _혼란스러운_ 위치를 알려주고 영향받는 파일을 변경하여 가장 정확한 곳을 알려주면 됩니다. + 이렇게 하면 `main` 에서 브랜치로 모든 변경점을 가져올 수 있으며 계속 진행할 수 있습니다. 그렇지 않은 경우에는 VS Code는 Git이 _혼란스러운_ 위치를 알려주고 영향받는 파일을 변경하여 가장 정확한 곳을 알려주면 됩니다. -1. **GitHub로 작업 보내기**. 작업을 GitHub에 보내는 것은 두 가지를 의미합니다. 브랜치를 저장소로 푸시 한 다음 PR, Pull Request를 엽니다. +1. **GitHub로 작업 보내기**. 작업을 GitHub에 보내는 것은 두 가지를 의미합니다. 브랜치를 저장소로 푸시한 다음 PR, Pull Request를 엽니다. ```bash git push --set-upstream origin [branch-name] @@ -218,9 +218,9 @@ GitHub에 코드를 올리는 주 이유는 다른 개발자와 협력할 수 위의 명령은 포크된 저장소에 브랜치를 만듭니다. -1. **PR 열기**. 다음으로, PR을 열고 싶습니다. GitHub의 포크된 저장소로 이동하면 됩니다. GitHub에서 새 PR을 만들 것인지 묻는 표시가 표시되고 이를 클릭하면 커밋 메시지 제목을 변경할 수 있는 인터페이스로 이동하게 되며 더 적절한 설명을 작성할 수 있습니다. 이제 포크한 저장소의 관리자는 이 PR을 보고 _행운을 빌며_ 감사하고 _병합_ PR을 수행합니다. 당신은 이제 기여자입니다, yay :) +1. **PR 열기**. 다음으로, PR을 열고 싶습니다. GitHub의 포크된 저장소로 이동하면 됩니다. GitHub에서 새 PR을 만들 것인지 묻는 표시가 표시되고 이를 클릭하면 커밋 메시지 제목을 변경할 수 있는 인터페이스로 이동하게 되며 더 적절한 설명을 작성할 수 있습니다. 이제 당신이 포크한 저장소의 관리자는 이 PR를 보게 될 것입니다. 그들이 당신의 PR을 보고 당신의 PR을 좋아하고 _병합_하기를 바랍니다. 당신은 이제 기여자입니다, yay :) -1. **정라하기**. 나중에 _정리_ 하는 것은 좋은 습관으로 간주됩니다. 로컬 브랜치와 GitHub에 푸시한 브랜치를 모두 정리하려고 합니다. 먼저 다음 명령을 사용하여 로컬에서 삭제하겠습니다: +1. **정리하기**. 나중에 _정리_ 하는 것은 좋은 습관으로 간주됩니다. 로컬 브랜치와 GitHub에 푸시한 브랜치를 모두 정리하려고 합니다. 먼저 다음 명령을 사용하여 로컬에서 삭제하겠습니다: ```bash git branch -d [branch-name] @@ -264,7 +264,7 @@ GitHub의 모든 공개 저장소에 스타 표시, 워치 및/또는 "포크" 프로젝트에는 달리 명시되지 않는 한 대부분 GitHub에 "이슈" 탭의 이슈 트레커가 있습니다. 그리고 Pull Requests 탭은 사람들이 진행중인 변경 사항을 논의하고 검토하는 곳입니다. -프로젝트는 포럼, 메일링 리스트 또는 Slack, Discord 또는 IRC와 같은 채팅 채널에서 토론 할 수도 있습니다. +프로젝트는 포럼, 메일링 리스트 또는 Slack, Discord 또는 IRC와 같은 채팅 채널에서 토론할 수도 있습니다. ✅ 새로운 GitHub 리포지토리를 둘러보고 설정 편집, 저장소 정보 추가, (Kanban 보드와 같은) 프로젝트 생성을 비롯한 몇 가지 작업을 시도해보시기 바랍니다. 할 수 있는 일이 많이 있습니다!