브라우저 IDE에서 GitHub 동기화 활용하기

브라우저 프로젝트가 편리한 이유는 폴더도 런타임도 설치도 필요 없기 때문입니다. 바로 그 성질이 약점이 됩니다. 프로젝트는 브라우저 프로필에 살고, 정리 도구에 의해 지워지거나 기기와 함께 사라지거나 다른 컴퓨터로 옮길 때 남겨질 수 있습니다. ZIP으로 내보내면 사본은 생기지만, ZIP은 이력도 공유 리모트도 없는 스냅샷입니다. GitHub는 빠진 계층을 제공합니다. 기기 밖 저장소, 커밋 이력, 협업 공간, 그리고 CI나 배포의 자연스러운 소스입니다. 이로써 브라우저 IDE의 역할이 바뀝니다. 일회용 메모장이 아니라 작은 프로젝트를 작성하고 검토하고 인계하는 장소가 될 수 있습니다. 이 흐름은 Chromebook, 학교 실습실, Git 설치가 불가능한 잠긴 회사 노트북에서 특히 유용합니다. 나중에 데스크톱 저장소로 옮길 빠른 프로토타입에도 잘 맞습니다. 첫 초안은 브라우저가 맡고, GitHub가 지속성을 부여합니다.

GB Coder는 Push, New repo, Pull 세 가지 GitHub 작업을 제공합니다. Push는 현재 프로젝트를 기존 저장소와 브랜치에 씁니다. New repo는 연결된 GitHub 계정에 저장소를 만들고 프로젝트를 첫 내용으로 커밋합니다. Pull은 브랜치를 읽어 텍스트 파일을 편집기로 가져옵니다. 모든 요청은 브라우저에서 api.github.com으로 직접 전송되며, LadeStack 서버가 중간에서 토큰을 보관하지 않습니다. 이 좁은 범위는 의도적입니다. 이 패널은 Git 명령줄을 대체하지 않습니다. rebase, 병합 충돌 해결, 서브모듈, Git LFS, 서명된 커밋, 훅, 여러 리모트를 제공하지 않습니다. 전체 커밋 그래프도 보여주지 않습니다. 복잡한 저장소에서는 이런 제한이 중요합니다. 정적 페이지, React 프로토타입, 수업 예제, 작은 유틸리티 같은 일반적인 브라우저 프로젝트에서는 세 작업이 탭 밖에서 실제로 필요한 부분을 다룹니다.

GitHub 동기화는 비밀번호나 GB Coder 계정이 아니라 개인 액세스 토큰을 사용합니다. 클래식 토큰에는 repo 스코프가 필요합니다. fine-grained 토큰에는 Contents 읽기 및 쓰기 권한이 필요하며, 단일 저장소로 제한할 수 있습니다. 더 좁은 옵션이 더 나은 기본값입니다. 토큰이 유출되어도 피해가 접근 가능한 프로젝트로 제한되기 때문입니다. 연결 화면은 GitHub 토큰 페이지로 연결하고 두 선택지를 설명합니다. 토큰을 붙여 넣고 기기에 기억할지 선택한 뒤 Connect를 누릅니다. GB Coder는 계정과 저장소 목록을 가져와 검증하고, 로그인한 사용자와 남은 API 레이트 리밋을 표시합니다. Push나 저장소 생성을 확인하기 전까지 저장소에는 아무것도 기록되지 않습니다. 토큰은 비밀번호처럼 다루십시오. 이슈, 채팅, 스크린샷에 붙여 넣지 말고, 필요 없어지면 GitHub에서 폐기하십시오. 만료일이 있고 하나의 저장소에만 접근하는 토큰은 이 흐름에 합리적인 절충입니다.

Push 탭은 저장소, 브랜치, 커밋 메시지, 그리고 프로젝트에 없는 파일을 삭제할지 여부를 묻습니다. 무언가 브라우저를 떠나기 전에 패널은 파일 수와 전체 크기를 보여줍니다. 업로드가 편집기 탭을 그대로 덤프하는 것이 아니므로 이 미리보기가 유용합니다. GB Coder는 ZIP 내보내기와 배포에 쓰는 것과 같은 아카이브 빌더를 사용합니다. 단순한 HTML/CSS/JavaScript 프로젝트는 index.html, style.css, script.js, README가 됩니다. React 또는 Vue 프로젝트는 index.html, package.json, vite.config.js, .gitignore, README, src/ 아래의 소스 파일로 구성된 Vite 형태 저장소가 됩니다. 의존성 폴더와 빌드 출력은 포함되지 않습니다. 커밋 메시지는 편집할 수 있고 기본값은 'Update from GB Coder'입니다. 없는 파일 삭제 옵션은 기본적으로 꺼져 있습니다. 저장소가 현재 프로젝트와 정확히 일치해야 할 때만 켜십시오. 로컬에 더 이상 없는 원격 파일을 삭제하기 때문입니다. 첫 Push에서는 의도적으로 별도 브랜치를 원하지 않는 한 저장소의 기본 브랜치를 선택하십시오.

순진한 브라우저 동기화는 파일을 하나씩 커밋합니다. 그러면 이력이 지저분해지고, 중간에 요청이 실패하면 저장소가 절반만 업데이트된 상태로 남습니다. GB Coder는 대신 GitHub의 Git Data API를 사용합니다. blob을 업로드하고, 브랜치의 현재 트리 위에 트리를 만들고, 하나의 커밋을 생성한 뒤 브랜치 참조를 이동합니다. 그 결과 Push마다 하나의 원자적 커밋이 생기며, 삭제 옵션으로 요청한 삭제도 포함됩니다. 두 번째 최적화는 더 조용하지만 똑같이 중요합니다. Git은 파일 내용을 SHA-1 해시로 식별하고, 브라우저는 WebCrypto로 그 해시를 로컬에서 계산할 수 있습니다. GB Coder는 업로드 전에 로컬 파일과 대상 트리를 비교합니다. 변경되지 않은 파일은 API 호출을 소비하지 않고, 아무것도 바뀌지 않은 Push는 빈 커밋을 만들지 않고 'already up to date'를 반환합니다. 이렇게 하면 이력이 읽기 쉬워지고 API 예산을 실제 변경에 쓸 수 있습니다. 작은 프로젝트에서는 차이가 보이지 않지만, 수십 개 파일이 있는 프로젝트에서는 깔끔한 동기화와 느리고 시끄러운 동기화의 차이가 됩니다.

New repo 탭은 연결된 계정에 저장소를 만듭니다. 이름과 선택적 설명을 입력하고 공개 또는 비공개를 고르며, GitHub가 README로 저장소를 초기화할지 결정합니다. 빈 저장소에는 첫 Push가 기반으로 삼을 브랜치 헤드가 없기 때문에 초기화는 기본적으로 켜져 있습니다. GB Coder는 그 시드 커밋을 사용해 README를 프로젝트 파일로 바꾸고 첫 커밋을 기록합니다. 초기화를 끄면 루트 커밋과 기본 브랜치 참조를 직접 만듭니다. 생성 후 새 저장소와 기본 브랜치가 다음 Push를 위해 선택되므로 두 번째 설정 단계가 없습니다. 아이디어에서 비공개 버전 관리 저장소로 가는 가장 짧은 경로입니다. 수업 과제, 비공개로 유지해야 하는 고객 데모, CI 서비스용 URL이 필요한 프로토타입에 유용합니다. 저장소는 토큰을 소유한 GitHub 계정에 속하며 LadeStack의 것이 아닙니다. 이후 GitHub에서 관리, 이전, 삭제할 수 있습니다.

Pull은 돌아오는 여정입니다. 저장소 URL 또는 owner/name 쌍을 입력하고 브랜치를 선택하면 GB Coder가 브랜치 트리를 읽습니다. 편집기에서 의미 있게 열 수 있는 텍스트 파일, 즉 소스 코드, JSON, Markdown, 설정, SVG 등을 가져옵니다. node_modules, dist, build, .git, .next, coverage 디렉터리는 건너뜁니다. 또한 Pull은 200개 파일, 파일당 512KB로 제한됩니다. 브랜치가 둘 중 하나를 넘으면 패널은 조용히 버리지 않고 몇 개 파일이 제외되었는지 알려줍니다. 줄바꿈은 정규화되어 Windows에서 만든 파일이 모든 줄이 바뀐 것처럼 보이지 않습니다. 가져온 파일이 프로젝트를 즉시 덮어쓰지는 않습니다. ZIP 가져오기와 같은 검토 및 적용 흐름을 거치므로 변경을 확정하기 전에 감지된 구조를 확인하고 나중에 되돌릴 수 있습니다. 따라서 Pull은 다른 기기에서 작업을 이어가거나, 편집 전에 저장소를 살펴보거나, 브라우저 저장소가 지워진 뒤 프로젝트를 복구하는 데 좋습니다. 이는 가져오기이지 병합이 아닙니다. 현재 프로젝트와 브랜치가 갈라졌다면 결과를 신중히 검토하십시오.

가장 중요한 안전 속성은 편집 중에 원격 브랜치가 움직일 때 일어나는 일입니다. GB Coder는 브랜치 참조를 force 비활성화 상태로 업데이트합니다. 그 사이 다른 사람이 Push했다면 GitHub는 업데이트를 거부하고, 패널은 그 작업을 조용히 버리지 않고 충돌을 보고합니다. 해결은 의도적으로 수동입니다. 최신 브랜치를 프로젝트로 Pull해 파일을 검토한 뒤 다시 Push하거나, 실제 병합을 위해 데스크톱 Git 클라이언트로 이동합니다. 다른 실패는 메시지에 따라 행동할 수 있도록 분리됩니다. 만료된 토큰은 인증 오류와 재연결 요청을 냅니다. 레이트 리밋은 GitHub 할당량이 언제 초기화되는지 보여줍니다. API는 인증된 사용자에게 시간당 5,000회 요청을 허용하며, Pull은 파일당 한 번의 요청을 사용합니다. 없는 저장소나 브랜치는 not-found 오류가 됩니다. 요청은 60초 후 타임아웃되고 긴 작업은 패널에서 취소할 수 있습니다. 이런 세부 사항은 화려하지 않지만, 신뢰할 수 있는 동기화 도구와 모호하게 실패하는 도구의 차이입니다.

토큰은 가치가 높은 자격 증명입니다. 쓰기 권한이 있는 GitHub 토큰은 접근 가능한 모든 저장소를 변경할 수 있습니다. GB Coder는 붙여 넣은 토큰을 기본적으로 모듈 스코프 맵에 보관합니다. 즉 탭을 닫으면 사라지고 localStorage에 기록되지 않습니다. 'Remember on this device' 옵션은 명시적 옵트인입니다. 이를 켜고 페이지가 보안 컨텍스트이면 토큰은 저장 전에 설치별 무작위 키로 AES-GCM 봉인됩니다. 이는 브라우저 프로필 백업, 동기화된 프로필, 공유 기기, 개발자 도구 스크린샷, 지원 번들에서 토큰이 읽히는 것을 막습니다. 같은 오리진에서 실행되는 스크립트는 막지 못합니다. 그 스크립트가 같은 저장 모듈을 호출할 수 있기 때문입니다. 브라우저 전용 설계로는 완전히 해결할 수 없습니다. 따라서 실질적인 통제는 범위, 만료, 폐기입니다. 필요한 저장소로 제한된 fine-grained 토큰을 사용하고 만료일을 설정하며, 작업이 끝나면 GitHub에서 토큰을 삭제하십시오. GitHub 트래픽은 브라우저에서 api.github.com으로 직접 가며 LadeStack이 자격 증명을 보관할 필요가 없습니다. 브라우저 저장소는 여전히 백업이 아니므로 저장소는 기기 밖 사본으로도 합리적입니다.

GitHub 동기화는 브라우저 프로젝트의 상당 부분에 충분합니다. 정적 사이트, React 또는 Vue 프로토타입, 수업 연습, 작은 내부 도구, 리모트와 배포 소스가 필요한 데모 등입니다. Git을 설치하지 않고 버전 관리를 원하는 1인 개발자, 재현 가능한 인계가 필요한 교사, 터미널이 없는 기기에서 작업하는 사람에게 맞습니다. 서브모듈이 있는 모노레포, Git LFS에 의존하는 저장소, 서명된 커밋이나 상세한 커밋 이력 검토가 필요한 팀, 훅과 여러 리모트에 기반한 릴리스 프로세스에는 충분하지 않습니다. 그것들은 데스크톱 Git 작업이며, 그렇지 않은 척하면 브라우저 흐름이 더 나빠집니다. 유용한 패턴은 하이브리드입니다. 첫 미리보기가 즉시 나오므로 브라우저에서 시작합니다. 유지할 가치가 있는 형태가 되면 Push합니다. 네이티브 도구, 더 깊은 디버거, 전체 Git 워크플로가 필요하면 같은 저장소를 데스크톱에서 엽니다. 브라우저로 돌아올 때 GitHub를 통해 변경 사항을 Pull합니다. 파일은 일반 소스 파일이므로 인계는 마이그레이션이 아니라 버전 관리입니다. 브라우저 쪽을 시험하려면 /app/projects의 Projects Dashboard를 열고 프로젝트를 만든 뒤 GitHub sync를 열어 첫 커밋을 Push하십시오. 전체 설정과 기능 참조는 문서에 있습니다.