헤깔리는 git 명령어 정리

너무 기초적이고 자주쓰이는 명령어는 제외하였고, 종종 쓰긴하지만 헤깔리는 git 명령어 + 옵션을 위주로 정리 하였다.

git init 등

git init

먼저, 새로운 저장소를 생성하는 명령어 이다. 저장소 정보가 담긴 .git 폴더가 생성이 된다.

일반적으로는 프로젝트 생성과 배포를 할때에 원격저장소와 연동을 해야 하기 때문에 아래와 같은 단계를 거친다.

프로젝트 생성 및 개발수행 -> git init 
-> github에서 repository 생성 
-> git remote add <원격저장소주소> 
-> git add . -> git commit -m "첫번째커밋"
-> git push origin main

또는 아래와 같이 원격저장소를 먼저 만든 다음에 git clone을 통해 원격저장소 주소와 정보가 모두 담긴 folder를 통째로 생성한 후 개발하여 배포하는 순서도 있을 수 있겠다.

github에서 repository 생성 
-> git clone <원격저장소주소> 
-> 프로젝트 생성 및 개발 수행 -> 배포

 

git add, commit 등

git commit
git add와 commit을 동시에 하고 싶다면 아래와 같은 명령어를 사용하면 된다.

git commit -am "커밋메시지"

단, tracked file 즉 수정 파일의 경우에만 add와 commit이 한꺼번에 가능함에 유의하자.

또한 만약 "git commit" 명령어만을 실행할 경우, vim모드로 커밋메시지를 작성할 수 있도록 전환이 되는데, 첫줄부터는 제목을 작성하고, 제목이 끝나는 지점에서 한줄 띄워진 부분부터 본문임을 기억하자.

git log
git log명령어는 커밋의 제목, 본문 등이 출력이 되는데, 커밋해시와 제목 등 간결하게 보고 싶다면 아래 명령어

git log --oneline

수정사항의 구체적인 내용까지 보고 싶을때는 git log --patch또는 아래와 같이 간단히 조회가능하다. 굳이 diff를 하지 않아도 되어 나는 자주 사용하는 편이다.

git log -p

git commit 취소
commit취소 -> staging 취소 -> 작업디렉토리(working directory) 취소 순서로 하나씩 살펴보자.

git reset HEAD^ : local저장소에 commit된 최신커밋취소
git reset HEAD~1 : 위와 동일한 명령어

<옵션>
--soft : staging은 남기고 reset
--mixed : 작업디렉터리는 남기고 reset
--hard : 작업디렉터리까지 전부 reset

옵션없이 git reset HEAD^만을 실행하면 default 옵션은 --mixed이다. 이때에는 staging에서는 취소가 됐지만, 작업디렉토리에 수정사항들은 그대로 남아 있을 것이다. reset이후 후속 취소처리를 보도록 하자.

git restore –staged .  : staging에 올린 사항 작업디렉토리로 원상복구
git checkout . && git clean –fdx  : 작업디렉토리에 변경 및 추가 사항 모두 원상복구
git restore . && git clean –fdx  : 작업디렉토리에 변경 및 추가 사항 모두 원상복구

기회가 되면, reset/revert 등 커밋 취소에 대해 자세히 설명하겠지만, local내에서는 reset을 자유롭게 쓰더라도, origin에 이미 배포된 상황이라면 reset은 지양하도록 하자.

git config 설정

git config —local user.email “hello@naver.com”
git config —local user.name "hello"

위의 name은 만든이/email이 누구인지를 지정하는 것이고, commit log와 협업하는 원격저장소로 push했을때 보여지는 이름이다. local은 현재 repo, global은 local을 별도로 지정하지 않은 모든 repo에 적용된다.

git config를 통해 여러가지 정보들을 설정할 수 있는데, 이 설정 정보들을 확인하는 명령어는 아래와 같다.

git config --list

 

git branch 생성/삭제 등

브랜치 생성과 사용

git branch 브랜치명 : 브랜치생성
git checkout 브랜치명 : 브랜치사용
git checkout -b 브랜치명 : 생성과 사용 동시

"git checkout 브랜치명" 과 같이 브랜치 전환에도 사용을 할 수 있지만, 아래와 같이 특정 커밋시점으로도 돌아갈 수 있다.

git checkout 특정commitID

만약 main브랜치에서 main브랜치의 특정 commit시점으로 전환 후에 다시 최신 커밋시점으로 돌아오고 싶다면,
"git checkout main"을 하면 된다.

브랜치 삭제

git branch -D 브랜치명 : 로컬브랜치삭제
git push origin --delete 브랜치명 : 리모트브랜치도 삭제

원격브랜치 정보를 로컬에 반영
만약, github UI에서 remote branch를 먼저 삭제하여, local보다 리모트가 먼저 삭제 됐다면, 원격브랜치 정보를 로컬에 반영해야 할 것이다.

git fetch -p origin : 실제 remote 서버의 branch 정보를 가져와 로컬 pc에 갱신

원격브랜치 정보 확인
리모트 브랜치 정보를 로컬에 반영한 뒤에, 아래 명령어를 통해 로컬에서 가지고 있는 원격브랜치 정보도 확인해보도록 하자.

git branch -r : 원격브랜치 정보 확인

git fetch 후 merge

git pull origin main을 할 경우엔 origin의 수정사항을 가져와 merge까지 수행 하게 되지만, git fetch는 수정사항만을 가져오게 된다.

git fetch origin 브랜치명

현재 checkout된 브랜치가 main브랜치이고 origin/main과 차이가 있다면 아래와 같은 상황이 벌어질 것이다.

위 그림을 보면, git fetch를 통해 가져온 origin main의 내용은 fetch_head라는 브랜치에 담기게 된다.

git diff fetch_head

위 diff 명령어를 통해 차이점을 확인한 후에 로컬저장소의 main에 merge하고 싶다면 아래 명령을 통해 merge를 시키면 되겠다.

git merge fetch_head

 

git tag

main브랜치에서 tag를 붙여 버전을 명시하고, release를 하고자 할때 아래와 같이 tag를 붙인뒤 push를 하면 된다. checkout된 branch기준으로 tag별 release가 생성이 된다.

git tag 버전명
git push origin 버전명

github으로 이동해보면, 해당 tag에는 최종 commit까지 tree가 만들어져 있고, release에는 source코드가 압축파일로 만들어져 있음도 알수 있을것이다.

 

git diff

git diff명령어는 가장 최신의 commit과 현재 작업디렉토리간의 차이를 확인하는 명령어이다. 이때 최신의 commit이 아닌 예전의 commit으로 checkout 하더라도 비교는 최신의 commit과 비교함에 유의하자.

git diff

마찬가지로 --staged옵션을 주면 최신의 commit기준으로 staging간의 차이를 출력한다.

git diff --staged

commit간의 차이는 아래와 같이 확인하면 되겠다.

git diff 커밋ID1 커밋ID2