커밋 관리하기

git&github

커밋 관리하기

몽자비루 2025. 10. 24. 00:53

협업을 하다보면 github에 commit 을 하는 경우가 많은데, 이때 불필요하게 자주 commit 을 하거나

알아보기 어려운 내용의 commit message를 작성하면 추후 문제가 생겼을 때 관리하기 어렵다.

그래서 한 단위의 작업을 하나의 버전에 내용 가능한 메시지와 함께 커밋을 해야 하고

팀원끼리 합의된 방식을 잘 준수하여 일관된 형태의 commit 을 작성하는 것이 가장 중요하다.

특히 커밋 메시지를 작성하는 널리 사용되는 방식인 컨벤션이 있는데 형태는 아래와 같다.

type : subject

body(optional)

footer(optional)

여기서 type은 해당 작업이 어느 부류에 속하는 지 바로 알 수 있도록 붙이는 태그를 의미한다.

예를 들어 feat 는 새로운 기능 추가, fix 는 버그 수정, docs 는 문서 수정, type 은 스타일 수정,

refactor 은 코드 리팩토링, perf 는 성능 개선, test 는 테스트 추가, chore는 보조 기능 수정 등이 있다.

Subject 는 커밋의 작읍 내용을 간단히 설명하고, body 는 길게 설명할 필요가 있는 경우 작성한다.

마지막으로 footer는 중요한 변경사항이나 특정 이슈 수정사항인 경우, 해당 이슈번호를 적기도 하며,

여기서 중요한 점은 type과 body, footer 사이에 각각 한줄씩 띄워서 입력해야 한다는 것이다.

예를 들어 로그인에 비밀번호 검사 기능의 이슈를 수정했다는 가정 하에 아래와 같이 작성할 수 있다.

fix : 로그인 비밀번호 검사 이슈 수정

로그인 비밀번호 검사 시, 모든 조건을 만족했음에도 fail처리되는 이슈를 수정함.
- 특수문자 인식 에러 수정
- 공백 포함하는 경우, 공백을 제거하도록 처리

Close #123

요즘에는 gitmogji 라고 해서 type에 이모지를 활용하기도 하는데 관련사항은 링크를 확인해보면 된다.

1. add 와 commit을 분할하여 진행하기

git add . 은 현재 local의 모든 수정사항을 stage area 에 넣는데,

git add 를 하기 전에 하나하나 확인하거나 헝크별로 진행하고 싶은 경우가 있다.

그럴 때 git add -p 를 입력하면 아래와 같은 페이지로 이동하게 되고 여기에서 보이는 부분 중

변화된 내용 하나하나를 hunk라고 부르며 이 hunk를 받아들일지 여부를 결정할 수 있다.

여기서 y, n, q, a, d, s, e, p, ? 중 하나를 입력하여 추가 액션을 취할 수 있는데
각각에 대한 설명은 아래 이미지를 참고하면 되고, 주로 사용되는 것은
y를 입력하여 hank를 받아들이거나 n를 입력하여 hank를 받아들이지 않을 수 있다.

만약 하나의 파일에서 일부는 수정하고 일부는 수정을 받아들이지 않는 경우,

git status를 진행했을 때, add가 된 부분과 되지 않은 부분 모두 해당 파일이 노출된다.

이후 git commit -v 를 진행하면, 아래에 어떤 부분이 변경되었는지 자세하게 확인할 수 있다.
이는 git commit 과 git diff --staged 를 동시에 하면서 각각 행크에 대한 승인을 한다고 볼 수 있다.

이후에 git status를 입력하면 수정되지 않은 상태로만 노출되고 기존에 수정된 상태는 사라졌다.

마지막으로 git add . 과 git commit 을 입력하면 나머지 변경사항이 전체 수정되는 것을 볼 수 있다.
이렇게 하나의 파일로도 원하는 부분만 수정함으로써 여러번 commit을 할 수 있다.

따라서 큰 파일에 작성된 변경사항도 분할되어 담길 수 있어 세심하게 add와 commit을 진행할 수 있다.

2. git stash

그렇다면 코드를 작업하다가 다른 코드를 수정해야 할때는 어떻게 하는게 좋을까?

아직 마무리하지 않은 작업을 스택에 잠시 저장할 수 있는 명령어가 있는데, git stash이다.

다만 tracking이 되는 파일에 한해서 한정적으로 사용할 수 있다는 주의점이 있다.

git stash 를 진행하면 이전에 수정하던 항목들이 전체 비활성화되서 노출된다.

해당내용은 sourcetree에서 확인해보면 스태시라는 공간에 노출되는 것을 볼 수 있다.
이후 다른작업을 한 뒤 stash의 값은 같은 브랜치 또는 다른 브랜치 위에 언제든 적용할 수 있다.

git stash pop을 진행하면 기존에 작업한 것들이 돌아오고 언제든 다시 적용할 수 있다.

또한 원하는것만 stash를 하기 위해서는 git stash -p를 진행하면 되는데 아래와 같이
수정사항 중 stash 에 넣고싶은 부분이 있냐고 물어보고 y, n를 통해 선택한다.

여기에서 y를 하는 항목만 stash로 이동되고 나머지는 local에 유지되는 것을 볼수있다.

아래처럼 test1.py만 적용하면 test2.py의 수정내용은 유지되고 test1.py의 수정내용은 사라진다.

또한 stash를 할 때에 메시지를 작성해서 어떤것을 stash로 넣었는지 명시해둘 수 있는데,
git stash -m "stash message" 를 입력함으로써 stash message를 입력할 수 있다.

이후 stash 로 이동시킨 목록을 stash list로 살펴볼 수 있고 stash 우측의 번호로 불러올 수 있다.

불러오는 방법은 git stash apply stash@{n} 형식이며, 만약 이렇게 일부만 불러오는 경우에
해당 항목이 자동으로 list에서 사라지지 않기 때문에 명시적으로 삭제해줘야 한다.

이때 사용되는 명령어는 git stash drop stash@{n} 이며, 이후 list에서 해당 stash가 사라져있다.

그렇다면 여기에서 git stash apply 와 drop을 동시에 할 수 있는 방법은 없을까?
git stash pop stash@{n}을 입력하면 특정 stash에 대해 두가지 액션을 한번에 할 수 있다.

추가적으로 git stash branch "branch name"을 입력하면 새로운 브랜치를 생성하여 pop하는데
일반적으로 수정된 파일과 stash의 내용이 충돌이 있는 경우 유용하게 쓰일 수 있다.

또한 stash의 모든 항목들을 비우기 위해서는 git stash clear 명령어를 입력하여 동작할 수 있다.

만약 소스트리에서 stash를 하고싶은 경우, 상단의 "스태시" 버튼을 눌러서 원하는 내용을 입력하고
확인을 누르면 수정중인 내용이 LNB의 "스태시" 하위로 이동되고 나중에 적용하고 싶다면
스태시 목록을 우클릭한 뒤 스태시 적용 버튼을 누르면 다시 파일에 적용시킬 수 있다.

3. 커밋 수정하기

이렇게 커밋하기 전에 미리 확인하기와 잠시 로컬의 내용을 옮기는 작업을 했는데,

만약 이미 커밋한 상태라면, 그리고 커밋의 내용을 수정하고 싶다면 어떻게 해야할까?

git commit --amend 를 사용해보면 commit message를 수정할 수 있는 에디터가 열린다.

이후 commit message를 변경한 뒤 :wq 로 저장하면 git commend가 수정된다.

두번째로 커밋에 포함해야 하는 내용이 누락된 경우가 있는데, 이때에도 git commit --amend가 쓰인다.

먼저 수정사항을 git add . 으로 staging area에 등록하고 git commit --amend를 입력하여 에디터로 이동한다.

여기서 커밋 메시지를 입력하고 저장하면 이전 commit message가 수정되면서 추가한 내용도 포함된다.

마지막으로 커밋 메시지를 변경하는 또다른 방법은 git commit --amend -m "commit message"

또한 git add . 없이 수정사항을 staging area 등록까지 일괄적으로 진행하고 싶다면

git commit --amend -am "commit message" 를 진행하여 수정사항 저장 및 메시지 변경이 가능하다.

이렇게 과거의 여러 커밋들을 수정 뿐 아니라 삭제, 병합, 분할 등 다양하게 수정할 수도 있다.

방법은 rebase를 사용하는데 이전에 rebase 에 대해서는 commit 대상 branch에게

다른 branch를 옮기는 것이라고 언급한 적이 있는데, 이번에도 비슷한 개념이다.

예를 들어 과거의 어떤 내역이 변경되면, 이 이후의 변경사항들은 이전의 commit과 동일하지 않다.

즉, A-B-C-D-E-HEAD 라고 되어있는 경우, B를 수정하면 B만 수정되는 것이 아니고,

이후의 C, D, E, HEAD 까지 커밋을 복사한 뒤 그것을 rebase로 붙이는 식으로 동작하게 된다.

또 다른 예를 들자면, A-B-C-D-E-HEAD 상태에서 C를 수정했다고 가정해보자.

그러면 A-B-C`-D-E-HEAD 가 아니라, A-B-C`-D`-E`-HEAD` 이러한 형식으로 변경되게 되고,

B 뒤에 있던 C~HEAD commit 은 사라지게 되는것과 비슷한 원리라고 보면 될것 같다.

먼저 commit 의 목록은 위와 같고 먼저 add datas에 대한 commit hash를 기억한 다음에,

git rebase -i "commit hash" 를 입력하면 아래와 같은 화면이 나온다.

여기서는 add datas 위에 있는 모든 커밋 목록들이 나오는데, 여기에서 pick 이라는 값을

어떻게 수정하고 저장하느냐에 따라 각 커밋에 대해 무엇을 할 지를 지정한다.

명령어	설명
p, pick	커밋 그대로 유지하기
r, reword	커밋 메시지 변경
e, edit	커밋 수정을 위해 정지시키기
d, drop	커밋 삭제하기
s, squash	이전 커밋에 합치기