Git - 상황별 사용법 (2)

3 minute read

이전 포스트에 이어 Git 상황별 사용법에 대해서 계속 알아보겠습니다.



상황별 Git 명령어

#이전의 특정 커밋을 찾기 - git log –grep {pattern}

git log를 통해 커밋 이력을 확인할 수 있지만, 특정 문자가 포함된 커밋 이력을 찾아 확인할 수 있습니다.

$ git log --grep 'myGitTest 수정1'
# pattern 으로 지정한 문자가 이전 커밋에 포함되어 있는지 확인합니다.


#소스 강제로 push 하기 - git push -f

협업을 하는 git 소스는 사실상 강제로 push를 해서는 안되지만, 개인 개발 branch 대상으로 어쩔수 없이 강제로 push를 해야하는 경우가 발생할 수 있습니다. commit 이력을 관리하거나 잘못된 branch 이력을 삭제하기 위해 강제 push를 사용하기도 합니다.

$ git push -f origin feature/myGitTest
# 자신의 개발 branch에 수정된 소스를 강제로 push합니다.


#기존 commit 메시지를 수정하기 - git commit –amend

git commit -m ‘message’ 를 통해 기존에 commit 메시지를 작성했지만, 수정이 필요한 경우에는 amend 옵션을 사용하요 수정할 수 있습니다.

$ git commit --amend
# commit 메시지 수정화면에서 메시지 수정을 합니다.


#커밋 이력을 하나로 통합하기(스쿼시) - git rebase -i HEAD~

개발을 진행하다보면 습관적인 커밋 또는 버그로 인해 계속적으로 수정과 커밋을 반복해야하는 경우가 있습니다. 커밋 이력을 많이 남긴다고 나쁜것은 아닙니다. 하지만 branch의 커밋 이력을 깔끔하게 유지해야하는 특별한 상황이나 특정 branch에서는 커밋을 간결하게 유지할 필요가 있습니다. 이럴경우 기존 커밋 이력을 적게 유지하기 위해 기존 커밋을 하나로 합쳐 관리할 수 있습니다.

$ git log
# log 를 통해서 기존 커밋이력을 확인합니다.
# 최신 커밋이 맨 위쪽에 위치하며 아려쪽으로 내려갈수록 과거 커밋입니다.

$ git rebase -i HEAD~2
# ~2 은 현재 커밋의 이전 2개까지 범위를 의미합니다.
# log를 통해 확인한 커밋 이력중에서 통합이 필요한 커밋까지의
# 범위를 확인 후 통합을 진행합니다.


pick 9930132 feature/myGitTest
pick 9930131 feature/myGitTest

# Rebase f35d994..9930132 onto f35d994 (1 command)
#
# Commands:
# p, pick <commit> = use commit
# r, reword <commit> = use commit, but edit the commit message
# e, edit <commit> = use commit, but stop for amending
# s, squash <commit> = use commit, but meld into previous commit
# f, fixup <commit> = like "squash", but discard this commit's log message
# x, exec <command> = run command (the rest of the line) using shell
# b, break = stop here (continue rebase later with 'git rebase --continue')
# d, drop <commit> = remove commit
# l, label <label> = label current HEAD with a name
# t, reset <label> = reset HEAD to a label
# m, merge [-C <commit> | -c <commit>] <label> [# <oneline>]
# .       create a merge commit using the original merge commit's
# .       message (or the oneline, if no original merge commit was
# .       specified). Use -c <commit> to reword the commit message.
#
# These lines can be re-ordered; they are executed from top to bottom.
#
# If you remove a line here THAT COMMIT WILL BE LOST.
#
"~/user/myGetTest/.git/rebase-merge/git-rebase-todo" 27L, 1160C

# 첫번째 이력을 기준으로 아래 이력들의 pick 부분을 s 또는 squash 로 변경해서 통합을 진행한다.


#rebase 취소하기 - git reset –hard HEAD~1

rebase 를 진행해 커밋이력을 변경했지만 취소가 필요한 경우에 –hard 옵션을 통해 사용할 수 있습니다. 이는 rebase에 의해 이동한 브랜치 앞부분의 위치를 rebase하기 전의 커밋의 위치로 되돌림으로써, rebase를 없었던 것으로 할 수 있습니다. --hard 옵션을 사용하였기때문에 이전 수정이력이 삭제될 수 있습니다.

$ git reset --hard HEAD~1
# 1개의 커밋이력을 취소합니다.


#이전 커밋을 취소하기(reset soft) - git reset –soft HEAD~2

스쿼시와 다르게 Reset 을 이용해 기존 커밋을 통합하거나 변경할 수 있습니다. Reset 옵션중에 이전 수정버전을 유지할 수 있는 –soft 옵션을 이용해 진행합니다.

$ git reset --soft HEAD~2

# ~2 은 현재 커밋의 이전 2개까지 범위를 의미합니다.
# log를 통해 확인한 커밋 이력중에서 통합이 필요한 커밋까지의 범위를 확인 커밋을 리셋합니다.
# 리셋후에는 기존 원격 저장소와 소스가 일치하지 않기 때문에 pull 상황이 발생합니다.
# 지금의 소스를 적용하려면 -f 를 통해 강제 push 할 수 있습니다.

항상 협업중인 소스는 reset, rebase 를 신중하게 해야합니다. 아직 다른 개발자의 소스와 통합되기 이전이라면 진행을 해도 무리가 없겠지만, 이미 통합된 소스에 대해서 커밋이력 변경을 진행한다면 사이드 이펙트와 같은 이슈가 발생할 수 있습니다.

지금까지 업무를 진행하면서 가장 많이 사용되는 Git 상황별 사용법에 대해 간단히 정리해 보았습니다. 사실 업무를 하다보면 더 많은 Git 명령어를 사용해야 할 경우가 있습니다. 제가 소개한 내용은 극히 일부이며 가장 많이 사용되는 명령어들만 정리했기 때문에 사용하시는 분들은 자신의 환경에 맞게 좀더 자세한 Git 명령어를 확인하고 사용하시길 권장합니다.

Tags:

Categories:

Updated:

 

 

Leave a comment