1. OS별 Git 설치 방법

먼저 각 운영체제에 맞는 설치 방법을 확인했다.

Windows

윈도우의 경우 공식 홈페이지에서 설치 파일을 다운로드해야 한다.

• Git 공식 홈페이지에서 다운로드 후 설치를 진행한다.
• 설치 완료 후 Git Bash를 실행하여 사용한다.

macOS

맥 사용자는 Homebrew를 이용하면 간편하게 설치할 수 있다.

brew install git

Linux

리눅스 배포판에 따라 명령어가 다르다.

# Debian/Ubuntu 계열
sudo apt-get install git

# CentOS/RHEL 계열
sudo yum install git

2. Git 초기 설정 (User Config)

Git을 설치한 후 가장 먼저 해야 할 일은 사용자 정보를 등록하는 것이었다. 이 정보는 커밋할 때 기록되므로 정확하게 입력해야 한다.

git config --global user.name "사용자명"
git config --global user.email "이메일@example.com"
git config --global core.editor "code --wait"  # VS Code를 기본 에디터로 설정

설정이 제대로 들어갔는지 확인하고 싶다면 아래 명령어를 사용한다.

git config --list

3. 프로젝트 시작과 기본 명령어 흐름

프로젝트를 시작하고 코드를 저장소에 올리는 기본적인 흐름은 다음과 같았다.

저장소 생성 및 가져오기

• git init: 현재 폴더를 Git 저장소로 초기화한다.
• git clone <URL>: 원격 저장소(GitHub 등)에 있는 코드를 내 컴퓨터로 복제해 온다.

파일 상태 확인 및 커밋

작업을 진행하면서 가장 많이 사용하게 되는 명령어들이다.

• git status: 어떤 파일이 수정되었고, 스테이징 되었는지 상태를 확인한다.
• git add 파일명: 특정 파일을 스테이징 영역에 올린다. (git add .을 사용하면 모든 변경 파일을 한 번에 올릴 수 있다.)
• git commit -m "메시지": 스테이징 된 파일들을 확정하여 이력을 남긴다.
• git log: 지금까지의 커밋 기록을 확인한다.

4. 협업을 위한 브랜치(Branch) 관리

혼자 개발할 때는 메인 브랜치만 써도 무방하지만, 협업을 위해서는 기능별로 브랜치를 나누는 것이 필수였다.

• git branch 브랜치명: 새로운 브랜치를 생성한다.
• git checkout 브랜치명: 작업할 브랜치로 이동한다.
• git checkout -b 브랜치명: 브랜치를 생성함과 동시에 그곳으로 이동한다. (가장 많이 쓴다.)
• git branch: 현재 존재하는 브랜치 목록을 확인한다.
• git merge 브랜치명: 다른 브랜치의 작업 내용을 현재 브랜치로 합친다. (주로 main으로 이동 후 사용)

5. 원격 저장소 연결과 업로드

로컬에서 작업한 내용을 GitHub 같은 원격 저장소에 올리는 과정이다.

초기화 후 GitHub 업로드 순서

프로젝트를 처음 만들어서 올릴 때는 보통 아래 순서를 따른다.

cd 프로젝트폴더
git init
git add .
git commit -m "프로젝트 초기 커밋"
git branch -M main
git remote add origin <저장소URL>
git push -u origin main

평소 작업 시 Push와 Pull

• git push origin 브랜치명: 내 작업 내용을 원격 저장소에 올린다.
• git pull origin 브랜치명: 원격 저장소의 최신 내용을 내 컴퓨터로 내려받는다.

6. .gitignore 설정하기

개발을 하다 보면 빌드 파일이나 개인 설정 파일처럼 Git에 올리면 안 되는 파일들이 생긴다. 이를 관리하기 위해 .gitignore 파일을 작성하는 법을 익혔다.

프로젝트 루트 경로에 .gitignore 파일을 생성하고, 제외할 파일이나 폴더 패턴을 적으면 된다.

작성 예시

# 빌드 결과물 제외
/dist
/build

# IDE 설정 파일 제외
.vscode/
.idea/

# 운영체제 생성 파일 제외
.DS_Store
Thumbs.db

# 특정 확장자 전체 제외
*.log

이미 추적 중인 파일 제외하기

이미 Git에 한 번 커밋된 파일은 .gitignore에 추가해도 계속 추적된다. 이때는 캐시를 지워줘야 한다.

git rm --cached .DS_Store
git commit -m "Stop tracking .DS_Store"

7. 그 외 유용한 명령어 모음

마지막으로 자주 쓰지는 않지만 알아두면 편리한 명령어들을 정리했다.

• git diff: 변경된 코드의 차이점을 상세히 비교한다.
• git stash: 현재 작업 중인 내용을 임시로 저장해 둔다. (브랜치 이동 시 유용)
• git stash pop: 임시 저장했던 작업을 다시 불러온다.
• git clean -fd: Git이 추적하지 않는 파일들(Untracked files)을 강제로 삭제한다.
• git log --oneline: 커밋 로그를 한 줄씩 간결하게 보여준다.

개발을 진행하던 중 커밋을 잘못 등록하는 실수를 했고, 흔히 알려진 대로 터미널에 git reset HEAD^를 입력했다. 그런데 예상과 달리 실행은 되지 않고, 뜬금없이 more?라는 문구만 출력된 채 커서가 깜빡거리는 현상이 발생했다.

오늘은 이 more? 문구가 왜 뜨는지(나도 그랬다...)에 대한 원인과 해결 방법,

그리고 상황에 맞춰 안전하게 커밋을 취소하는 세 가지 리셋(Reset) 전략에 대해 정리해 보았다.

1. 상황별 리셋 전략: Soft vs Mixed vs Hard

단순히 HEAD^로 돌아가는 것 외에, 특정 시점(로그상의 eb2e173...)으로 돌아가고 싶을 때 작업 내용을 어떻게 처리할지에 따라 전략을 달리해야 함을 알게 되었다.

로그를 확인해보니 돌아가야 할 타겟 커밋은 eb2e17368bad6e1670f341955c83c694d7266035였다. 이 시점으로 리셋할 때 선택할 수 있는 세 가지 옵션을 정리해 보았다.

방법 A: 작업 내용은 살리고 커밋만 취소 (Soft Reset)

가장 권장되는 방식이다. 커밋 이력만 삭제되고, 작업했던 파일들은 'Staging(스테이징)' 상태로 안전하게 남는다.

• 용도: 방금 올린 커밋에서 오타를 수정하거나 파일을 조금 더 추가해서 다시 커밋하고 싶을 때 적합하다.

git reset --soft eb2e173(id)

방법 B: 작업 내용은 살리되 언스테이징 상태로 (Mixed Reset)

옵션을 안 붙였을 때의 기본값이다. 커밋은 취소되고 작업물은 남지만, git add를 다시 해줘야 하는 'Unstaged' 상태가 된다.

# 기본이 mixed다
1. git reset eb2e173(id)

2. git reset --mixed eb2e173(id)

방법 C: 작업 내용까지 완전히 삭제 (Hard Reset)

가장 주의해야 하는 방식이다. 타겟 시점 이후의 모든 작업 내용과 코드를 깔끔하게 날려버린다. 복구가 불가하다고 생각해라...

git reset --hard eb2e173(id)

2. 윈도우에서 git reset HEAD^ 실행 시 more?가 뜨는 이유

명령어를 입력했을 때 진행이 안 되고 more?가 떴던 이유는 내가 사용 중인 윈도우 CMD(명령 프롬프트) 환경의 특성 때문이었다.

Git이나 리눅스 환경과 달리, 윈도우 CMD에서 ^ (Caret, 캐럿) 기호는 탈출 문자(Escape Character)로 사용된다.

즉, 명령어 끝에 ^를 입력하고 엔터를 누르면 시스템은 이를 "명령어가 아직 끝나지 않았고 다음 줄에 입력할 내용이 더 있다"라고 인식한다. 그래서 사용자에게 추가 입력을 요구하며 more?라는 메시지를 띄우는 것이었다.

이 상태에서 빠져나오려면 당황하지 말고 Ctrl + C를 눌러 명령을 취소하면 된다.

3. more? 오류를 피해서 명령어를 입력하는 방법

이 문제를 해결하고 의도했던 대로 "가장 최신 커밋 하나를 취소"하기 위해서는 윈도우 터미널이 ^를 특수 문자로 인식하지 못하게 하거나, 다른 방식으로 표현해야 했다. 해결책은 다음 세 가지가 있었다.

방법 1: 따옴표 사용 (가장 권장)

^ 문자가 시스템 명령어(탈출 문자)로 해석되지 않도록 따옴표(" ")로 감싸주는 방법이다.

git reset "HEAD^"

방법 2: ~ (Tilde) 사용

^ 대신 ~ 기호를 사용하는 방법이다. 여기서 뒤의 숫자 1은 되돌릴 커밋의 개수를 의미한다.

git reset HEAD~1

방법 3: 꺽쇠 두 번 사용

CMD의 특성을 역이용하여 ^를 두 번 입력하면 문자 그대로 하나로 인식된다.

git reset HEAD^^

4. git reset HEAD^의 정확한 의미와 동작 원리

명령어가 제대로 실행된다면 어떤 일이 일어나는지도 명확히 짚고 넘어갈 필요가 있었다.

• HEAD: 현재 내가 위치한 브랜치의 가장 최신 커밋을 가리킨다.
• ^ (Caret): '바로 이전'을 의미한다. 즉 HEAD^는 최신 커밋의 바로 전 단계 조상을 뜻한다.
• 기본 동작 (Mixed Reset): 별도의 옵션 없이 git reset을 사용하면 기본적으로 -mixed 모드로 작동한다. 이는 커밋 이력은 삭제되지만, 해당 커밋에서 수정했던 파일 내용들은 지워지지 않고 내 작업 디렉토리에 'Unstaged(변경 사항)' 상태로 남는다는 것을 의미한다.

5. 리셋 실행 후 확인 절차

리셋을 수행한 뒤에는 반드시 상태가 의도대로 변경되었는지 확인하는 습관을 들여야 했다.

1. 명령어 실행: 위에서 결정한 방식(나의 경우 작업 보존을 위해 Soft Reset 선택)으로 명령어를 입력한다.
2. 상태 확인 (git status):
   • Soft Reset을 했다면 파일들이 초록색(Staged)으로 표시되어야 한다.
   • Hard Reset을 했다면 working tree clean이라는 메시지가 뜬다.
3. 로그 확인 (git log):
   • git log --oneline -n 5를 입력하여 현재 HEAD가 의도했던 eb2e173 커밋을 가리키고 있는지 최종 점검한다.

마무리

결과적으로 나의 상황은 원격 저장소(origin/myBranch)와 로컬의 싱크를 맞추면서, 실수로 올린 파일(docker 및 cursor rule)은 유지해야 했기에 Soft Reset이 가장 안전한 선택이었다.

윈도우 터미널에서 more?가 떴을 때는 당황하지 말고 따옴표를 기억하면 된다.

또한 리셋을 할 때는 내가 작업한 코드를 날릴 것인지 살릴 것인지를 먼저 판단하고 --soft와 --hard 옵션을 신중하게 선택해야 한다는 점을 다시금 확인했다.