[멋사] git 공부

밥슌·2025년 2월 11일

🐈‍⬛github

목록 보기

12/12

✅루트 디렉토리 설정

~(틸드) 기호는 사용자의 홈 디렉토리를 나타내는데, 현재 Git Bash에서 루트 디렉토리를 /c/Users/parks로 변경했음에도 불구하고 ~가 그대로 /c/Users/parks를 가리키지 않음

이 문제를 해결하려면 Git Bash의 홈 디렉토리를 확실하게 /c/Users/parks로 설정.

🔧 해결 방법: Git Bash의 홈 디렉토리 변경
방법 1: Windows 환경 변수 수정 (권장)
Windows 키 + R을 눌러 실행 창을 열고 sysdm.cpl 입력 후 엔터.
고급 탭으로 이동 → 환경 변수(N)... 클릭.
사용자 변수에서 HOME이라는 변수가 있는지 확인하고 없으면 추가.
새로 만들기(N)... 버튼 클릭하고 다음 값 입력:
변수 이름: HOME
변수 값: C:\Users\parks
확인을 눌러 저장하고 시스템을 재시작하거나 Git Bash를 다시 실행.

🎯 적용 결과

이제 Git Bash를 실행했을 때, 프롬프트가 /c/Users/parks가 아닌 ~로 표시될 거야!
즉, 현재 디렉토리가 /c/Users/parks라면 pwd 명령어를 실행해도 ~로 표시.

✅ 기존 저장소의 `master` 브랜치를 `main`으로 변경하는 방법

이미 생성된 저장소에서 master 브랜치를 main으로 바꾸려면 다음 명령어를 실행.

git branch -m master main

💡 실행 결과

master 브랜치의 이름이 main으로 변경됨.
이후 git branch를 실행하면 main 브랜치가 표시.

🛠️ 추가 설정 (GitHub 원격 저장소까지 반영)

만약 로컬에서 브랜치 이름을 변경한 후 GitHub 원격 저장소에도 반영하려면 다음 단계를 따라해야 함.

기존 master 브랜치를 main으로 변경
```
git branch -m master main
```
GitHub 원격 저장소에도 main 브랜치로 푸시
```
git push -u origin main
```
GitHub에서 기본 브랜치를 main으로 변경
- GitHub 리포지토리로 가서 Settings → Branches → Default branch에서 main으로 변경.
이전 master 브랜치 삭제 (선택 사항)
```
git push origin --delete master
```

📌 결론

git config --global init.defaultBranch main 명령어는 새로운 저장소를 만들 때만 적용됨.
기존 저장소의 master 브랜치를 main으로 바꾸려면 git branch -m master main을 사용해야 함.
GitHub에도 반영하려면 git push -u origin main 후 GitHub에서 기본 브랜치를 변경해야 함.

이제 master가 아닌 main 브랜치를 사용할 수 있음! 🚀

git checkout -b docs와 git switch -c docs는 새로운 브랜치를 생성하고 해당 브랜치로 전환하는 명령어입니다. 두 명령어 모두 같은 기능을 수행하지만, 사용 목적과 명령어의 역사적인 배경에서 차이가 있습니다.

🚀 차이점 요약

구분	`git checkout -b docs`	`git switch -c docs`
기능	브랜치 생성 + 전환	브랜치 생성 + 전환
목적	브랜치 전환 + 파일 복원 등 다기능	브랜치 전환 전용
버전 호환성	모든 Git 버전에서 사용 가능	Git 2.23 이상부터 사용 가능
가독성	상대적으로 복잡	직관적이고 간결

✅ 언제 사용해야 할까?

브런치 간의 이동: git switch 사용 추천 (가독성이 좋고 명확함).
커밋 간의 이동(파일 복원): git checkout 사용 추천.

📦 -r 명령어 간단한 비유로 이해하기

파일 복사: 한 개의 상자(파일)만 복사하면 간단합니다.
폴더 복사: 상자 안에 또 다른 상자(폴더 안에 하위 폴더)가 있으면, 그 안까지 전부 복사해야 하죠.
이때, "재귀적으로 모든 하위 폴더와 파일까지 복사하라고 지시하는 것이 바로 -r 옵션입니다."

✅ Fast-Forward 병합의 개념

조건: 병합 대상 브랜치(docs)가 현재 브랜치(main)의 직후 커밋에 이어져 있을 때 발생합니다.
동작 방식: main 브랜치가 docs 브랜치의 최신 커밋을 가리키도록 포인터만 앞으로 이동합니다.
결과: 새로운 병합 커밋이 생성되지 않으며, 더 깔끔한 커밋 히스토리를 유지할 수 있습니다.

✅ `git remote -v`에서 `-v`의 의미

-v는 verbose(상세한 정보 출력)의 약자입니다.

기본 명령어:
```
git remote
```
이 명령어는 등록된 원격 저장소(remote)의 이름만 보여줍니다.

상세 정보 출력:

git remote -v

-v 옵션을 추가하면 원격 저장소의 URL 정보까지 함께 표시됩니다.

origin  https://github.com/user/repo.git (fetch)
origin  https://github.com/user/repo.git (push)

✅ `git remote update`란?

git remote update 명령어는 원격 저장소(remote)의 최신 상태를 로컬 저장소로 가져오는 명령어입니다.
이는 원격 브랜치의 변경 사항(새로운 커밋, 브랜치 생성/삭제 등)을 로컬에 동기화하는 역할을 합니다.

🚀 기본 동작

git remote update

원격 저장소의 모든 변경 사항을 로컬에 가져옵니다.
하지만 현재 작업 중인 브랜치에는 영향을 주지 않습니다.
(즉, git pull처럼 자동 병합이 일어나지 않음)

📊 실제 예제

1️⃣ 상황 가정:

원격 저장소(origin)에 새로운 브랜치 feature/new가 추가됨.
로컬 저장소에는 이 변경 사항이 반영되지 않은 상태.

2️⃣ `git remote update` 실행:

git remote update

결과: 로컬의 원격 브랜치 목록이 최신 상태로 갱신됨.

3️⃣ 변경 사항 확인:

git branch -r

origin/feature/new 브랜치가 추가된 것을 확인할 수 있음.

🔍 `git pull`과의 차이점

구분	`git remote update`	`git pull`
기능	원격 저장소의 변경 사항을 가져오기만 함	가져온 변경 사항을 현재 브랜치에 병합
병합 여부	❌ 병합 없음 (안전)	✅ 자동 병합 수행
용도	원격 브랜치 상태 확인, 충돌 방지용	브랜치 최신화 및 동기화

📌 정리

git remote update = 원격 저장소의 최신 상태를 로컬로 가져오기 (병합 없음)
안전하게 원격 저장소의 변화를 확인할 때 유용
병합까지 하고 싶다면 git pull 사용

협업 시 충돌 방지를 위해 자주 사용하는 중요한 명령어입니다! 🚀

✅ 바로 이전 커밋 취소하는 방법

Git에서 이전 커밋을 취소하는 방법은 상황에 따라 다릅니다.
(커밋만 취소할지, 파일 변경 사항까지 취소할지) 선택할 수 있습니다.

🚀 1️⃣ 커밋만 취소하고 변경 사항은 유지하기

(= soft reset)

git reset --soft HEAD~1

의미: 바로 이전 커밋(HEAD~1)을 취소하지만, 변경된 파일은 그대로 작업 디렉토리에 남겨둠.
사용 상황: 메시지를 잘못 작성했거나 커밋만 되돌리고 싶을 때.

TIP: 이 상태에서 git commit --amend로 커밋 메시지를 수정할 수 있습니다.

🔥 2️⃣ 커밋과 변경 사항 모두 취소하기

(= hard reset)

git reset --hard HEAD~1

의미: 이전 커밋을 삭제하고, 그 커밋에서 변경된 내용도 모두 삭제됨.
사용 상황: 잘못된 파일을 커밋했는데 변경 사항 자체도 필요 없을 때.

⚠️ 주의: hard reset은 되돌리기 어렵기 때문에 중요한 작업은 꼭 백업하세요.

🗑️ 3️⃣ 커밋만 취소하고 변경 사항은 Staging에서 빼기

(= mixed reset, 기본값)

git reset HEAD~1

의미: 커밋은 취소하고, 파일은 Unstaged 상태로 돌아감.
사용 상황: 커밋은 취소하되, 변경 사항은 남기고 다시 커밋하거나 수정하고 싶을 때.

⏪ 4️⃣ 커밋을 되돌리는 방법 (Revert)

(= 안전한 방법)

git revert HEAD

의미: 이전 커밋을 "취소하는 새로운 커밋"을 생성함.
사용 상황: 이미 푸시한 커밋을 취소하고 싶을 때 협업 환경에서 안전하게 사용 가능.

✅ revert는 기존 커밋을 삭제하지 않고 히스토리를 유지하기 때문에 협업 시에 추천!

📌 상황별 선택 가이드

상황	명령어	설명
커밋만 취소, 변경 사항은 유지	`git reset --soft HEAD~1`	커밋 취소 후 수정 가능
커밋 + 변경 사항 모두 삭제	`git reset --hard HEAD~1`	완전히 삭제, 복구 어려움
커밋 취소, 변경 사항은 Unstage로 유지	`git reset HEAD~1`	커밋 취소 후 다시 커밋 가능
푸시한 커밋 안전하게 되돌리기	`git revert HEAD`	되돌리기 커밋 생성 (협업에 안전)

⚠️ 주의사항

git reset --hard는 복구가 어렵기 때문에 주의!
이미 원격 저장소에 푸시한 경우라면 git revert 사용이 안전합니다.

✅ `pull`과 `push`만으로 3-Way Merge 만들기

강사님이 main 브랜치만 사용하고 pull과 push로 병합 커밋을 만든 이유는 원격 저장소와의 충돌을 유도하여 자동으로 3-Way Merge가 발생하도록 한 것입니다.

이 방법은 주로 협업 상황이나 원격 저장소에서 변경 사항이 생긴 경우에 자연스럽게 발생합니다.

🚀 3-Way Merge를 만드는 과정 (main 브랜치만 사용)

1️⃣ 로컬 저장소의 변경 사항 커밋하기

# 새로운 내용 추가
echo "Git과 친해졌으면..." >> README.md
git add README.md
git commit -m "내친구 Git"

2️⃣ 로컬에서 `push` 하기 전에 원격 저장소에서 변경 사항 만들기

#또 다른 내용 추가(원격 저장소에)
echo "Git은 너무 어려워..." >> README.md
git add README.md
git commit -m "친구가 되고싶은 Git"

다른 환경(예: GitHub 웹 UI 또는 다른 컴퓨터)에서 main 브랜치에 새로운 커밋을 추가합니다.
예: Push, Pull 명령어라는 커밋 추가.

이제 로컬과 원격 저장소가 다른 상태가 됩니다.

3️⃣ 로컬에서 `push` 시도

git push origin main

❌ 결과: 오류 발생

! [rejected]        main -> main (non-fast-forward)
error: failed to push some refs to 'https://github.com/your-repo.git'
hint: Updates were rejected because the tip of your current branch is behind

이 오류는 로컬 브랜치가 원격보다 뒤처졌기 때문에 발생합니다.

4️⃣ 원격 저장소의 변경 사항을 `pull`로 병합하기

git pull origin main

이 과정에서 Git은 3-Way Merge를 자동으로 수행합니다.
변경 사항이 충돌하지 않으면 자동으로 병합 커밋이 생성됩니다.
충돌이 발생하면 수동으로 해결한 후 병합 커밋을 생성할 수 있습니다.

5️⃣ 최종적으로 다시 `push` 하기

git push origin main

이제 로컬과 원격 저장소가 모두 동기화됩니다.

📊 커밋 기록 결과

*   ccd20cb (main) Merge branch 'main' of https://github.com/seulbinim/learn-reset
|\
| * ab71da3 친구가 되고싶은 Git
| * ecf41ad 내친구 Git
* | 94bfca9 Push, Pull 명령어
|/
* 39f9fff 로컬, 리모트 저장소

Merge branch 'main'이라는 병합 커밋이 생성됩니다.

⚡ 정리

로컬에서 커밋 생성
원격 저장소에서 직접 커밋 추가 (또는 다른 사람이 푸시)
로컬에서 git push 시도 → 오류 발생
git pull로 병합 (3-Way Merge 자동 수행)
git push로 최종 푸시

❗ 팁

git pull 명령어는 내부적으로 git fetch + git merge를 수행합니다.
만약 병합 커밋을 반드시 만들고 싶다면:
```
git pull --no-ff
```

밥슌

마트 시식코너같은 저의 벨로그에 어서오세요.

이전 포스트

[멋사] git 공부

🐈‍⬛github

✅루트 디렉토리 설정

🎯 적용 결과

✅ 기존 저장소의 `master` 브랜치를 `main`으로 변경하는 방법

💡 실행 결과

🛠️ 추가 설정 (GitHub 원격 저장소까지 반영)

📌 결론

🚀 차이점 요약

✅ 언제 사용해야 할까?

📦 -r 명령어 간단한 비유로 이해하기

✅ Fast-Forward 병합의 개념

✅ `git remote -v`에서 `-v`의 의미

✅ `git remote update`란?

🚀 기본 동작

📊 실제 예제

1️⃣ 상황 가정:

2️⃣ `git remote update` 실행:

3️⃣ 변경 사항 확인:

🔍 `git pull`과의 차이점

📌 정리

✅ 바로 이전 커밋 취소하는 방법

🚀 1️⃣ 커밋만 취소하고 변경 사항은 유지하기

🔥 2️⃣ 커밋과 변경 사항 모두 취소하기

🗑️ 3️⃣ 커밋만 취소하고 변경 사항은 Staging에서 빼기

⏪ 4️⃣ 커밋을 되돌리는 방법 (Revert)

📌 상황별 선택 가이드

⚠️ 주의사항

✅ `pull`과 `push`만으로 3-Way Merge 만들기

🚀 3-Way Merge를 만드는 과정 (main 브랜치만 사용)

1️⃣ 로컬 저장소의 변경 사항 커밋하기

2️⃣ 로컬에서 `push` 하기 전에 원격 저장소에서 변경 사항 만들기

3️⃣ 로컬에서 `push` 시도

4️⃣ 원격 저장소의 변경 사항을 `pull`로 병합하기

5️⃣ 최종적으로 다시 `push` 하기

📊 커밋 기록 결과

⚡ 정리

❗ 팁

[git]코드가 안전하게 지켜지면서 원본 코드도 최신 상태로 유지

0개의 댓글

[멋사] git 공부

🐈‍⬛github

✅루트 디렉토리 설정

🎯 적용 결과

✅ 기존 저장소의 master 브랜치를 main으로 변경하는 방법

💡 실행 결과

🛠️ 추가 설정 (GitHub 원격 저장소까지 반영)

📌 결론

🚀 차이점 요약

✅ 언제 사용해야 할까?

📦 -r 명령어 간단한 비유로 이해하기

✅ Fast-Forward 병합의 개념

✅ git remote -v에서 -v의 의미

✅ git remote update란?

🚀 기본 동작

📊 실제 예제

1️⃣ 상황 가정:

2️⃣ git remote update 실행:

3️⃣ 변경 사항 확인:

🔍 git pull과의 차이점

📌 정리

✅ 바로 이전 커밋 취소하는 방법

🚀 1️⃣ 커밋만 취소하고 변경 사항은 유지하기

🔥 2️⃣ 커밋과 변경 사항 모두 취소하기

🗑️ 3️⃣ 커밋만 취소하고 변경 사항은 Staging에서 빼기

⏪ 4️⃣ 커밋을 되돌리는 방법 (Revert)

📌 상황별 선택 가이드

⚠️ 주의사항

✅ pull과 push만으로 3-Way Merge 만들기

🚀 3-Way Merge를 만드는 과정 (main 브랜치만 사용)

1️⃣ 로컬 저장소의 변경 사항 커밋하기

2️⃣ 로컬에서 push 하기 전에 원격 저장소에서 변경 사항 만들기

3️⃣ 로컬에서 push 시도

4️⃣ 원격 저장소의 변경 사항을 pull로 병합하기

5️⃣ 최종적으로 다시 push 하기

📊 커밋 기록 결과

⚡ 정리

❗ 팁

[git]코드가 안전하게 지켜지면서 원본 코드도 최신 상태로 유지

0개의 댓글

✅ 기존 저장소의 `master` 브랜치를 `main`으로 변경하는 방법

✅ `git remote -v`에서 `-v`의 의미

✅ `git remote update`란?

2️⃣ `git remote update` 실행:

🔍 `git pull`과의 차이점

✅ `pull`과 `push`만으로 3-Way Merge 만들기

2️⃣ 로컬에서 `push` 하기 전에 원격 저장소에서 변경 사항 만들기

3️⃣ 로컬에서 `push` 시도

4️⃣ 원격 저장소의 변경 사항을 `pull`로 병합하기

5️⃣ 최종적으로 다시 `push` 하기