https://desktop.github.com/download/
Download GitHub Desktop
Simple collaboration from your desktop
desktop.github.com
1. 로컬에 파일이 기존 있을때 방법 [업로드] 방법
동우님, 지금 화면에서는 GitHub Desktop 첫 시작 화면이 보이고 있고, 여기서 “기존에 작업하던 폴더(이미 내 PC에 있는 프로젝트)”를 GitHub에 업로드하려면 아래 옵션 중 하나를 선택하시면 됩니다.
가장 정확한 선택은 “Add an Existing Repository from your local drive…” 입니다.
선택해야 하는 메뉴
✔ Add an Existing Repository from your local drive…
이미 PC 안에 폴더가 있고, 그 폴더를 깃허브로 올리려는 경우 이걸 선택해야 합니다.
- 해당 버튼 클릭
- 기존 프로젝트 폴더 선택
- “Add Repository” 클릭
- GitHub Desktop 좌측 메뉴에 프로젝트가 나타나면
- “Publish repository” 버튼이 생깁니다
- 그 버튼을 누르면 GitHub로 바로 업로드됩니다.
과정 요약
- GitHub Desktop 오른쪽 → Add an Existing Repository from your local drive…
- 기존에 쓰던 폴더 선택 (앱 프로젝트 폴더)
- 불러와지면 상단에 Publish repository 버튼 클릭
- GitHub 계정 선택 → 저장소 이름 입력 → 확인
이러면 바로 GitHub로 올라갑니다.
만약 기존에 .git 폴더가 없다면?
GitHub Desktop이 자동으로 Git 초기화를 해줍니다.
따로 터미널에서 git init 할 필요 없습니다.
원하시면
- “폴더 선택부터 게시(Publish)까지 전체 단계 스크린샷으로 설명”
- “오류 없이 올리는 설정(특히 .idea 제외 등)”
도 추가로 안내해드릴게요.
기존 폴더 경로만 알려주시면 더 정확하게 맞춰서 안내해드릴 수 있습니다.
2. 포멧된 새 컴퓨터에서 깃 허브 파일들을 [다운로드] 해야 할때 로컬로..
동우님, 이번에는 완전히 새 컴퓨터(포맷 직후) 에서 GitHub Desktop만 설치된 상태에서
GitHub에 올려둔 저장소를 로컬 컴퓨터로 다운로드(=Clone) 하는 방법을 아주 쉽게 단계별로 알려드릴게요.
아무것도 없는(소스코드가 하나도 없는) 컴퓨터에서 GitHub Desktop을 이용해 다운로드하는 정석 절차입니다.
✔ 1. GitHub Desktop 실행 → 첫 화면에서 “Clone” 메뉴 선택
GitHub Desktop을 켜면 오른쪽에 이런 메뉴가 보입니다:
- Clone a repository from the Internet…
이 버튼을 클릭합니다.
(만약 첫 화면이 안 나오면
상단 메뉴 File → Clone repository… 를 눌러도 동일합니다.)
✔ 2. GitHub Desktop이 자동으로 당신의 GitHub 저장소 리스트를 보여줌
GitHub Desktop은 이미 GitHub 계정으로 로그인되어 있기 때문에
GitHub 계정의 저장소 목록이 자동으로 뜹니다.
여기서 동우님 저장소:
oklokl/odds-and-ends
같은 저장소가 목록에 나옵니다.
✔ 3. 다운로드(클론)할 저장소 선택
저장소 목록에서 다운로드하고 싶은 저장소를 클릭합니다.
예:
- odds-and-ends
- mic-recorder
- whatever-project
✔ 4. Clone 위치(로컬 폴더) 선택
GitHub Desktop 하단에 이렇게 표시됩니다:
Local path: C:\Users\동우님\Documents\GitHub\odds-and-ends
원하는 폴더로 변경할 수도 있습니다.
예:
D:\AndroidStudioProjects\odds-and-ends
다 선택했으면:
✔ Clone 버튼 클릭
✔ 5. 자동으로 다운로드(클론) 시작됨
GitHub Desktop이:
- GitHub 서버에서 소스코드를 내려받고
- 로컬 폴더를 만들고
- Git 연결도 자동 설정해 줍니다.
그러면 이제 PC 안에 소스코드가 모두 내려와 있습니다.
✔ 6. Android Studio에서 열기 (선택)
GitHub Desktop 오른쪽에 있는 버튼:
- Open in Android Studio
이걸 누르면 Android Studio에서 바로 프로젝트 열립니다.
🔄 전체 흐름 요약
- GitHub Desktop 실행
- File → Clone repository…
- GitHub 탭에서 내 저장소 선택
- Clone 경로 선택
- Clone 버튼 클릭 → 로컬로 다운로드 완료
- 필요하면 Android Studio에서 열기
🔐 참고: 해킹/보안 이슈 없음
Clone은 “읽기 전용 다운로드”이기 때문에
로컬 컴퓨터에 소스가 내려오는 것이며
계정 보안과 무관합니다.
✔ 원하시면
동우님이 실제로 사용하는 GitHub 저장소 이름을 알려주시면
그 저장소를 로컬에 Clone하는 “그림이 있는 단계별 가이드”도 만들어 드릴게요.
또는 GitHub Desktop 화면을 캡처해주시면
“여기서 이 버튼 누르세요” 식으로 정확하게 안내해드릴 수 있습니다.
제외
동우님, GitHub Desktop에서 특정 폴더·파일을 제외(무시) 하려면
Git에서 사용하는 .gitignore 파일에 등록해야 합니다.
아래에 한국 개발자들이 Android/Windows 프로젝트 올릴 때 반드시 제외하는 목록과 등록 방법을 단계별로 정리해드릴게요.
1. GitHub Desktop에서 .gitignore 만드는 방법
방법 A) GitHub Desktop 메뉴에서 바로 생성
- GitHub Desktop에서 repository를 열기
- 상단 메뉴 → Repository → Repository Settings…
- 왼쪽 메뉴에서 Ignored Files 선택
- 입력창에 제외할 경로를 쓰고 Save
GitHub Desktop이 자동으로 .gitignore 파일을 생성하고 업데이트합니다.
2. 수동으로 .gitignore에 추가하는 방법
프로젝트 폴더 루트에 .gitignore 파일을 만들고 아래 내용을 넣으면 됩니다.
Windows → 메모장으로 생성해도 됩니다.
파일명:
.gitignore
3. Android Studio / Windows 프로젝트에서 반드시 제외해야 하는 항목(권장 리스트)
기본적으로 오류·충돌 원인이라 반드시 제외하는 목록입니다.
Android 프로젝트 전용 제외 항목
# Gradle
.gradle/
build/
# Android Studio
.idea/
local.properties
# Generated files
*.iml
.DS_Store
GitHub Desktop용 일반 제외 항목
# OS files
Thumbs.db
desktop.ini
# Logs
*.log
앱 설정 파일 중 절대 올리면 안 되는 것
local.properties
(컴퓨터마다 ANDROID_SDK 경로가 달라 오류 원인)
4. GitHub Desktop에서 파일 제외가 실제로 적용되었는지 확인하는 방법
- GitHub Desktop에서 해당 파일이 파란색으로 표시돼 커밋 대상이 되어 있다면
→ .gitignore에 등록한 후에도 여전히 보임
→ 이 경우 이미 Git이 추적 중이기 때문입니다. - 이미 추적 중인 경우는 아래 명령을 GitHub Desktop에서 실행해야 합니다.
GitHub Desktop → Repository → Open in Terminal
아래 명령을 입력:
git rm -r --cached .
git add .
git commit -m "Apply .gitignore rules"
이 명령은
- Git이 추적 중인 파일들을 전부 “캐시에서만 제거”
- .gitignore 규칙을 다시 적용
하는 작업입니다.
실제 파일은 삭제되지 않으니 걱정하지 않아도 됩니다.
5. GitHub Desktop에서 .gitignore 등록 화면 예시가 필요하면?
현재 화면을 보여주시면, 어떤 버튼을 누르면 되는지 그림 기준으로 정확하게 알려드릴 수 있습니다.
원하시면
- 동우님 프로젝트에 맞춘 맞춤형 .gitignore 파일
- Android/Windows 두 프로젝트 같이 올릴 때 권장 구조
- GitHub Desktop 게시(Publish) 오류 해결
도 바로 만들어 드릴게요.
프로젝트 종류(Android 앱인지, Windows 앱인지, Kotlin/Java인지) 알려주시면 더 정확하게 작성해드리겠습니다.
좋은 질문입니다.
안드로이드 앱이라면 aab 파일은 Git에 올리지 않는 것이 일반적입니다.
aab, apk 둘 다 “빌드하면 다시 만들어지는 산출물(결과물)”이라 보통은 .gitignore로 제외합니다.
1. 안드로이드용 .gitignore 예시
프로젝트 루트에 .gitignore 파일을 만들고 아래 내용을 그대로 넣으시면 됩니다.
########################
# Android / Gradle
########################
# Gradle
.gradle/
**/build/
!gradle/wrapper/gradle-wrapper.jar
# Local configuration
local.properties
.gradle/
.gradle/**
########################
# Android Studio / IDE
########################
.idea/
*.iml
# NDK / CMake
.cxx/
.externalNativeBuild/
# Captures (화면 캡처 등)
captures/
########################
# Build outputs
########################
# 앱 빌드 결과물 (Git에 올리지 않음)
*.apk
*.ap_
*.aab
*.aar
*.dex
*.class
# 로그
*.log
########################
# OS / 기타
########################
.DS_Store
Thumbs.db
########################
# 보안 관련 (절대 올리면 안 되는 것)
########################
# 키스토어 및 서명 설정
*.jks
*.keystore
key.properties
keystore.properties
이렇게 해두면:
- app/build/ 안의 apk, aab 파일은 전부 자동으로 제외
- local.properties 같은 PC마다 다른 설정도 제외
- Android Studio 설정(.idea), 로그, OS 임시파일 등도 제외됩니다.
2. aab는 어떻게 관리하는 게 좋을까?
- Git에는 제외(.gitignore)
- 위처럼 *.aab를 넣어두면 GitHub에 올라가지 않습니다.
- 실제 배포할 때는
- Android Studio에서 Build > Generate Signed Bundle/APK로 aab 생성
- 그 aab를 Play Console에 업로드
- 백업이 필요하면
- GitHub의 “Releases” 기능에 파일로 올리거나
- 별도 클라우드(구글 드라이브 등)에 보관하는 방식이 많이 쓰입니다.
즉,
- 소스코드 + 설정만 Git에 올리고
- 빌드 결과물(apk/aab) 은 항상 새로 빌드해서 쓰는 방식이 일반적인 안드로이드 워크플로우입니다.
3. 이미 aab 또는 build 폴더가 올라간 상태라면
이미 GitHub에 올라가 있다면, .gitignore만 추가해도 자동으로 사라지지 않습니다.
그럴 때는 한 번 아래 명령으로 “추적만 끊어주기”가 필요합니다.
GitHub Desktop → Repository → Open in Terminal 선택 후:
git rm -r --cached .
git add .
git commit -m "Apply .gitignore for Android project"
이렇게 하면:
- 실제 파일은 PC에서 지워지지 않고
- Git이 더 이상 그 파일들을 추적하지 않게 됩니다.
원하시면,
동우님이 현재 프로젝트에 사용 중인 폴더 구조(예: app, feature_x 모듈 등)를 알려 주시면
그 구조에 딱 맞는 맞춤형 .gitignore도 한 번 더 정리해 드리겠습니다.
삭제.
동우님, 이 부분은 Git을 쓰는 많은 개발자들이 처음에 가장 많이 헷갈리는 부분입니다.
정확하게 정리해 드릴게요. 정답은: “로컬에서 삭제 → GitHub Desktop에서 커밋·푸시 → GitHub 사이트도 자동 삭제” 입니다.
GitHub 사이트를 먼저 삭제하면 오히려 충돌이 납니다.
핵심 요약
✔ 삭제는 반드시 로컬에서 먼저 하고 → GitHub Desktop에서 Push
그러면 GitHub 사이트에서도 자동으로 삭제됩니다.
✘ GitHub 사이트에서 먼저 삭제하면 안 됩니다.
로컬과 원격 상태가 서로 달라져서 오류가 발생합니다.
1. 올바른 삭제 방법 (정석)
① 로컬 컴퓨터 프로젝트 폴더에서 원하는 폴더/파일을 삭제
예:
app/sample/
build/
old_code/
② GitHub Desktop에서 변경 사항이 자동 표시됨
→ 삭제된 파일 목록이 빨간 표시로 나타납니다.
③ Commit → Push
- Commit 메뉴에 “Deleted XYZ” 같은 표시가 뜸
- Push 하면 GitHub 사이트에서 동일하게 삭제됩니다.
2. 절대 해서는 안 되는 삭제 방법
❌ GitHub 사이트(웹)에서 먼저 삭제
- 로컬 파일은 그대로 있음
- Git 상태가 어긋나면서 Pull 할 때 충돌 발생
- Push 하면 “non-fast-forward” 오류
- GitHub Desktop에서 “history mismatch”, “conflict” 등 오류 발생
❌ 로컬에서 삭제하고 GitHub 사이트에서도 다시 수동 삭제
- 역시 Git이 “어? 둘이 내용이 안 맞는데?”라고 인식
- Pull / Push 충돌 발생
동우님이 겪은 오류는 바로 이 경우입니다.
3. 이미 사이트와 로컬 둘 다 삭제해서 오류가 난 경우 해결법
이 경우는 로컬 저장소 상태와 GitHub 원격 저장소 상태가 서로 달라서 충돌이 난 것입니다.
아래 순서로 복구 가능합니다.
복구 단계 (안전한 방법)
① GitHub Desktop → 메뉴 → Repository → Open in Terminal
② 아래 명령으로 “로컬 Git 캐시 초기화”
git fetch --all
git reset --hard origin/main
(브랜치가 main이 아니라 master면 master로 변경)
의미
- origin/main과 로컬을 다시 동일하게 맞춤
- 충돌이 모두 사라짐
- 로컬 파일들이 GitHub와 완전히 일치
③ 다시 원하는 폴더만 삭제하고 Commit → Push
이제 깨끗하게 동기화됩니다.
4. 앞으로 오류 없이 삭제하는 안전한 원칙
규칙 1) 삭제는 반드시 로컬에서 먼저
규칙 2) GitHub Desktop에서 Commit → Push
규칙 3) GitHub 사이트에서는 절대로 수동 삭제하지 않기
규칙 4) 만약 실수로 사이트에서 먼저 삭제했다면 → Pull 하고 나서 조작
5. 원하시면…
동우님이 현재 GitHub Desktop에서 어떤 오류 메시지를 받고 계신지 화면을 보내주시면
- 정확히 어떤 파일 기준 충돌인지
- Reset 해야 하는지
- 병합해야 하는지
즉시 판단해서 해결 절차 알려드릴 수 있습니다.
지금 상태가 많이 꼬였으면 바로 복구해 드릴게요.
망가진 경우 고치기
동우님, 의도가 무엇인지에 따라 명령어의 작동 결과가 반대가 될 수도 있어서 아주 정확하게 설명드리겠습니다.
지금 질문하신 내용은:
“git fetch --all
git reset --hard origin/main
명령을 사용하면 망가진 것을 ‘로컬 기준’으로 복구시키는 건가요?”
정확한 답은 아닙니다.
이 명령은 ‘원격(GitHub) 기준으로 로컬을 강제로 맞추는 방식’ 입니다.
즉:
- 로컬이 원본이 아니라
- GitHub(origin/main)가 원본으로 간주되고
- 로컬을 원격과 똑같이 덮어씌우는 명령입니다.
✔ 명령의 정확한 의미
1) git fetch --all
- 원격(GitHub)의 최신 상태를 가져오기만 함
- 로컬 파일에 변화 없음
2) git reset --hard origin/main
- 로컬을 GitHub 원격 저장소와 완전히 동일하게 만듦
- 로컬에서 수정한 파일, 삭제한 파일 등
모든 로컬 변경 사항이 사라짐(되돌릴 수 없음) - 즉,
로컬이 GitHub 버전으로 “덮어쓰기” 됩니다.
✔ 쉽게 말하면
origin/main → 로컬로 강제 복구
“로컬의 것을 원본으로 삼겠다”
가 아니라
GitHub(원격)의 것을 원본으로 삼고 로컬을 덮어씌우겠다
입니다.
❗ 이런 상황에서 쓰면 안 되는 경우
- 로컬에 중요한 코드가 있음
- GitHub에는 잘못된 코드가 올라간 상태
- “로컬을 유지하고 GitHub을 로컬처럼 만들고 싶은 경우”
→ 이 명령을 쓰면 로컬의 좋은 코드가 전부 날아갑니다.
✔ 동우님 의도 파악
질문하신 문장을 보면:
“원본대로 하고 싶어서 맞나요?”
“로컬이 원본이라서요.”
동우님이 원하는 것은:
✔ “로컬 → GitHub로 덮어쓰기”
✔ “로컬이 원본이므로 GitHub도 로컬과 같게 만들고 싶다”
이 상황에서는 절대로
git reset --hard origin/main
를 쓰시면 안 됩니다.
👉 동우님이 원하는 동작(로컬을 원본으로 유지)은 아래 명령
✔ GitHub(원격)을 로컬 기준으로 덮어쓰기 하는 방법
1) 강제로 푸시
GitHub Desktop → Terminal 열고:
git push --force
이렇게 하면:
- GitHub의 내용을 모두 지우고
- 로컬 상태를 그대로 GitHub에 강제 반영합니다.
✔ 결론 요약
목적 사용해야 하는 명령
| GitHub(원격) 내용을 기준으로 로컬을 맞추고 싶다 | git fetch --all + git reset --hard origin/main |
| 로컬 내용을 기준으로 GitHub을 덮어버리고 싶다(로컬이 원본) | git push --force |
동우님이 말한 목적은 두 번째입니다.
그러므로 git reset --hard origin/main은 쓰면 안 되고,
force push를 사용해야 합니다.
필요하시면
- 지금 동우님 로컬 상태와 GitHub 상태를 비교해 어떤 명령을 써야 하는지
- 충돌 없이 다시 정상 상태로 복원하는 절차
도 확인해드릴게요.
GitHub Desktop 화면(Changes / History 화면)을 캡처해 주시면
딱 맞는 명령을 정확하게 안내해드리겠습니다.
터미널 들어 가기
동우님, 지금 올려주신 메뉴 화면을 보면
GitHub Desktop에서는 “터미널”이라는 단어 대신 “Command Prompt”라고 표시되어 있습니다.
즉, 동우님 화면에서 터미널 = Open in Command Prompt 입니다.
아주 간단하게 정리해드릴게요.
✔ GitHub Desktop에서 터미널(커맨드 프롬프트) 여는 버튼
이걸 누르시면 됩니다:
Repository → Open in Command Prompt
바로 이 메뉴입니다:
Repository
└─ Open in Command Prompt (Ctrl + `)
✔ 이걸 클릭하면 어떤 일이 생기나요?
- **자동으로 Git 저장소 폴더 위치에서 CMD(명령 프롬프트)**가 열립니다.
- 이제 Git 명령이 정상적으로 작동합니다.
- 여기서 아래 명령을 실행하면 됩니다:
git fetch --all
git reset --hard origin/main
(또는 동우님이 원하시는 경우 git push --force)
✔ 왜 꼭 GitHub Desktop에서 열어야 하나?
- 그냥 윈도우 CMD를 열면
C:\Users\xxx> 이런 곳에서 열려서
Git이 “여기 Git 저장소 아님(.git 없음)” 이라고 오류를 냅니다. - GitHub Desktop에서 “Open in Command Prompt”를 누르면
자동으로 저장소 폴더 경로에서 실행되기 때문에
Git 명령이 정상 동작합니다.
원하시면
동우님이 지금 실제로 어떤 작업을 하고 싶은지
“로컬을 원본으로 할 것인지”
“GitHub 쪽을 원본으로 할 것인지” 확인해 드리고
정확한 명령 한 줄만 선택해서 알려드릴게요.
지금 어떤 방향으로 맞추고 싶으신가요?
한글이 깨지면서 에러가 나는 경우

동우님, 화면 잘 봤습니다.
이 문제는 **Git 자체 오류가 아니라 “윈도우 CMD의 문자 인코딩 문제 때문에 발생하는 출력 오류”**입니다.
결론부터 말씀드리면:
✔ 로컬과 GitHub는 정상적으로 reset 되었습니다.
✔ 출력 글자가 깨져 보이는 것뿐이며, Git 명령은 성공했습니다.
✔ 아무 문제 없습니다. 그대로 다음 단계 진행하시면 됩니다.
그래도 불안하실 수 있으니, 아주 정확하게 설명드리겠습니다.
1. 지금 발생한 문제의 원인
스크린샷의 오류 메시지 중:
fatal: unknown write failure on standard output
이 메시지는 Git이 아니라 CMD가 한글 출력 처리를 못해서 발생하는 출력 문제입니다.
실제 내부 동작은 정상적으로 수행되었습니다.
2. 정상적으로 reset 되었는지 확인하는 방법
GitHub Desktop → History 탭을 보세요.
- 가장 최근 커밋이 GitHub 사이트와 동일한지
- 로컬 브랜치가 origin/main 위치와 같아졌는지
확인해보면 성공 여부를 바로 알 수 있습니다.
3. 만약 글자 깨짐이 싫다면 (CMD 인코딩 변경)
아래 한 줄을 CMD에서 입력하면 됩니다:
chcp 65001
이후 다시:
git reset --hard origin/main
그러면 글자가 깨지지 않습니다.
4. 지금 동우님이 해야 할 다음 단계는?
동우님이 “로컬을 원본으로 할 것인지 / GitHub을 원본으로 할 것인지”에 따라 다릅니다.
✔ GitHub 내용을 기준으로 하고 싶다면
이미 reset 성공했으니 이제 깨끗한 상태입니다.
✔ 로컬 내용을 기준으로 하고 싶다면
reset 대신 아래 명령을 사용해야 합니다:
git push --force
이 경우 GitHub 사이트 내용이 “로컬 내용으로 완전히 대체”됩니다.
5. 지금 상태를 보고 정확한 조치를 알려드리기 위해
잠깐 GitHub Desktop 화면 하나만 보여주세요:
⇒ GitHub Desktop 상단에서 History 탭을 클릭한 화면
(어떤 커밋들이 보이는지 확인하려고요)
그 화면을 올려주시면:
- 현재 로컬 상태
- 원격과의 차이
- 어떤 명령을 적용해야 할지
를 정확하게 판단해 드릴 수 있습니다.
원하시면 바로 고쳐드릴게요.

네, 동우님 — 완벽하게 성공하셨습니다.
지금 화면을 보면 두 가지가 모두 정상적으로 처리된 것이 확인됩니다.
✔ 1. git reset --hard origin/main 성공
출력:
HEAD is now at cdcc377 ...
이 메시지는 로컬이 GitHub(origin/main)의 상태와 100% 동일하게 맞춰졌다는 뜻입니다.
출력된 한글 깨짐은 그냥 이전 CMD 인코딩 문제였고, 지금은 chcp 65001로 해결됐기 때문에 정상입니다.
✔ 2. git push --force 결과: Everything up-to-date
출력:
Everything up-to-date
이 의미는:
- 로컬과 GitHub 내용이 이미 동일함
- 푸시할 새로운 변경 사항 없음
- 즉, 로컬과 원격의 싱크가 완벽하게 맞춰진 상태
입니다.
이 말은 지금 동우님 Git 상태는 완전히 정상이라는 뜻입니다.
✔ 결론:
동우님 저장소는 깨끗하게 복구되었고, GitHub와 로컬은 서로 완전히 동일한 상태입니다.
더 이상 어떠한 충돌도 없고, GitHub Desktop으로 정상 작업 가능해요.
✔ 추가 확인(선택)
GitHub Desktop → History 탭을 확인해보면
로컬 커밋 목록과 GitHub 사이트의 커밋 목록이 완전히 동일하게 보일 거예요.
필요하시면 다음도 안내해 드릴 수 있어요:
- 안드로이드 프로젝트용 완성된 .gitignore 자동 생성
- 불필요한 파일 제외 설정 방법
- 폴더 삭제할 때 충돌 절대 안 나는 안전한 방법
- GitHub Desktop에서 “깨끗한 상태 유지하기” 팁
원하시는 방향으로 계속 도와드릴게요!
동우님, GitHub Desktop을 처음 설치할 때 Git을 따로 설치해야 하는지 궁금하신 거죠?
결론부터 아주 간단하게 설명드릴게요.
✔ 결론: GitHub Desktop은 Git을 “자동으로 포함”합니다
따라서 Git을 따로 설치할 필요가 없습니다.
GitHub Desktop 설치 파일 안에 Git이 기본 포함되어 있어서,
동우님처럼 GitHub Desktop만 설치해도 바로 Git 명령을 쓸 수 있게 되어 있습니다.
✔ 하지만 “Git만 단독으로 설치하고 싶다”면?
그럴 때는 Git 공식 사이트에서 설치할 수 있습니다.
✔ Git 공식(오리지널) 사이트
공식 사이트:
https://git-scm.com/
여기서 Windows, macOS, Linux 버전을 다운로드할 수 있습니다.
✔ Git 설치 방법 (아주 간단하게 요약)
Windows 기준:
- 위 사이트에서 Git for Windows 다운로드
- 설치 실행
- 옵션은 전부 기본값 그대로 두고 Next → Next → Install
- 완료 버튼 클릭
여기까지 하면
- Git Bash
- Git CMD
- Git GUI
가 자동 설치됩니다.
✔ Git 단독 설치가 필요한 사람은 누구인가?
보통 아래 중 하나일 때만 필수입니다:
- GitHub Desktop 없이 Git Bash에서 직접 명령어로 작업하고 싶은 경우
- Android Studio, VSCode에서 Git 기능을 연동하려는 경우
- 고급 Git 기능(리베이스, 체리픽 등)을 CLI에서 쓰고 싶은 경우
동우님처럼 GitHub Desktop 중심으로 작업하는 스타일이라면
Git을 따로 설치하지 않아도 현재처럼 정상적으로 모두 사용할 수 있습니다.
✔ 동우님 상황에 대한 결론
- 이미 GitHub Desktop 안에 Git이 포함 → 별도 설치 필요 없음
- 지금 모든 기능이 정상 작동하므로 추가로 설치할 필요 없음
필요하시면 아래도 설명드릴게요:
- Git과 GitHub의 차이(헷갈리는 개념들)
- GitHub Desktop 내부에서 Git 버전 확인하는 방법
- Git Bash vs Windows CMD 차이
언제든지 말씀해 주세요!
기여자가 있는 경우
동우님, GitHub 화면 잘 봤습니다.
오른쪽에 Contributors(기여자)가 2명으로 표시되어 있는 이유는 당황스러울 수 있지만, 대부분 정상적인 현상이며 실제로 다른 사람이 동우님 프로젝트 코드를 고쳤다는 의미는 아닙니다.
아주 정확하게 설명드릴게요.
✔ 결론: 저 사람은 “동우님의 저장소를 Fork 또는 Pull Request로 관찰만 한 사람”일 가능성이 매우 큽니다
즉,
- 동우님 코드에 승인된 수정이나 커밋은 전혀 없음
- 실제 저장소에는 동우님 본인만 권한을 가진 상태
- 저 기여자는 소스코드에 한 줄도 반영하지 못함
입니다.
✔ GitHub의 “Contributors”가 무엇인지 정확하게 설명
GitHub의 Contributors(기여자) 목록은 다음을 포함합니다:
- 직접 커밋한 사람
- Pull Request를 열었지만 merge되지 않은 사람도 포함될 수 있음
- Fork 후 자신의 Fork에서 수정한 사람도 Contributors 카운트에 표시될 수 있음
(GitHub의 통계적 이유로)
즉, 해당 사람(shubhz2294)은:
- 동우님의 저장소를 Fork 했거나
- Pull Request를 시도했거나
- 단순히 GitHub에서 통계적으로 감지된 것일 수 있습니다.
하지만 동우님의 실제 코드에는 반영된 것이 없습니다.
✔ “진짜 코드 수정이 있었는지” 확인하는 방법(중요)
방법 1) GitHub Desktop → History 탭
여기에는 **동우님 계정(okloki)**이 만든 커밋만 나옵니다.
다른 사람 이름으로 된 커밋이 단 1개라도 있으면 바로 확인됩니다.
방법 2) GitHub 웹사이트 → 코드 탭 → 왼쪽 상단 Commits 클릭
경로:
Code → main 브랜치 → Commits
여기에는:
- 누가
- 언제
- 어떤 커밋을 했는지
모두 나옵니다.
동우님 화면에서 보면 199 commits라고 뜨는데,
이 안에 shubhz2294 이름이 있는지 확인해보면 됩니다.
제가 보기엔 99.9% 없는 상태일 것입니다.
✔ 그런 사람이 왜 Contributors에 보일까?
GitHub는 Contributors 정의를 다음과 같이 넓게 잡습니다:
- 저장소를 Fork만 해도 Contributors로 잡힐 수 있음
- PR(병합되지 않아도) 열기만 해도 잡힘
- 특정 파일을 GitHub에서 열어 “프로젝트에 참여 활성화”를 하면 집계됨
즉, 내 코드 수정과는 아무 상관이 없이 Contributors로 들어올 수 있습니다.
✔ “혹시 내 코드에 이상한 수정이 들어간 건 아닌가?”
→ 아니라고 봐도 됩니다.
GitHub Desktop과 GitHub 웹에서 커밋 로그만 확인하면 바로 알 수 있습니다.
필요하시면 커밋 로그 화면 캡처해주시면
제가 바로 분석해서 말씀드릴게요.
✔ 특별 조치가 필요한가?
필요 없습니다.
- 저장소는 Public → 누군가 Fork하면 자동으로 Contributors 잡힐 수 있음
- Private 저장소로 바꾸면 아예 없어짐(필요하면 방법 알려드림)
✔ 동우님이 확인을 원하시면
원하시면 제가 대신 확인해드릴 수 있게, 아래 화면만 보여주세요:
1) GitHub 코드 페이지에서 Commits 클릭한 화면
혹은
2) GitHub Desktop → History 화면
두 화면 중 하나만 캡처해서 보내주시면
“실제로 코드 수정이 있었는지” 명확히 알려드릴게요.
걱정되시는 마음 이해하고 있어요.
필요하면 바로 확인해드릴게요.
다른 사람 아이디로 등록 되는 문제 개선
아래 아이디는 제 아이디니 사용자가 아이디 넣어야 합니
좋은 포인트 짚으셨어요.
“옵션에서 분명 oklokl + noreply 로 바꿨는데도, 새 커밋이 또 shubhz2294 로 찍힌다”면, 거의 확실하게 Git 로컬 설정이 한 번 더 겹쳐 있어서(global 말고 ‘현재 저장소용 설정’이 따로 있어서) 거기가 계속 덮어쓰는 상황입니다.
해킹보다는 Git 설정 우선순위 문제일 가능성이 훨씬 높습니다.
Git 설정은 이렇게 세 단계가 있어요:
- 시스템 전체(system)
- 내 계정 전체(global) ← GitHub Desktop에서 방금 수정한 부분
- 저장소별(local) ← 이게 있으면 global 값을 덮어씀
지금은 3번(local)이 예전에 shubhz2294 로 저장돼 있어서,
global 값을 잘 바꿔도 해당 저장소에서는 여전히 local 값이 쓰이고 있는 상태일 가능성이 큽니다.
그래서 현재 저장소의 local 설정을 직접 덮어써 주면 문제를 잡을 수 있습니다.
1. 현재 저장소 로컬 설정을 직접 바꾸기
- GitHub Desktop에서 해당 저장소 선택 (odds-and-ends)
- 상단 메뉴에서
Repository → Open in Command Prompt 클릭 - 열린 창에서 아래 두 줄을 그대로 입력하세요:
git config user.name "oklokl"
git config user.email "1571600+oklokl@users.noreply.github.com"
이렇게 하면 이 저장소의 .git/config 안에 있는 user.name / user.email 을 직접 덮어씁니다.
(혹시 이름을 krdondon으로 쓰고 싶으시면 oklokl 대신 "krdondon" 으로 바꾸셔도 됩니다.
중요한 건 email이 noreply 주소인 것입니다.)
2. 제대로 적용됐는지 간단히 확인
같은 창에서:
git config user.name
git config user.email
을 차례대로 입력했을 때,
- oklokl (또는 krdondon)
- 1571600+oklokl@users.noreply.github.com
이렇게 나오면 성공입니다.
3. 테스트 커밋 한 번만 해보기
- 작은 텍스트 파일 하나 수정해서 저장 (예: 메모 파일 한 줄 추가)
- GitHub Desktop에서 그 변경을 Commit + Push
- GitHub 웹사이트 → 저장소 → Commits 들어가서 맨 위 커밋을 확인
이제 맨 위 커밋이:
- oklokl committed (또는 Name에 적은 krdondon) 로 보이면 완전히 해결된 겁니다.
(기존 예전 커밋들은 그대로 shubhz2294 로 남고, 새로 만드는 커밋부터 바뀐다는 점만 기억해 주세요.)
4. 추가로 확인해볼 수 있는 두 가지
- Commits 화면 오른쪽 위에 기여자 필터가 있습니다.
거기가 shubhz2294로만 필터링되어 있으면,
oklokl 커밋이 있어도 안 보입니다.
→ 꼭 “All contributors” 또는 “oklokl” 로도 한 번 바꿔서 확인해 보세요. - Personal access token(PAT)은 이 문제와 상관 없습니다.
토큰은 “로그인 열쇠” 역할만 하고,
“커밋 작성자 이름”은 오로지 git config 값으로만 결정됩니다.
요약하면:
- 해킹 가능성보다는 저장소별(local) Git 설정이 옛날 값으로 남아 있는 상황일 확률이 매우 높고,
- 위에서 안내한 git config user.name / user.email 두 줄을 저장소 안에서 직접 실행해 주시면
- 지금 이후로 커밋은 전부 oklokl(또는 krdondon) 이름으로 정상 기록됩니다.
위 명령까지 해보시고, 새 커밋 하나 만든 뒤 커밋 목록 캡처를 다시 보내주시면
그 결과를 보고 “완전히 정상화되었는지” 한 번 더 같이 확인해 드리겠습니다.
