코드 파일을 수정했는데 무엇이 달라졌는지 보기 어렵다면 GitHub Desktop에서 파일별 변경사항과 줄별 차이를 확인할 수 있습니다. 명령어를 먼저 외우지 않아도 변경 파일을 선택하고 설명을 적어 로컬 커밋을 만들 수 있는 무료 오픈소스 앱입니다. 이 글은 GitHub 공식 3.6.6 안정판의 Windows x64 설치 파일을 기준으로 첫 작업까지 안내합니다.
저장소를 컴퓨터에서 만드는 단계와 GitHub에 올리는 단계는 다릅니다. 로컬 커밋은 내 PC의 작업 기록이고, Publish repository나 Push origin은 원격 저장소와 동기화하는 동작입니다. 공개 여부가 중요한 프로젝트라면 원격으로 올리기 전에 저장소의 공개·비공개 선택을 확인하세요.
GitHub Desktop으로 무엇을 할 수 있나요?
GitHub Desktop은 Git 저장소를 화면으로 다루는 공식 데스크톱 앱입니다. Current Repository에서 작업할 저장소를 고르고, Changes에서 수정한 파일 목록과 차이를 살핀 뒤 Summary에 변경 이유를 적어 커밋할 수 있습니다. History에서는 앞서 저장한 커밋을 확인합니다. 처음 Git을 쓰는 사람에게 특히 유용하지만, 화면이 파일의 의미를 대신 판단해 주지는 않으므로 커밋 전에 선택한 변경사항을 읽어야 합니다.
처음부터 온라인에 코드를 올릴 필요는 없습니다. 공식 튜토리얼은 컴퓨터에서 저장소를 만들고 README를 수정한 뒤 Commit to main으로 로컬 기록을 남기는 순서를 설명합니다. GitHub 계정으로 로그인하면 원격 저장소를 만들거나 기존 저장소를 복제·동기화하는 기능을 사용할 수 있습니다. 팀 저장소에 올릴 때는 권한과 브랜치를 먼저 확인하세요.
이번에 확인한 공식 릴리스의 일반 Windows x64 설치 파일은 GitHubDesktopSetup-x64.exe입니다. 같은 릴리스에 시스템 전체 설치용 MSI도 있지만 이 글은 개인 PC에서 따라가기 쉬운 x64 EXE 한 가지를 다룹니다. 파일명에 x64가 붙어 있으므로 32비트 Windows 설치 파일인 것처럼 소개하지 않습니다.
GitHub 공식 화면에서 보는 변경사항과 커밋
제품 페이지와 GitHub Docs의 실제 GitHub Desktop 화면입니다. 앱 버전·계정 상태에 따라 버튼 배치나 표시 문구가 달라질 수 있습니다. 화면에 보이는 파일 내용은 예시입니다.
| 프로그램 | GitHub Desktop |
|---|---|
| 개발·배포 | GitHub 공식 데스크톱 프로젝트 |
| 확인 안정판 | 3.6.6 |
| 설치 파일 | Windows x64 EXE |
| 무료 범위 | GitHub Desktop 앱 무료 · 오픈소스 |
| 작업 | 저장소 만들기·복제, 변경사항 확인, 로컬 커밋, 원격 동기화 |
Windows x64 설치 파일을 정확히 고르기
GitHub 공식 릴리스에서 release-3.6.6을 열고 GitHubDesktopSetup-x64.exe를 고르세요. 파일명에 Setup-x64가 들어간 일반 사용자용 EXE입니다. 같은 목록의 GitHubDesktopSetup-x64.msi는 시스템 전체 설치를 관리할 때 쓰는 파일이므로 처음 설치하는 경우 두 파일을 모두 받을 필요가 없습니다. 릴리스 주소의 소유자가 github.com/desktop/desktop인지도 확인하세요.
Windows 설정에서 시스템 종류가 64비트인지 먼저 확인하세요. 이 안내의 파일은 Windows x64용입니다. macOS에서는 운영체제에 맞는 별도의 공식 파일을 선택해야 하고, 이 x64 EXE를 열 수 없습니다. GitHub Desktop 공식 앱의 다운로드는 무료이지만 GitHub 서비스의 각 계정·저장소 요금제와 앱의 무료 배포는 다른 이야기입니다.
- Windows 설정에서 64비트 시스템인지 확인합니다.
- 공식 3.6.6 릴리스의 GitHubDesktopSetup-x64.exe를 선택합니다.
- 다운로드 폴더에서 파일명과 릴리스 주소를 다시 대조합니다.
앱을 열고 첫 로컬 저장소 만들기
받은 설치 파일을 Windows에서 열어 설치를 마치고 GitHub Desktop을 실행하세요. 공식 튜토리얼은 시작할 때 GitHub 계정 인증을 안내합니다. 온라인 저장소를 게시하거나 복제하려면 해당 계정에 로그인해야 합니다. 설치 과정의 버튼 문구는 버전에 따라 달라질 수 있으므로 설치 창을 그대로 외우기보다 앱의 저장소 화면이 열리는지 확인하세요.
File 메뉴에서 New repository를 선택하고 이름과 컴퓨터에 저장할 위치를 정합니다. README를 포함하도록 선택하면 첫 파일을 바로 편집해 볼 수 있습니다. Create repository 후 왼쪽 상단 Current Repository에 새 이름이 보이는지 확인하세요. 이 단계의 파일은 내 컴퓨터에 있으며, Publish repository를 누르기 전까지 자동으로 공개 저장소가 되는 것은 아닙니다.
- GitHub Desktop을 실행해 계정 인증을 진행합니다.
- File > New repository에서 이름·로컬 위치·README 포함 여부를 정합니다.
- Current Repository에 새 저장소가 나타나는지 확인합니다.
변경 파일을 읽고 첫 커밋 만들기
README에 한 줄을 추가해 저장한 뒤 GitHub Desktop의 Changes 탭을 여세요. 왼쪽 목록의 README를 선택하면 오른쪽에서 수정한 줄을 비교할 수 있습니다. 커밋에 넣고 싶지 않은 파일이 함께 보인다면 왼쪽 체크 표시를 살펴 선택 범위를 조정하세요. 비밀번호나 토큰 같은 민감한 값이 들어간 줄은 기록으로 남기기 전에 반드시 제거해야 합니다.
왼쪽 아래 Summary에 이번 변경을 설명하는 짧은 말을 적고 필요하면 Description에 이유를 더하세요. 그런 다음 Commit to main을 눌러 로컬 커밋을 만듭니다. 공식 화면의 브랜치가 main이 아닐 수 있으므로 실제 버튼에는 Commit to 현재 브랜치가 표시될 수 있습니다. History 탭에 새 커밋이 나타나면 PC에서 첫 변경 기록이 완성된 것입니다.
원격으로 올릴 계획이라면 그다음 Publish repository 또는 Push origin을 사용합니다. Publish repository는 새 원격 저장소를 만드는 단계이고, Push origin은 이미 연결된 원격으로 로컬 커밋을 보내는 단계입니다. 새 원격 저장소를 만들 때 비공개 옵션이 선택되었는지 확인한 뒤 게시하세요. 로컬 커밋만 원했다면 이 단계는 건너뛰어도 됩니다.
- README를 수정한 뒤 Changes에서 실제 변경 파일과 줄을 확인합니다.
- Summary를 적고 Commit to 현재 브랜치를 누릅니다.
- History에 커밋이 보이는지 확인하고, 필요할 때만 원격 게시·푸시합니다.
기존 저장소를 복제하거나 동기화가 안 될 때
이미 GitHub에 있는 프로젝트라면 File > Clone repository에서 복제할 저장소와 컴퓨터의 저장 위치를 선택하세요. 공식 문서는 GitHub.com 목록에서 고르거나 저장소 URL을 입력하는 방법을 안내합니다. 복제 전에는 소유자와 저장소 주소, 접근 권한을 확인해야 합니다. 다른 사람의 저장소를 수정해 올릴 계획이면 직접 푸시 권한이 있는지와 포크가 필요한지를 구분하세요.
변경 파일이 안 보인다면 Current Repository가 실제 수정한 폴더인지 확인하세요. 다른 브랜치에 커밋했다면 Current Branch 표시와 History를 먼저 비교합니다. Push origin이 실패한다면 GitHub 로그인 상태, 해당 저장소 권한, 네트워크 연결, 원격 변경 여부를 확인하세요. 인증 오류를 해결하려고 토큰을 본문이나 커밋 메시지에 붙여 넣지 마세요.
- Current Repository와 Current Branch가 예상한 대상인지 확인합니다.
- 기존 프로젝트는 File > Clone repository에서 소유자·URL·저장 위치를 확인합니다.
- 푸시 실패 시 계정 권한과 원격 상태를 확인합니다.
여러 파일을 고칠 때 커밋을 나누는 기준
README 문구 수정과 프로그램 오류 수정을 한 번에 했다면 Changes 목록에서 두 변경을 구분해 보세요. 관련된 파일만 선택하고 그 작업을 설명하는 Summary를 적으면 나중에 History에서 왜 바꿨는지 읽기 쉽습니다. 첫 커밋에서는 README 한 파일만 고르는 식으로 시작하면 선택 표시가 커밋 범위에 어떤 영향을 주는지 이해하기 좋습니다. 선택을 바꾼 뒤에는 오른쪽 차이 화면을 다시 읽어 실제 넣을 줄이 맞는지 확인하세요.
특히 설정 파일을 편집한 프로젝트에는 접속 비밀번호, 개인 키, 토큰, 로컬 경로처럼 저장소에 남기면 안 되는 값이 섞일 수 있습니다. GitHub Desktop의 화면이 이런 정보를 자동으로 안전하게 지워 주는 것은 아닙니다. 공개 저장소가 아니어도 팀원이 원격 기록을 볼 수 있으므로, 민감한 값은 커밋 전에 파일에서 제거하고 프로젝트가 요구하는 별도 보관 방식을 사용하세요. 이미 기록한 값을 나중에 지우는 일은 단순히 파일 한 줄을 삭제하는 것보다 복잡합니다.
브랜치를 여러 개 쓰는 팀이라면 커밋 직전에 Current Branch 이름을 다시 읽으세요. 같은 파일을 바꿨어도 어느 브랜치에서 커밋했는지에 따라 동료가 보는 작업 흐름이 달라집니다. 로컬 커밋이 끝난 뒤 바로 원격으로 보내기보다 History에서 요약과 파일 범위를 한 번 확인하면 엉뚱한 변경을 공유할 가능성을 줄일 수 있습니다. 원격 저장소에 새 변경이 이미 있다면 먼저 팀의 동기화 순서를 확인한 뒤 푸시하세요.
- Changes에서 이번 작업과 관련된 파일만 선택합니다.
- 차이 화면에 비밀번호·토큰 같은 값이 없는지 확인합니다.
- Current Branch와 Summary를 읽고 커밋한 뒤 History에서 기록을 확인합니다.
자주 묻는 질문
GitHub Desktop 앱은 무료인가요?
예. GitHub의 공식 도움말은 GitHub Desktop을 무료 오픈소스 앱으로 소개합니다. 온라인 GitHub 서비스의 계정 요금제와는 구분하세요.
3.6.6 Windows 설치 파일은 어느 것인가요?
개인 Windows x64 PC에는 공식 release-3.6.6의 GitHubDesktopSetup-x64.exe를 고르세요. MSI는 별도의 시스템 전체 설치용 파일입니다.
Commit을 누르면 바로 GitHub에 공개되나요?
아니요. Commit to 현재 브랜치는 우선 로컬 기록을 만듭니다. Publish repository나 Push origin 같은 원격 동작은 별도로 진행합니다.
수정한 파일이 Changes에 안 나오는 이유는 무엇인가요?
Current Repository가 수정한 폴더를 가리키는지, 파일을 저장했는지, Current Branch가 예상한 브랜치인지 확인하세요.
기존 GitHub 저장소도 열 수 있나요?
예. File > Clone repository에서 접근 가능한 저장소 또는 URL을 선택하고 로컬 저장 위치를 지정할 수 있습니다.
변경 파일을 확인한 뒤 로컬 커밋부터 남기세요
GitHub Desktop 3.6.6의 공식 Windows x64 EXE를 설치한 뒤 README가 있는 저장소를 만들고 한 줄을 수정해 보세요. Changes에서 파일과 줄별 차이를 읽고 Summary를 적어 커밋하면 프로그램이 필요한 첫 작업을 마친 것입니다.
온라인 게시가 필요하다면 History에서 방금 만든 로컬 커밋을 확인한 뒤 Publish repository의 공개 범위와 저장소 소유자를 살피세요. 기존 저장소를 다룰 때는 복제 대상과 브랜치를 먼저 확인하면 다른 프로젝트에 변경을 올리는 실수를 줄일 수 있습니다.
공식 자료와 확인일
GitHub Desktop 공식 제품 페이지 · GitHub Desktop 3.6.6 공식 안정판 릴리스 · GitHub Docs: 첫 저장소 만들기와 커밋 · GitHub Docs: 저장소 복제와 포크 · GitHub Desktop 공식 라이선스 | 2026-10-04T21:24:22.307543+00:00
