[Git] Git 실무에서 자주 쓰는 상황과 명령어 조합

Git에서는 다양한 명령어의 기능을 제공하지만, 실제 업무에서 주로 사용하는 흐름이 어느정도 정해져 있습니다.

이번 글에서는 업무 중 자주 마주치는 상황을 중심으로, 어떤 명령어를 어떤 순서로 사용하면 좋을지 정리해보았습니다.

---

1. 새로운 기능 개발 브랜치 생성 및 작업 시작

새로운 기능을 개발할 때는, main 브랜치에서 분기하여 별도의 브랜치에서 작업하는 것이 일반적입니다.

git switch main
git pull origin main
git switch -c feature/login

작업 후에는 변경사항을 커밋하고 원격 저장소에 푸시합니다.

git add .
git commit -m "feat : 로그인 페이지 UI 구현"
git push origin feature/login

이후에는 Pull Request(PR) 을 생성하여 팀원들과 코드 리뷰를 진행합니다.

 

2. 마지막 커밋 수정

커밋 메시지를 잘못 입력했거나, 커밋에 빠트린 파일이 있는 경우 --amend 옵션을 사용하여 최근 커밋을 수정할 수 있습니다.

git add app.js
git commit --amend --no-edit

메시지를 함께 수정하고자 할 경우에는 아래와 같이 사용합니다.

git commit --amend

커밋을 이미 원격 저장소에 푸시한 경우에는 git push --force가 필요하므로, 협업 브랜치에서는 신중하게 사용해야 합니다.

 

3. 브랜치 전환 전 작업 임시 저장

작업 중이던 내용을 당장 커밋하기 어려운 상황에서 다른 브랜치로 전환해야 한다면, stash를 사용하여 임시 저장할 수 있습니다.

#현재 feature/login 브랜치에 있는 경우
git stash -u
git switch feature/category

작업 복원은 다음과 같이 할 수 있습니다.

git switch feature/login
git stash pop

stash -u 옵션을 사용하면, untracked 파일도 함께 저장됩니다.

 

4. 특정 커밋 되돌리기 (히스토리 유지)

이전에 잘못된 커밋이 포함되었지만, 커밋 이력을 보존하고 싶을 때는 revert 명령어를 사용합니다.

git log --online
git revert <커밋 해시>

revert 명령어를 사용하면 해당 커밋을 사용하는 반대 내용의 새 커밋이 “Revert …” 메시지와 함께 생성됩니다.

 

5. 실수로 작업 내용을 삭제했을 때 복구

reset --hard나 브랜치 삭제 등으로 작업 내용이 사라졌더라도, reflog를 통해 복구할 수 있습니다.

git reflog
git reset --hard HEAD@{2}

reflog는 HEAD의 이동 이력을 가지고 있기 때문에, 실수한 시점 이전으로 되돌릴 수 있습니다.

 

6. 특정 커밋만 다른 브랜치에 적용

기능 전체가 아닌, 특정 버그 수정 커밋만 다른 브랜치에 적용하고 싶을 때는, cherry-pick 명령어를 사용합니다.

git switch main
git cherry-pick <커밋 해시>

위의 예시에서는 main 브랜치에 특정 커밋만 반영하게 됩니다.

 

7. 병합 전에 최신 내용 반영

작업 중인 브랜치에 main 브랜치의 최신 내용을 병합하거나 재배치하려면, fetch와 함께 merge 또는 rebase 를 사용할 수 있습니다.

git fetch origin
git rebase origin/main

혹은 병합 커밋을 명시적으로 남기고 싶다면 다음과 같이 사용할 수 있습니다.

git merge origin/main --no-ff

팀의 Git 정책에 따라 merge 또는 rebase중 하나를 선택하여 사용하는 경우가 많습니다.

 

8. 삭제한 브랜치 복구

실수로 브랜치를 삭제했더라도, 최근 커밋을 기준으로 다시 복구할 수 있습니다.

git reflog
git checkout -b feature/login-restored HEAD@{3}

reflog에서 삭제되기 전 브랜치가 가리키던 커밋을 찾아, 새 브랜치로 복원할 수 있습니다.

 

9. 원격 저장소에 푸시한 커밋 취소하기

로컬에서는 문제가 없어 보여 원격 저장소에 커밋과 푸시까지 했지만, 커밋 메시지에 실수가 있거나, 잘못된 파일을 올렸다면 이미 푸시한 내용을 취소하고 원격 저장소 상태를 되돌려야 할 수 있습니다.

#취소할 커밋의 해시를 확인합니다.
git log --oneline

#커밋을 되돌린 뒤 강제 푸시합니다. 
git reset --hard HEAD^
git push origin master --force

이 방식으로 푸시했던 커밋이 원격 저장소에서도 제거됩니다.

push --force는 협업 중인 브랜치에서 사용하면, 다른 팀원의 작업에 영향을 줄 수 있으므로, 반드시 사전 협의가 필요합니다.

 

10. 잘못된 브랜치에 푸시했을 때, 되돌리기

개인 브랜치에서 작업하려던 내용을 main 이나 다른 공유 브랜치에 푸시한 경우 작업 내용을 따로 빼내고, 기존 브랜치의 상태는 복원하는 처리가 필요합니다.

#잘못 푸시한 커밋을 새 브랜치로 복사합니다. (ex. feature/login 브랜치의 경우)
git checkout -b feature/fix-dev-push

#원래 브랜치를 이전 상태로 되돌립니다.
git checkout developer
git reset --hard origin/developer
git push origin developer --force
#기존의 developer 브랜치는 작업 내용이 없는 상태로 되돌아갑니다.

#새 브랜치에서 작업을 이어나갑니다.
git switch feature/fix-dev-push

이 역시 강제 푸시가 포함되므로, 다른 팀원이 해당 브랜치를 pull 하기 전에 조치를 취하는 것이 중요합니다.

 

11. 원격 저장소에 잘못 올라간 민감한 파일 삭제하기

간혹가다 원격 저장소에 올라가면 안되는 파일이 실수로 커밋되어 원격 저장소에 푸시된 경우, 단순히 파일을 삭제하는 것만으로는 충분하지 않을 수 있습니다.

이런 경우에는 커밋 히스토리에서 해당 파일을 제거해야 하며, 작업 시 주의가 필요합니다.

 

파일 삭제 후 커밋

먼저 로컬 저장소에서 해당 파일을 삭제하고, 커밋합니다.

git rm .properties
git commit -m "chore : 잘못 올라간 파일 삭제"

필요 시 .gitignore에 추가해 이후 추적되지 않도록 처리합니다.

 

커밋 히스토리에서 파일 흔적 제거(필요한 경우)

파일 자체는 삭제했지만, 이전 커밋에 해당 파일 내용이 포함되어 있다면, 민감한 정보가 외부에 노출될 수 있으므로 커밋 히스토리에서 파일 흔적을 완전히 제거해야 합니다.

이때는 git filter-repo 또는 git filter-branch, BFG Repo-Cleaner 등의 도구를 사용합니다.
여기서는 최근 권장되는 git filter-repo를 예시로 사용합니다.

git filter-repo --path .properties --invert-paths

filter-repo는 로컬 Git 히스토리를 재작성하므로, 원격 저장소를 강제 푸시 해야합니다.
사용 전 전체 백업을 권장합니다.

 

강제 푸시로 반영

git push origin --force --all

원격 저장소에 반영하기 위해 강제 푸시가 필요합니다.

같은 브랜치에서 작업하는 다른 팀원에게 영향을 줄 수 있으므로, 작업 전 팀원과의 협의가 필요합니다.

 

이렇게 Github에 이미 올라간 민감한 정보는 Git 기록을 수정해도 완전히 제거되지 않을 수 있어, 아래의 문서를 참고하여 캐시 삭제 요청을 할 수 있습니다.

https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/removing-sensitive-data-from-a-repository

GitHub과 같이 클라우드 서버에서 관리되는 원격 저장소인 경우 민감한 정보가 포함된 파일은 단순히 삭제만 해서는 안되고, 이력에서 완전히 제거하는 작업이 필요합니다.

이런 상황을 예방하기 위해 .gitignore 파일을 관리하거나 pre-commit 훅 등을 사용하여 민감 파일이 커밋되지 않도록 차단할 수 있습니다.

 

12. pre-commit Hook을 이용하여 민감 파일 커밋 방지하기

Git 은 커밋 직전에 실행되는 pre-commit 훅을 제공하고 있습니다.

이 훅을 활용하면 커밋하기 전 자동으로 파일을 검사하여, 특정 조건에 맞지 않는 경우 커밋을 차단할 수 있습니다.

 

Git Hook 디렉터리 확인

Git 저장소에는 기본적으로 .git/hooks/ 디렉터리가 존재합니다.

여기에는 다양한 훅 스크립트가 샘플 형태로 존재하며, 이 중에 pre-commit.sample 파일을 사용합니다.

cd {your-project}/.git/hooks

 

pre-commit 훅 스크립트 작성

아래는 특정 파일 이름 혹은 패턴이 커밋 대상에 포함되었는지 검사하고, 포함되었을 경우 커밋을 막는 예시입니다.

.git/hooks/pre-commit 파일을 새로 만들거나 기존 샘플을 수정합니다.

#!/bin/sh

# 커밋 대상 파일 목록을 가져옵니다
FILES=$(git diff --cached --name-only)

# 금지할 파일 패턴 목록
BLOCKED_PATTERNS="\.env\|\.pem\|\.key\|secret\.json"

echo "$FILES" | grep -E "$BLOCKED_PATTERNS" > /dev/null

#패턴과 일치하는 파일이 있을 경우 exit 1 로 커밋을 중단합니다.
if [ $? -eq 0 ]; then
  echo "민감한 파일이 커밋 대상에 포함되어 있습니다."
  echo "해당 파일은 커밋하지 않도록 확인해주세요."
  exit 1
fi

exit 0

이렇게 작성한 훅 스크립트는 실행 권한을 부여해야 동작합니다.

chmod +x .git/hooks/pre-commit

이후 금지할 파일 패턴 목록과 일치하는 파일을 Staging 영역에 올려 커밋할 경우, 메시지를 남기며 커밋을 중단합니다.

.git/hooks 디렉터리는 Git 내부 디렉터리이므로, 다른사람과 공유되지 않습니다.

프로젝트 단위로 설정 파일을 관리하기 위해서는 pre-commit 프레임워크나 Husky 같은 도구를 이용하여 관리할 수 있습니다.