☕ 시작
이번 글에서는 git tag와 git rebase, git merge에 대해서 알아보고 실제로 어떻게 사용할 수 있는지 정리해보겠다.
💻 git tag
git tag는 말 그대로 특정 커밋에 "태그"를 매기는 명령어이다.
특정 브랜치의 특정 커밋에 메모를 남기는 것이다.
🧐 사용법
git tag는 아래와 같이 사용할 수 있다.
- 태그 목록
git tag- 태그 생성 (간단 버전)
git tag helloworld- 태그 생성 (디테일 버전)
git tag -a helloworld -m "태그 내용"- 로컬에 생성된 모든 태그를 레포지토리로 push
git push origin --tags그래서 이 태그로 무엇을 할 수 있을까?
⭐ 예시
git tag는 배포 버전을 관리할 때, 사용할 수 있다.
예를 들어서 실제 서비스되는 코드가 저장되는 production브랜치가 있고, 하루에 1번 배포가 된다고 가정해보자.
배포가 될 때, 해당 커밋에 태그를 달면 배포 버전이 관리가 되는 것이다.
혹시나 서비스에 장애가 생겨서 전 날의 배포 버전으로 롤백을 해야하는 경우를 생각해보자. 이 때, 전날에 배포된 커밋에 태깅이 되어 있다면, 해당 커밋을 쉽게 찾을 수 있을 것이고 금방 롤백을 할 수 있을 것이다.
아래 이미지는 예전에 했던 프로젝트에서 실제로 버전을 관리했던 내역이다.
이렇게 배포 하나 하나 마다 기록이 되어 있으므로, 서비스를 운영하는 측면에서 아주 중요한 역할을 해준다.
💻 브랜치 merge & rebase
협업을 하다 보면 여러 브랜치를 생성하게 되고, 필연적으로 서로 다른 브랜치를 하나로 합쳐야하는 일이 생긴다. 브랜치를 합치는 방법은 2가지가 있다.
하나는 git merge이고, 또 다른 하나는 git rebase이다.
이 둘은 무슨 차이가 있을까?
⭐ merge와 rebase 비교
먼저 git merge 는 병합시킬 브랜치와 병합될 브랜치의 최종 커밋들을 비교하여 적절하게 병합이 된다. 또, 병합하면서 "병합을 했다"라는 커밋도 하나 생성이 된다.
특별한 경우가 아니라면, 새롭게 작성한 코드가 안전하게 기존의 코드에 추가가 된다.
그림으로 본다면 아래와 같다.
그렇다면, git rebase는 무엇일까?
git rebase도 두 개의 브랜치를 합치는 것이지만 merge와는 다르다.
git rebase는 두 브랜치의 커밋들을 다 합쳐서 rebase한 브랜치의 커밋으로 만든다.
(브랜치의 base를 다시 설정했다고 해서 rebase라고 한다.)
그림으로 본다면 아래와 같다.
다시 merge와 rebase의 차이점을 정리해보면 아래와 같다.
- git merge를 하면 "병합을 했다"라는 커밋이 생성된다.
- git rebase는 "병합 커밋"이 생성되지 않는다.
- git merge로 병합한 커밋들은 시간 순으로 배열된다.
- git rebase는 기존 브랜치에 rebase한 브랜치의 추가된 커밋들이 얹혀진다.merge와 rebase 모두 병합을 하는 것이고, 최종결과물(병합된 코드)은 동일하다. 하지만 각각은 근본적으로 아주 다르므로 정확한 목적과 의도를 갖고 사용하도록 하자.
🔥 내가 rebase를 쓰는 법
나는 주로 트렁크 브랜치의 코드를 그대로 배포 브랜치로 옮기고 싶을 때 사용한다.
이렇게 하면, merge에 대한 커밋이 추가로 생기지 않기도 하고 안전성이 확보된 메인 브랜치의 코드가 배포 브랜치로 그대로 옮겨지는 격이여서 배포 코드 또한 안전성이 확보된다.
그렇다면, git rebase의 명령어를 좀 더 알아보자.
🧐 명령어
- 현재 브랜치를 main브랜치와 동일하게 만들기
(현재 브랜치를 main브랜치로 rebase하기)
git rebase main- 특정 브랜치를 main브랜치와 동일하게 만들기
git rebase main {특정 브랜치}😊 여러 커밋 합치기
git rebase 는 브랜치를 합치는 것 뿐만 아니라 여러 커밋을 하나의 커밋으로 합칠 수도 있다.
먼저 이렇게 5개의 커밋이 있는 프로젝트가 있다고 가정해보자. 여기서 가장 최근의 커밋 2개를 하나의 커밋으로 합치고 싶다고도 가정해보겠다.
이 때, git rebase를 사용해서 여러 커밋을 하나의 커밋으로 합칠 수 있다.
git rebase -i HEAD~{합치고 싶은 커밋의 갯수}
ex. git rebase -i HEAD~2위 명령어를 실행하면, 병합의 대상이 되는 커밋과 병합시킬 커밋을 선택하게 된다.
명령어를 실행하면 위와 같은 에디터가 뜬다.
여기서 유심히 볼 부분은 Commands 들이다.
나는 그 중에서도 p(pick)와 s(squash)를 많이 사용한다.
pick은 그대로 남길 커밋이고, squash는 이전 커밋으로 합쳐질 커밋을 나타낸다.
나는 가장 최근에 작성한 커밋을 이전 커밋인 update : world.txt로 합치도록 하겠다.
이렇게 수정한 내용을 저장하면, 위와 같이 합쳐질 커밋의 메세지를 새롭게 수정할 수 있는 에디터가 뜬다.
나는 위와 같이 수정해보도록 하겠다. 그리고 수정한 내용을 저장하면, 커밋 합치기가 완료가 된다.
짜잔~~ ㅎㅎ
2개였던 커밋이 하나의 커밋으로 합쳐졌다.
🤔 커밋을 왜 합치나요?
나는 로컬에서 작업할 때는 내가 커밋을 남기고 시점에 편하게 커밋을 남긴다.
커밋 규약같은 거를 엄격하게 지키지 않고, '임시 저장'느낌으로 커밋을 찍는다.
그러다가 작업이 모두 끝나면, 원격 레포지토리에 코드를 push하게 된다.
이 때, 나는 git rebase를 써서 커밋들을 정리하곤 한다.
옳바르게 기록을 남기는 목적도 있지만, 가장 큰 이유는 다른 개발자분들이 내 코드를 좀 더 쉽게 리뷰할 수 있도록 하기 위함이다.
즉, 나는 git rebase 를 활용한 커밋 병합은 협업을 하기 위해서 주로 사용한다. ㅎㅎ
(개인 프로젝트할 때는 커밋을 막 찍는다... ㅋ)
