저번 시간에는 GitHub에 대한 전반적인 기초 지식을 다뤄봤습니다.
이번 시간에는 커밋을 좀 더 잘 다룰 수 있는 여러 가지 방법에 대해 알아보겠습니다.
📥 커밋 히스토리 살펴보기
이때까지 우리가 한 커밋들을 살펴봅시다. 이를 커밋 히스토리라고 부르는데요. 커밋 히스토리를 보면 프로젝트 디렉토리에서 일어났던 모든 변경 사항들을 확인할 수 있습니다. 커밋 히스토리는 git log 커맨드를 통해 볼 수 있습니다. log는 '기록, 일지'라는 뜻을 가지고 있습니다.
git log
커밋 히스토리에서는 가장 오래된 커밋이 가장 아래에 있습니다. 따라서, 지금 화면에서 보고 있는 커밋은 가장 최근의 커밋인 것이죠. 이때, 우리가 이해할 수 있는 영어로 된 부분이 바로 커밋 메시지입니다. 이처럼 커밋 메시지를 남겨두면 어떤 커밋이었는지 이해하기가 수월합니다.
그럼 커밋 뒤에 있는 알 수 없는 문자열은 무엇일까요? 이는 커밋의 아이디입니다. Git은 각각의 커밋을 구분하기 위해 각 커밋에 아이디를 붙여 관리합니다. 이를 어려운 말로 커밋 해시라고도 부릅니다.
그리고 Author는 커밋한 사람을 의미하며, Date는 커밋한 날짜와 시간을 의미합니다.
이제 q를 써서 히스토리에서 나갑니다.
커밋 히스토리를 좀 더 깔끔하게 보는 방법이 있습니다. 바로 --pretty라는 옵션을 주면 됩니다. 이때, 주의해야 할 것은 우리가 지금까지 배웠던 옵션과 다르게 이 옵션은 하이픈이 두 개 있다는 점입니다. 그리고 이 옵션의 값으로 =oneline을 주면 됩니다. 이는 커밋당 한 줄씩 출력하라는 뜻입니다.
git log --pretty=oneline
그럼 커밋 하나의 정보가 딱 한 줄에 보입니다. 커밋 아이디와 커밋 메시지만 간단하게 보여주기 때문이죠. 총 여섯 줄이므로 이제까지 여섯 번의 커밋을 진행한 것입니다.
그런데 이렇게만 봐서는 어떤 파일이 어떻게 변했는지 알 수가 없습니다. 이럴 때, 사용할 수 있는 커맨드는 git show입니다. show는 '보여준다'는 뜻이죠? 커맨드 옆에는 구체적으로 알고 싶은 커밋의 아이디를 적으면 됩니다.
문제는 커밋 아이디가 너무 길고 복잡하다는 것인데요. 사실, 아이디의 앞 네 자리만 적어줘도 충분합니다. 그러니 앞의 네 자리가 겹치는 커밋 아이디가 있으면 안 되는데요. 그렇지만 커밋 수가 엄청 많지 않은 이상 겹치는 경우가 잘 없습니다. 한 번 해볼게요.
git show 4ee6
실행을 하면 해당 커밋과 바로 그 전의 커밋의 차이를 보여줍니다. 여기서 --- 부분이 이전 커밋에서의 모습이고 +++ 부분이 해당 커밋에서의 모습입니다. 마찬가지로 -이면서 빨간 글씨가 이전 커밋에서의 README의 모습, +면서 녹색 글씨가 현재 커밋에서의 README의 모습입니다.
정리하자면, 전반적인 커밋 히스토리를 보려면 git log를, 특정 파일의 변화를 보고 싶다면 git show를 활용하면 됩니다.
📥 m 옵션 없이 커밋 메시지 남기기
커밋을 할 때 m 옵션을 통해 커밋 메시지를 남겼었죠? 그런데 m 옵션 없이도 커밋 메시지를 남기는 방법이 있습니다. 한 번 보여드릴게요.
calculator.py 파일을 열어 multiply 함수를 추가하겠습니다. multiply는 곱 연산을 뜻하는데요. 우리는 일부러 다른 연산을 넣어보겠습니다.
파일을 저장한 후, Git Bash로 넘어와 커밋을 진행합니다.
git add .git commit이번에는 m 옵션을 주지않고 commit만 입력한 후 실행해보겠습니다.
그럼 위와 같이 새로운 창이 하나 뜹니다. 위 문구를 해석하면 커밋 메시지를 작성해달라고 하네요. 그 다음, 샾(#)으로 적힌 문장은 무시될 거라고 합니다.
이 창에서는 커밋 메시지를 입력할 수 있는데요. 화면에 나온 문구들은 커밋 메시지를 작성하는 방법에 대한 간단한 안내 문구들입니다. 안내한 내용대로 모두 샾으로 시작하고 있기 때문에 커밋 메시지에는 포함되지 않습니다.
또한, 이 창은 Git에서 기본 설정된 텍스트 에디터가 실행된 것입니다. 유닉스 체계에서는 이러한 텍스트 에디터를 vim이라고 부릅니다. 이에 대해 더 자세히 알고 싶으시다면 유닉스 시리즈를 읽어보시길 바랍니다.
그럼 커밋 메시지를 한 번 입력해 봅시다. i를 누르면 입력 모드로 들어가는데요. 입력 모드가 되면 좌측 하단에 -- INSERT --라는 문구가 뜹니다. 이 상태에서 커밋 메시지 "Add one function"을 적어줍니다. 그 다음, 엔터를 두 번 누르고 상세 내용도 적어주겠습니다. 다음과 같이 적어주세요.
이제 저장을 해야 하는데요. esc를 누르고 :wq를 입력한 다음 엔터를 치면 됩니다.
그럼 자동으로 커밋이 완료되고 커밋 메시지가 저장됩니다. 이 상태에서 커밋 히스토리를 살펴보겠습니다.
방금 추가한 내용이 잘 들어갔네요.
그럼 이렇게 m 옵션 없이 git commit만으로 텍스트 에디터에 커밋 메시지를 남기는 방법에는 어떤 장점이 있을까요? 바로 복잡하고 긴 커밋 메시지를 쉽게 남길 수 있다는 점이 있습니다. 그러므로 상황에 따라 간단한 메시지를 남기고 싶으면 m 옵션을, 긴 메시지를 남겨야 한다면 git commit만을 입력하면 되겠습니다.
📥 최신 커밋 수정하기
커밋을 하고 나면 아쉬운 순간들이 있습니다. 미처 추가하지 못한 코드나 어려운 커밋 메시지와 같은 이유들 때문입니다. 또, 어떤 경우에는 잘못된 코드를 그대로 두고 커밋을 할 수도 있습니다. 물론 수정을 하고 새로운 커밋을 하면 되지만 그렇게 하면 굳이 없어도 될 커밋이 생기겠죠?
그래서 Git에는 최신 커밋을 다시 수정할 수 있는 기능이 있습니다. 앞서 우리는 multiply 함수를 작성할 때, 곱셈이 아닌 다른 연산을 넣었습니다. 이를 수정하여 새로 커밋하지 않고 최신 커밋 자체를 수정해 보겠습니다.
커밋 히스토리를 다시 살펴봅시다. 아이디와 커밋 메시지만 확인하고 싶으니 pretty 옵션을 주겠습니다.
git log --pretty=oneline
그럼 방금 생성한 최신 커밋을 확인할 수 있습니다.
그 다음, Sublime Text로 돌아와 잘못된 코드를 수정하겠습니다.
그 다음 평소처럼 git add까지 마쳐주세요. 이제 커밋을 할 차례인데요. 지금 우리는 새로운 커밋을 하려는게 아니라 최신 커밋을 수정하려고 하고 있습니다. 이때, --amend라는 옵션이 필요합니다. amend는 '수정하다, 고치다'라는 뜻을 가지고 있습니다. 이 옵션은 git에서 최신 커밋을 수정하는 역할을 수행합니다. 그리고 pretty 옵션과 마찬가지로 하이픈 두 개를 사용합니다.
git commit --amend그럼 m 옵션 없이 commit만 했을 때와 마찬가지로 텍스트 에디터 창이 뜨는데요. 아까 적어줬던 커밋 메시지가 보입니다.
커밋 메시지를 다음과 같이 수정해주겠습니다.
Add multiply function그 다음 esc를 누르고 :wq를 입력하면 커밋이 완료됩니다.
다시 커밋 히스토리를 보겠습니다.
git log --pretty=oneline
그럼 제일 최신의 커밋이 방금 바꾼 커밋으로 바뀐 것을 확인할 수 있습니다. 기존의 커밋은 사라졌죠. 바뀐 것을 또 확인해볼 수 있는 방법은 커밋 아이디에 있습니다. 이전에는 최신 커밋의 아이디가 f036으로 시작되는 반면에, 현재는 2442로 시작되고 있습니다.
누구나 한번에 완벽한 커밋을 하기란 어렵습니다. 따라서, 커밋을 하고 나서 고치고 싶은게 있다면 amend 옵션을 적극 활용해보시길 바랍니다.
자, 그럼 이때까지 한 커밋을 리모트 레포지토리에 전송해주겠습니다. git push 커맨드를 사용하면 되겠죠?
git push
푸쉬가 잘 되었습니다.
만약 푸쉬를 하다가 에러가 나면 --force라는 옵션을 붙여주세요. 강제로 푸쉬가 가능합니다.
📥 커밋 생성, 메시지 작성 가이드라인
커밋에는 크게 세 가지 정보가 있습니다.
- 커밋을 한 사용자 아이디
- 커밋한 날짜와 시간
- 커밋 메시지
특정 프로젝트 디렉토리의 변경 이력을 한 눈에 파악하기 위해서는 이러한 정보들이 필요합니다. 그런데, 1과 2의 경우는 커밋을 할 때, git에서 자동으로 기록되지만 3의 경우에는 커밋을 하는 사람이 직접 작성하는 것이기 때문에 사람마다 그 분량이나 스타일이 다를 수 있습니다.
개인 프로젝트의 경우에는 상관 없지만, 기업 프로젝트와 같이 여러 개발자가 참여하는 프로젝트의 경우에는 이러한 커밋 메시지가 아주 중요합니다. 따라서, 작성법에 대한 규칙이 정해진 경우가 많은데요.
지금부터 일반적인 가이드라인을 소개해드리려 합니다.
❗ 커밋 메시지 작성 가이드라인
-
커밋 메시지의 제목과 상세 설명 사이에는 한 줄을 비워두세요.
- 이전 영상에서 메시지를 남겼을 때, 이 규칙을 적용했었죠?
- 보통 커밋 메시지는 제목(title)과 상세 내용(body)로 이루어져 있습니다.
- 그리고 그 사이를 한 줄 띄워야 가독성을 높일 수 있습니다
- 이는, git에서 공식적으로 권장하는 사항이기도 합니다.
-
커밋 메시지의 제목 뒤에 온점(
.)을 붙이지 마세요. -
커밋 메시지의 제목의 첫번째 알파벳은 대문자로 작성하세요.
-
커밋 메시지의 제목은 명령조로 작성하세요.
-
커밋의 상세 내용에는 다음과 같은 내용을 적어주세요.
- 커밋한 이유
- 문제 상황
- 적용한 해결책의 효과
-
다른 사람들이 자신의 코드를 바로 이해할 수 있다고 생각하지 말고 최대한 친절하게 작성하세요.
❗ 커밋할 때, 알아야 하는 가이드라인
첫째, 하나의 커밋에는 하나의 수정사항이나 이슈를 해결한 내용만 남기세요. 다양하게 수정을 하고 나서 하나의 커밋으로 남기는 것은 좋지 않습니다.
다시 말해, 최대한 작은 단위의 변화를 기준으로 커밋을 해야 합니다. 예를 들어, 여러 함수를 수정했는데 한꺼번에 커밋을 하고 나면 나중에 어떤 함수가 문제였는지 알기가 어렵습니다. 그리고 이렇게 하면 커밋 간의 독립성이 떨어져 프로젝트의 이력을 확인하기도 어렵습니다.
하지만 어느 정도의 단위를 최대한 작은 것으로 볼 것인지는 상황에 따라 다릅니다. 다만, 체감 상 많은 내용을 담고 있다고 느껴지면 커밋을 나눠서 진행하기를 추천 드립니다.
둘째, 현재 프로젝트 디렉토리의 상태가 그 내부의 전체 코드를 실행했을 때 에러가 발생하지 않는 상태인 경우에만 커밋을 하세요. 그렇지 않으면, 나중에 동료 개발자가 특정 커밋을 실행했을 때 혼란을 줄 수 있습니다.
커밋으로 보관된 특정 시점의 전체 코드는 항상 문제 없이 실행되어야 합니다. 과거의 커밋일지라도 과거 버전의 프로그램을 사용해야 하거나 과거 커밋을 시작점으로 한 다른 방향의 별도 프로젝트를 시작하거나 아예 그 커밋으로 현재 프로젝트를 리셋할 수도 있기 때문이죠.
따라서, 매 커밋의 코드들은 항상 정상 실행되는 상태의 코드여야 합니다. 그렇지 않으면 나중에 그 커밋을 위와 같은 용도로 사용하려고 할 때 문제가 생길 테니까요. 협업하는 상황에서 이러한 문제가 발생하면 민망하기도 하구요. 그러니 커밋 전에는 반드시 프로그램이 정상 실행되는지 점검하고 커밋하는 것이 좋습니다.
다시 한번, 이러한 가이드라인이 필요한 이유를 설명드리자면 나중에 다시 봤을 때 커밋의 내용이 이해하기 어렵지 않게 하기 위함과 다른 동료 개발자와 협업하는 데 방해가 되지 않기 위함임을 상기해주시길 바랍니다.
이번 시간에는 커밋을 잘 다룰 수 있는 방법 중 커밋 히스토리 보기, m 옵션 없이 커밋 메시지 남기기, 최신 커밋 수정하기, 커밋 생성 및 커밋 메시지 작성 가이드라인에 대해 배웠습니다. Git에서 중요한 역할을 맡는 커밋인만큼 그 기능을 더 자세히 알아두는 것이 좋을 것 같다는 생각이 듭니다.
다음 시간에는 커밋을 잘 다룰 수 있는 또 다른 방법들에 대해 함께 알아보겠습니다.
* 이 자료는 CODEIT의 'Git으로 배우는 버전 관리' 강의를 기반으로 작성되었습니다.