커밋 히스토리(Commit History)
-
개발자들이 작업을 진행할 때 코딩 컨벤션( = 코딩 관습? 스타일), git 전략, commit 메시지 작성법등이 있을 것이다.
-
커밋 히스토리(Commit History) : 의미있는 커밋이력들이 모여서 형성하게 되는 것
- 커밋을 의미있게 작성했다면, 필요한 커밋 이력을 찾기가 편해질것이다. 그 다음으로 필요한 것이 이 커밋들이 모여서 이루는 커밋 히스토리(Commit History) 관리이다.
-
만약 커밋이력 release 3.0.0 에선 없던 버그가 release 3.0.1 에서 발생한 경우를 생각해보자.
이때 커밋 히스토리가 제대로 정리되어 있다면, 커밋 히스토리 (이전 커밋내용) 으로부터 발생한 벅그와 관련한 버그 원인을 찾아내고 수정 내역을 찾아낼 것이다!
이런 상황을 위해 커밋 히스토리(Commit History) 관리가 필요하다!
이러한 커밋 히스토리 관리를 위한 3가지 방법을 알아보자.
merge
가장 기본적인 방법
merge 에 대한 commit 이 하나 생성되고 어느 시점에 merge 를 진행했는지 쉽게 알 수 있다.
즉, develop 에서 feature 에 대해 merge 를 진행하면 어느 시점에 feature 가 develop 으로 merge 되었는지를 쉽게 확인할 수 있다.
위와 같이 feqture/c, feature/d 가 어느 시점에 develop 브렌치로 merge 되었는지를 (합쳐졌는지를) 쉽게 알 수 있다.
- 단점 : 그렇지만 이 방법은 만약 feature 브렌치가 계속 늘어나고 여러번의 merge 가 생기게 되면, 그래프가 복잡해져 커밋 히스토리(Commit History) 를 파악하기 더욱 어려워질 수 있다.
하지만 merge 의 시점은 확실히 알 수 있다는 장점이 있다.
squash and merge
이 방법은 merge 에 대한 이력은 생기지 않는 방법이다.
예를들어 feature 에서 여러 작업을 하고 develop 으로 합치는 경우에 feature 브렌치의 많은 작업 이력들을 하나의 커밋으로 합쳐서 develop 으로 합친다.
위 그림을 보면 feature/c 에서 작업한 3가지의 커밋이 별도로 develop 으로 merge 가 되는 형식이 아니고,
3가지의 커밋이 하나로 합쳐져서 develop 제일 앞의 부분에 commit 으로 붙게된다.
이러한 방법은 feature 의 지저분한 작업 이력들을 develop 으로 합칠 때 사용하면 develop 의 이력들을 깔끔하게 관리할 수 있을 것이다. 어차피 feature 브렌치들은 merge 가 되면 삭제하기 떄문이다!
rebase and merge
이 방법 역시 merge 에 대한 이력이 남는 방법은 아니다.
squash and merge 와는 다르게 모든 커밋이력들이 rebase 되어서 붙는 방법이다.
즉, fast-forward 된다!
위의 그림은 feature/a 의 커밋 이력들이 모두 develop 으로 붙어진 그림이다.
여기서 만약 feature/a 브렌치를 삭제하기 되면 develop 브렌치에서만 작업한 것 같은 그림이 나타나게 될 것이다.
다만 이 방법은 언제 merge 가 되었는지를 알 수 없는 방법이긴하다.
그렇지만 모든 커밋이력을 가지고 합칠 수 있다는 장점이 있다!
release -> master 브렌치로 합칠때, 사용하면 모든 release 에 대한 이력을 master 에 자세하게 남길 수 있는 방법이 될 것이다.
