GitHub Codespaces 는 컨테이너를 사용하여 개발을 위한 공용 언어, 도구 및 유틸리티를 제공하는 즉각적인 클라우드 기반 개발 환경입니다. GitHub Codespaces 은 구성 가능하므로 프로젝트에 대한 사용자 지정된 개발 환경을 만들 수 있습니다. 프로젝트에 대한 사용자 지정 개발 환경을 구성하면 프로젝트의 모든 사용자에 대해 반복 가능한 codespace 구성을 사용할 수 있습니다.
Codespace 만들기
codespace를 만드는 진입점은 여러 가지가 있습니다.
- GitHub 템플릿 또는 템플릿 리포지토리에서 GitHub 새 프로젝트 시작
- 새로운 기능을 개발하기 위해 리포지토리에서 분기를 생성하여 작업을 시작합니다.
- 진행 중인 작업을 탐색하기 위한 열린 끌어오기 요청에서 시작합니다.
- 특정 시점의 버그를 조사하기 위한 리포지토리 기록의 커밋에서 시작합니다.
GitHub의 Visual Studio Code에서 생성하거나 GitHub CLI을(를) 사용하여 codespace를 생성할 수 있습니다.
코드를 테스트해야 하거나 장기 실행 기능 작업을 수행하기 위해 동일한 codespace로 돌아갈 수 있는 경우 codespace의 유효 기간이 짧을 수 있습니다.
자세한 내용은 리포지토리에 대한 codespace 만들기, 템플릿에서 codespace 만들기, 기존 Codespace 열기을(를) 참조하세요.
참고
리포지토리 또는 분기당 둘 이상의 codespace를 만들 수 있습니다. 그러나 만들 수 있는 codespace 수와 동시에 실행할 수 있는 codespace의 수에는 제한이 있습니다. codespace 최대 수에 도달하고 다른 codespace를 만들려고 하면 기존 codespace를 제거해야 새 codespace를 만들 수 있다는 메시지가 표시됩니다.
Codespace 생성 프로세스
codespace를 만들 때 codespace를 사용할 수 있게 되기 전에 백그라운드에서 다양한 단계가 수행됩니다.
1단계: VM 및 스토리지가 codespace에 할당
코드스페이스를 만들면 VM 호스트 이미지의 안정 또는 공개 미리 보기 릴리스를 사용하여 VM(가상 머신)이 만들어집니다. 자세한 내용은 안정적인 호스트 또는 베타 호스트 이미지 선택을(를) 참조하세요. 호스트 이미지는 VM에 사용되는 Linux 버전을 정의합니다. VM은 전용이며 비공개입니다. 전용 VM이 있으면 해당 컴퓨터의 전체 컴퓨팅 리소스 집합을 사용할 수 있습니다. 필요하다면 이를 통해 컨테이너에 대한 전체 루트 액세스 권한을 사용할 수도 있습니다.
그런 다음 리포지토리 또는 템플릿에서 codespace를 만드는 경우 템플릿 리포지토리의 단순 복제본이 생성됩니다. 이는 VM의 /workspaces 디렉터리에 복제된 후 개발 컨테이너에 탑재됩니다. 자세한 내용은 아래의 codespace의 디렉터리 구조 정보를 참조하세요.
2단계: 개발 컨테이너가 만들어짐
GitHub Codespaces 는 Docker 컨테이너를 개발 환경으로 사용합니다. 이 컨테이너는 리포지토리의 devcontainer.json 파일 및 필요한 경우 Dockerfile에서 정의할 수 있는 구성을 기반으로 만들어집니다. 빈 템플릿 또는 파일이 GitHub 없는 devcontainer.json 리포지토리에서 GitHub Codespaces코드스페이스를 만드는 경우 사용할 수 있는 언어와 런타임이 많은 기본 이미지를 사용합니다. 자세한 내용은 개발 컨테이너 소개을(를) 참조하세요. 개발 컨테이너의 기본 이미지에 포함된 내용에 대한 자세한 내용은 devcontainers/images 리포지토리를 참조하세요.
참고
codespace에서 Git 후크를 사용하고 git 템플릿 디렉터리의 모든 내용을 codespace에 적용하려면 컨테이너를 만든 후 4단계에서 후크를 설정해야 합니다.
컨테이너를 만들기 전에 리포지토리가 호스트 VM에 복제되므로 4단계에서 를 사용하여 devcontainer.json 구성 파일에 후크를 설정하지 않는 한 postCreateCommand의 모든 내용은 codespace에 적용되지 않습니다. 자세한 내용은 4단계: 만들기 후 설정을 참조하세요.
3단계: codespace에 연결
컨테이너가 만들어지고 다른 초기화가 실행되면 codespace에 연결됩니다. 다음을 사용하여 연결할 수 있습니다.
- 당신의 웹 브라우저
- Visual Studio Code
- GitHub CLI
4단계: 만들기 후 설정
codespace에 연결되면 devcontainer.json 파일에 지정한 구성을 기반으로 자동화된 설정이 계속 빌드될 수 있습니다.
postCreateCommand와 postAttachCommand가 실행되는 것을 볼 수도 있습니다.
codespace에서 Git 후크를 사용하려면 devcontainer.json와 같은 postCreateCommand 수명 주기 스크립트를 사용하여 후크를 설정합니다. 개발 컨테이너 수명 주기 스크립트에 대한 자세한 내용은 개발 컨테이너 웹사이트의 개발 컨테이너 사양을 참조하세요.
공용 dotfiles 리포지토리 GitHub Codespaces가 있는 경우 새 코드스페이스에서 사용하도록 설정할 수 있습니다. 사용하도록 설정하면 dot 파일이 컨테이너에 복제되고 설치 스크립트가 호출됩니다. 자세한 내용은 계정에 대한 GitHub Codespace 개인 설정을(를) 참조하세요.
마지막으로, 리포지토리에서 codespace를 생성하면 리포지토리의 전체 기록은 전체 복제본으로 복사됩니다. 템플릿에서 codespace를 만든 경우 템플릿 리포지토리의 전체 기록은 유지되지 않습니다. 대신 빈 템플릿을 사용하지 않는 한 템플릿 리포지토리의 내용에 대한 초기 커밋으로 시작합니다.
만들기 후 설정하는 동안에도 통합 터미널을 사용하고 파일을 편집할 수 있지만 작업과 실행 중인 명령 간의 경합 상태를 피하기 위해 주의해야 합니다.
Codespaces 수명 주기
codespace에 파일 저장
사용 중인 편집기에 따라 변경 내용을 일반적인 방식으로 저장합니다.
코드스페이스에서 작업하는 경우 자동 저장을 Visual Studio Code사용하도록 설정하여 변경 내용이 항상 저장되도록 할 수 있습니다.
코드스페이스 닫기 또는 중지하기
코드스페이스는 사용 중인 동안 최대 12시간까지 계속 실행되지만, 일정 시간 동안 활동이 없으면 시간 초과로 종료됩니다. 편집기와 터미널 출력의 파일 변경 사항이 작업으로 인식되기 때문에, 터미널이 계속 실행 중인 동안에는 codespace의 시간 제한이 초과되지 않습니다. 기본 비활성 시간 제한 기간은 30분입니다. 자신이 생성한 codespace에 대한 개인 시간 제한 설정을 정의할 수 있지만, 이 설정은 조직 시간 제한 정책에 의해 무효가 될 수 있습니다. 자세한 내용은 GitHub Codespaces에 대한 시간 제한 기간 설정을(를) 참조하세요. 최대 수명에 대한 자세한 내용은 codespace 수명 주기 이해을 참조하세요.
코드스페이스가 시간 초과되면 실행이 중지되지만 브라우저 탭(브라우저에서 코드스페이스를 사용하는 경우) 내 VS Code또는 코드스페이스 목록에서 다시 시작할 수 있습니다 https://github.com/codespaces.
코드스페이스를 중지하려면 다음을 수행하십시오.
- 브라우저: https://github.com/codespaces의 codespace 목록에서 중지하려는 codespace 오른쪽의 줄임표(...)를 클릭하고 codespace 중지를 클릭합니다.
- 에서 VS Code- 예를 들어 Ctrl+Shift+P(Windows/Linux) 또는 Shift+명령+P(Mac)
Codespaces: stop를 눌러 엽니다 Visual Studio Code Command Palette . 그런 다음 Enter 키를 누릅니다. 자세한 내용은 GitHub Codespaces에서 Visual Studio Code 명령 팔레트 사용을(를) 참조하세요. - 터미널 창에서 : 명령을
gh codespace stop사용합니다GitHub CLI. 자세한 내용은 GitHub CLI에서 GitHub Codespace 사용을(를) 참조하세요.
중지 명령을 실행하지 않고(브라우저 탭을 닫는 등의 방법을 통해) codespace를 종료하거나 상호 작용 없이 codespace를 계속 실행하면, codespace와 codespace에서 실행 중인 프로세스는 비활성 시간 제한 기간에 계속 유지됩니다.
codespace를 닫거나 중지하면 codespace에 다시 연결할 때까지 커밋되지 않은 모든 변경 내용이 유지됩니다.
애플리케이션 실행
포트 전달은 codespace 내에서 실행 중인 TCP 포트에 대한 액세스 권한을 제공합니다. 예를 들어 codespace 내의 포트 4000에서 웹 애플리케이션을 실행하는 경우 해당 포트를 자동으로 전달하여 브라우저에서 애플리케이션에 액세스할 수 있도록 할 수 있습니다.
포트 전달은 원격 컴퓨터에서 액세스할 수 있는 포트를 결정합니다. 포트를 전달하지 않더라도 해당 포트는 codespace 자체 내에서 실행 중인 다른 프로세스에서 계속 액세스할 수 있습니다.
내부에서 GitHub Codespaces 실행되는 애플리케이션이 포트를 콘솔 GitHub Codespaces 에 출력하는 경우 localhost URL 패턴을 검색하고 포트를 자동으로 전달합니다. 터미널의 URL 또는 오른쪽 아래 모서리에 표시되는 "알림 메시지" 알림 메시지의 VS Code링크를 클릭하여 브라우저에서 포트를 열 수 있습니다. 기본적으로 GitHub Codespaces HTTP를 사용하여 포트를 전달합니다. 포트 전달에 대한 자세한 내용은 코드스페이스에서 포트 전달을(를) 참조하세요.
포트는 자동으로 전달될 수 있지만 인터넷에 공개적으로 액세스할 수는 없습니다. 기본적으로 모든 포트는 공개되지 않지만 수동으로 조직에서 사용하도록 하거나 공개한 다음 URL을 통해 액세스를 공유할 수 있습니다. 자세한 내용은 코드스페이스에서 포트 전달을(를) 참조하세요.
codespace를 처음 사용할 때 애플리케이션을 실행하면 빠른 내부 개발 루프를 만들 수 있습니다. 편집할 때 변경 내용이 자동으로 저장되고 이를 전달된 포트에서 사용할 수 있습니다. 변경 내용을 보려면 브라우저에서 실행 중인 애플리케이션 탭으로 돌아가서 새로 고칩니다.
변경 내용 커밋 및 푸시
Git은 기본적으로 codespace에 설치되므로 기존 Git 워크플로를 사용할 수 있습니다. 터미널을 통해 또는 의 소스 제어 기능을 VS Code사용하여 코드스페이스에서 Git로 작업할 수 있습니다.
기존의 리포지토리에서 작업하고 있다면, 리포지토리의 모든 분기, 커밋 또는 끌어오기 요청에서 codespace를 만들거나 활성 codespace 내에서 새 분기 또는 기존 분기로 전환할 수 있습니다. 임시로 설계되었으므로 GitHub Codespaces 격리된 환경으로 사용하여 실험하거나, 팀 동료의 끌어오기 요청을 확인하거나, 병합 충돌을 수정할 수 있습니다.
리포지토리에 대한 읽기 권한만 있는 경우 포크할 수 있는 한 리포지토리에 대한 코드스페이스를 만들 수 있습니다. 코드스페이스에서 커밋하거나 새 분기를 푸시하면 GitHub Codespaces 가 자동으로 사용자를 위해 리포지토리의 포크를 만들거나, 업스트림 리포지토리에 대한 기존 포크가 이미 있는 경우 코드스페이스를 해당 포크에 연결합니다.
템플릿에서 만든 codespace에서 작업하는 경우 Git은 기본적으로 설치되지만 작업을 지속하고 다른 사용자와 공유하려면 codespace를 원격 리포지토리에 게시해야 합니다. 빈 템플릿에서 GitHub시작하는 경우 먼저 작업 영역을 Git 리포지토리(예: 입력 git init)로 초기화하여 코드스페이스 내에서 소스 제어 사용을 시작해야 합니다.
자세한 내용은 codespace에서 원본 제어 사용을(를) 참조하세요.
참고
codespace에서의 커밋은 https://github.com/settings/profile에 구성된 이름과 공개 이메일 계정으로 기록됩니다. 리포지토리로 범위가 지정된 토큰으로, 환경에 GITHUB_TOKEN 포함되며 GitHub 자격 증명을 사용하여 인증합니다.
확장을 사용하여 codespace 개인 설정
코드스페이스 내에 확장을 추가하여 환경을 개인 설정할 수 있습니다 VS Code.
VS Code 확장 프로그램
데스크톱 애플리케이션 또는 웹 클라이언트의 VS Code 코드스페이스에서 작업하는 경우 필요한 Visual Studio Code Marketplace확장을 추가할 수 있습니다. 확장이 실행되는 GitHub Codespaces방법에 대한 자세한 내용은 원격 개발 지원 및 GitHub CodespacesVS Code 설명서를 참조하세요.
이미 사용 VS Code중인 경우 설정 동기화 를 사용하여 로컬 인스턴스와 만든 모든 코드스페이스 간에 확장, 설정, 테마 및 바로 가기 키를 자동으로 동기화할 수 있습니다.
codespace의 디렉터리 구조 정보
codespace를 만들면 리포지토리가 codespace의 /workspaces 디렉터리에 복제됩니다. 이 디렉토리는 컨테이너에 탑재되는 영구 디렉터리입니다. 파일 편집, 추가 또는 삭제를 포함하여 이 디렉터리 내에서 변경한 내용은 codespace를 중지하고 시작할 때와 codespace에서 컨테이너를 다시 빌드할 때 유지됩니다.
/workspaces 디렉터리 외부의 codespace에는 codespace를 빌드하는 데 사용되는 개발 컨테이너 이미지에 따라 달라지는 Linux 디렉터리 구조가 포함됩니다. /workspaces 디렉토리 외부의 파일을 추가하거나 변경할 수 있습니다. 예를 들어 새 프로그램을 설치하거나 파일(예: ~/.bashrc)에서 셸 구성을 설정할 수 있습니다. 루트가 아닌 사용자는 특정 디렉터리에 대한 쓰기 액세스 권한을 자동으로 부여하지 않을 수 있지만 대부분의 이미지는 sudo 명령을 사용하여 이러한 디렉터리에 대한 루트 액세스를 허용합니다.
/tmp 디렉터리를 제외하고 /workspaces 외부에서는 codespace의 디렉터리가 컨테이너의 수명 주기에 연결됩니다. 즉, 코드 영역을 중지하고 시작할 때 변경 내용이 유지되지만 컨테이너를 다시 빌드할 때는 유지되지 않습니다. 디렉터리에 대한 /tmp 자세한 내용은 환경 변수 및 임시 파일 유지을 참조하세요.
/workspaces 외부의 디렉터리를 지우면 새로 만든 codespace에 있는 것과 동일한 상태로 다시 빌드된 컨테이너를 확인할 수 있습니다. 작업 중인 codespace에 구성 변경 내용을 적용하기 위해 컨테이너를 다시 빌드하는 경우, 사용자가 수행한 구성 변경 내용이 동일한 구성으로 새 codespace를 만드는 사용자에게도 동일하게 작동할 것이라고 확신할 수 있습니다. 자세한 내용은 개발 컨테이너 소개을(를) 참조하세요.
재빌드 및 여러 codespace에 걸쳐 보다 강력하게 codespace를 변경하려는 경우 몇 가지 옵션이 있습니다.
- 리포지토리에서 만든 모든 codespace에 프로그램 및 도구를 설치하려면 개발 컨테이너 구성에서 사용자 지정 설치 명령을 실행하기 위해
postCreateCommand같은 수명 주기 명령 속성을 사용하거나 "기능"이라는 미리 작성된 설치 명령 중에서 선택할 수 있습니다. 자세한 내용은 개발 컨테이너 웹 사이트 및 AUTOTITLE의 개발 컨테이너 사양을 참조하세요. - 도구를 설치하거나 프로필 구성
bash과 같이 만든 모든 코드스페이스에서 설정을 사용자 지정하려면 dotfiles 리포지토리와 연결할 GitHub Codespaces 수 있습니다. dot 파일 리포지토리도 영구/workspaces디렉터리에 복제됩니다. 자세한 내용은 계정에 대한 GitHub Codespace 개인 설정을(를) 참조하세요. - 재빌드를 통해 특정 파일을 유지하려는 경우,
devcontainer.json파일을 사용하여 파일과/workspaces내의 영구 디렉터리 간에 symlink를 만들 수 있습니다. 자세한 내용은 Codespace에서 컨테이너 다시 빌드을(를) 참조하세요.