[Git] Linear History with Foxtrot Merge

Git은 history를 관리하는 방식이 크게 두 가지로 나뉜다.

• Linear history
  • 장점: history graph가 깔끔해진다.
  • 단점: patch 반영 시 conflict resolution이 번거롭다.
• Non-linear history
  • 장점: pull (fetch and merge) command로 수행이 쉽다.
  • 단점: history가 복잡해져 나중에 특정 시점을 검색하기가 쉽지 않으며, foxtrot merge가 발생 될 수 있다.

Foxtrot merge란, 만약 non-linear history 방식으로 진행이 될 경우 아래와 같은 경우가 발생 될 수 있다.

1. User 1과 user 2가 commit A 기반으로 작업을 시작한다.
2. User 1은 commit B를 생성하고, user 2는 commit A에서 branch를 생성해 commit C를 생성한다.
3. User 1이 먼저 remote repository에 push를 하고, user 2가 그 뒤에 push 하려고 하면 Git은 conflict이 발생하니 merge를 하라고 메시지를 보낸다.
4. User 2가 merge를 위해 user 1이 commit한 B를 merge 하면 foxtrot merge가 발생되어 가운데 그림과 같은 형태의 git graph가 된다.
5. 그리고 remote repository에 git push를 하게 되면 오른쪽 그림처럼 main branch가 변경되게 된다.

어떤 것이 정답이라고는 나와있지 않지만, 개인적으로는 linear history 방식이 좀 더 깔끔한 것으로 선호된다. 그럼 어떻게 하면 linear history 방식으로 source code management를 할 수 있을까?

Single User Single Branch

쉽게 말해서 main branch (작업의 시작이 되는 공동의 branch) 에서 작업을 하지 않고, main branch에서 각자 작업을 위한 branch를 생성해서 작업을 하고, 각자 main branch에 fetch and merge를 하는 방식으로 진행하면 위와 같은 foxtrot merge 문제가 발생되지 않고 fast-forward 방식으로 merge가 될 것이다.

위 그림의 경우는 main branch에서 user 1이 commit B를 생성해서 생긴 문제다.

Rebase and Merge

이 방식은 위 그림처럼 자유롭게 작업을 진행을 하되, 대신 rebase를 해 내가 merge를 하고자 하는 target branch와 conflict resolution을 진행하고 난 뒤에 merge를 하는 것이다. (만약 main branch에서 작업을 할 경우, 여전히 foxtrot merge 문제가 발생 될 수 있다.)

이렇게 진행 할 경우 git graph가 깔끔하게 정리가 되는 것을 확인 할 수 있다.

Reference

1. https://seosh817.tistory.com/240#google_vignette