Git 기본 작업 가이드

원격 저장소의 특정 브랜치를 로컬로 가져오기 (로컬에 없는 브랜치)

git checkout -b localBranchName origin/remoteBranchName

만약 오류 메시지가 나타난다면:

fatal: Cannot update paths and switch to branch 'newBranch' at the same time.
Did you intend to checkout 'origin/newBranch' which can not be resolved as commit?

먼저 다음 명령어를 실행해야 합니다:

git fetch

그 후 다시 시도해보세요:

git checkout -b localBranchName origin/remoteBranchName

로컬에서 새로운 브랜치를 체크아웃하고 원격 저장소에 푸시하기

새 브랜치 생성, 자동으로 해당 브랜치로 전환됩니다.

git checkout -b newBranchName

원격 저장소에 새 브랜치를 푸시합니다. 현재 브랜치가 새 브랜치임을 확인하세요.

git push --set-upstream origin branchName

cherry-pick 사용법

cherry-pick은 A 브랜치의 특정 커밋을 B 브랜치로 이동시키는 기능입니다.

기본 사용법

먼저 B 브랜치로 전환합니다.
git checkout -b targetBranch

지정한 커밋 commitHash를 현재 브랜치에 적용합니다.
git cherry-pick <commitHash>

만약 git cherry-pick 명령어의 인수가 브랜치 이름이라면, 그 브랜치의 가장 최근 커밋을 현재 브랜치로 옮깁니다.
git cherry-pick featureBranch

여러 커밋 이동

X와 Y 두 개의 커밋을 현재 브랜치로 이동시킵니다.

git cherry-pick <HashX> <HashY>

연속된 커밋 범위 X(포함되지 않음)부터 Y(포함됨)까지를 이동하려면 다음과 같이 입력합니다.

git cherry-pick <HashX>..<HashY>

X를 포함하려면 아래 문법을 사용합니다.

git cherry-pick X^..Y

코드 충돌

충돌 발생 시 Cherry pick 과정이 중단되며, 사용자가 어떻게 진행할지를 결정해야 합니다.

(1)--continue

코드 충돌 해결 후, 수정된 파일을 스테이징 영역에 추가(git add .)하고 다음 명령어로 Cherry pick 과정을 계속합니다.

$ git cherry-pick --continue

(2)--abort

충돌 발생 시 합병을 취소하고 이전 상태로 돌아갑니다.

(3)--quit

Cherry pick을 종료하지만 이전 상태로 되돌리지는 않습니다.

rebase 사용법

여러 커밋을 하나로 병합

git rebase -i startCommit endCommit

  • -i--interactive를 의미하며, 사용자에게 병합 작업을 위한 대화형 인터페이스를 제공합니다.
  • 시작과 끝 커밋은 왼쪽 열린 구간(start, end]으로 정의됩니다. 끝 커밋은 포함되지만 시작 커밋은 포함되지 않습니다.

예를 들어 A->B->C->D 순서의 커밋이 있을 때, B->C->D를 하나로 병합하려면 다음과 같이 합니다:

git rebase -i A D

다음과 같은 화면이 나타납니다:

각 커밋 앞에 pick이라는 단어가 표시되며, 이를 변경하여 다양한 작업을 수행할 수 있습니다:

pick:커밋 유지 (축약:p)
reword:커밋은 유지하나 메시지를 수정 (축약:r)
edit:커밋 유지하나 내용 수정 필요 (축약:e)
squash:현재 커밋을 이전 커밋과 병합 (축약:s)
fixup:현재 커밋을 이전 커밋과 병합하나 메시지는 유지하지 않음 (축약:f)
exec:shell 명령어 실행 (축약:x)
drop:커밋 삭제 (축약:d)

B 커밋은 pick, C와 D 커밋은 squash로 설정하여 병합합니다.

버전 롤백

먼저 원하는 버전의 커밋 ID를 확인합니다:

git log

특정 버전으로 롤백:

git reset --hard commitId

빠른 롤백 명령어:

git reset --hard HEAD^  # 이전 버전
git reset --hard HEAD^^  # 이전 이전 버전

로컬 저장소를 원격 저장소와 동일하게 만듬 (원격 강제 덮어쓰기)

git fetch origin  # origin에서 객체와 참조 다운로드
git reset --hard origin/main  # 현재 HEAD를 원격 브랜치의 것으로 재설정합니다. 주의: 이 명령어는 모든 로컬 변경사항을 삭제합니다.

최근 커밋 메시지 수정

git commit --amend

추적되지 않는 파일 삭제

# 추적되지 않는 파일 삭제
git clean -f

# 추적되지 않는 디렉토리도 함께 삭제
git clean -fd

# .gitignore에 정의된 파일도 삭제 (주의: 컴파일된 .o 파일 등을 제거하는 데 사용됩니다.)
git clean -xfd

# 위 명령어 실행 전에 삭제될 파일 목록을 미리 확인
git clean -nxfd
git clean -nf
git clean -nfd

브랜치 삭제

git branch -d branchToDelete

Oh My Zsh에서 Git 속도 저하 문제

Oh My Zsh가 Git 업데이트 정보를 가져오면서 발생하는 문제입니다.

해결 방법:

Git 프로젝트 디렉토리에서 다음 명령어를 실행하여 파일 변화 정보를 읽지 않도록 설정합니다:

git config --add oh-my-zsh.hide-dirty 1

더 느릴 경우 Git 정보를 전혀 읽지 않도록 설정:

git config --add oh-my-zsh.hide-status 1

원래대로 되돌리려면 값을 0으로 설정하면 됩니다.

프록시 설정

전역 프록시 설정

# 프록시 설정
git config --global http.proxy "http://proxy_url"
git config --global https.proxy "https://proxy_url"
# 프록시 설정 해제
git config --global --unset http.proxy
git config --global --unset https.proxy

개별 프록시 설정

# clone 시 프록시 설정
git clone --config http.proxy="http://proxy_url" https://github.com/example/repo.git

로컬에 원격 주소 추가

git clone 이후 원격 정보가 자동으로 추가되며, git config -l 명령어로 확인 가능합니다:

$ git config -l
# 기본 원격 이름은 origin
remote.origin.url=https://github.com/example/repo.git
# 기본 master 브랜치는 origin에 연결
branch.master.remote=origin

다른 원격 주소를 추가하려면 git remote add customRemoteName remoteURL 명령어를 사용합니다:

git remote add customOrigin git@custom.dev.sh.example.com:user/repo.git

추가 후 다시 확인:

$ git config -l
# 기본 원격 이름은 origin
remote.origin.url=https://github.com/example/repo.git
# 기본 master 브랜치는 origin에 연결
branch.master.remote=origin
# 새로 추가된 원격 이름은 customOrigin
remote.customOrigin.url=git@custom.dev.sh.example.com:user/repo.git

이렇게 하면 GitHub에서 코드를 가져와 GitLab에 푸시하는 등의 작업을 수동으로 할 수 있습니다.

GIT PUSH 시 "MERGE BRANCH 'MAIN' OF ..." 메시지 방지

로컬 브랜치가 원격 브랜치보다 뒤처져 있는 경우:

  1. 로컬에 다른 커밋이 없다면 fast-forward 모드로 pull하면 병합 노드 없이 간단히 업데이트됩니다.
  2. 로컬에 커밋이 있고 pull을 시도하면 병합 노드가 생깁니다.

이를 피하려면 git pull --rebase를 사용하면 됩니다. 충돌이 없으면 리베이스가 자동으로 이루어지고, 충돌이 있으면 수동으로 해결해야 합니다.

태그: Git VersionControl SystemManagement

6월 24일 04:19에 게시됨