브랜치 합칠때 merge와 rebase

[Outsider (JeongHoon Byun)]

브랜치를 합칠 때 merge와 rebase중에서 어느걸 더 선호하시나요?

git flow의 방식을 어느정도 도입해서 쓰고 있는데 완전히 습관화되지는 않았지만 일반적으로는
큰 덩어리(?)의 태스크는 의미있게 브랜치명을 주고 --no-ff로 머지해서 머지 커밋을 남기는 편입니다.
그에 비해서 간단한 작업정도만 한 브랜치는 FF로 합치거나 리베이스로 해서 히스토리를 만듭니다.

오픈소스들의 그래프를 봐도 히스토리에 브랜치가 많이 나타나게 하는 사람들이 있고
거의 직선으로 유지하면서 한두개만 브랜치로 머지한 기록이 남게 하는 분들이 있는데
어떤 방법을 보통들 선호하시나요?

전 큰단위는 브랜치로 분리해서 보이는게 좀 명확해 보이지 않나 싶은데
각기 어떤 장단점이 있을려나요? ㅎ

--
/************************************************

Outsider (JeongHoon Byun)

Programmer & Hacker

Blog : http://blog.outsider.ne.kr

Twitter : @Outsideris

G-Talk : outsideris@gmail.com

Github : https://github.com/outsideris

*************************************************/

[Zéide Peace]

소스트리를 쓰니까 그냥 merge를 하는 것 같습니다. 흑흑

일단 모든 히스토리를 남깁니다.
(나중에 작업내용 물어보려구요;)

2013/3/6 Outsider (JeongHoon Byun) <outsi...@gmail.com>

--

Ne perdez pas courage!
Ce n`est pas encore fini.

[Changwoo Park]

어려운 문제입니다. 머지 커밋을 남기면 나중에 머지커밋만 조회해볼수 있어 좋습니다.

남들이 볼만한 프로젝트는 해보질 못해서 전 적당히 합니다. 하지만 예를 들어, npm 프로젝트의 히스토리에서 머지 커밋만 조회해보면 어떤 버전에서 무슨일이 있었는지 한눈에 보입니다. 따로 릴리즈 노트를 열어볼 필요가 없습니다.

릴리즈 노트를 만든다는 느낌으로 하면 될 것 같은데, 정말 그런지 실험을 못해봤네요.ㅜㅜ

[Changwoo Park]

[Outsider (JeongHoon Byun)]

merge 커밋만 조회해 보시는건 어떤 명령어를 사용하시나요?
커밋 메시지에서 Merge 메시지가 들어간걸 검색하시는건가요?

2013/3/7 Changwoo Park <pis...@gmail.com>

어려운 문제입니다. 머지 커밋을 남기면 나중에 머지커밋만 조회해볼수 있어 좋습니다.

남들이 볼만한 프로젝트는 해보질 못해서 전 적당히 합니다. 하지만 예를 들어, npm 프로젝트의 히스토리에서 머지 커밋만 조회해보면 어떤 버전에서 무슨일이 있었는지 한눈에 보입니다. 따로 릴리즈 노트를 열어볼 필요가 없습니다.

릴리즈 노트를 만든다는 느낌으로 하면 될 것 같은데, 정말 그런지 실험을 못해봤네요.ㅜㅜ

[Changwoo Park]

`git log --merges` 입니다. Merge 커밋은 메시지와 상관없이 조회할 수 있습니다.

집에 와서 다시 확인해보니 npm 프로젝트도 릴리즈 노트 수준으로 히스토리를 관리하지 않고 있네요. 죄송합니다, 정정합니다.

그리고 Rebase할 수 없는 상황이 아니라면 Rebase해서 Merge하는 것이 보기 좋습니다.

그러니까 Rebase를 할지 말지와 Merge 커밋을 남길지 말지는 다른 문제인 것 같습니다.

저는 Topic 브랜치를 Long-Running 브랜치에 Merge할 때 반드시 Rebase를 합니다.

Topic 브랜치에 커밋이 한 개면 FF로 Merge하고 여러개면 Merge 커밋을 남김니다.

git-flow도 이렇게 구현은 돼 있습니다.

FF가 가능해도 --no-ff 옵션이 켜진 상태로 Merge하지만, 커밋이 하나일 땐 그냥 FF로 Merge해버립니다.

On Thursday, March 7, 2013 6:06:05 PM UTC+9, JeongHoon Byun wrote:

merge 커밋만 조회해 보시는건 어떤 명령어를 사용하시나요?
커밋 메시지에서 Merge 메시지가 들어간걸 검색하시는건가요?

2013/3/7 Changwoo Park <pis...@gmail.com>

어려운 문제입니다. 머지 커밋을 남기면 나중에 머지커밋만 조회해볼수 있어 좋습니다.

남들이 볼만한 프로젝트는 해보질 못해서 전 적당히 합니다. 하지만 예를 들어, npm 프로젝트의 히스토리에서 머지 커밋만 조회해보면 어떤 버전에서 무슨일이 있었는지 한눈에 보입니다. 따로 릴리즈 노트를 열어볼 필요가 없습니다.

릴리즈 노트를 만든다는 느낌으로 하면 될 것 같은데, 정말 그런지 실험을 못해봤네요.ㅜㅜ

--
/************************************************

Outsider (JeongHoon Byun)

Programmer & Hacker

Blog : http://blog.outsider.ne.kr

Twitter : @Outsideris

G-Talk : outsi...@gmail.com

Github : https://github.com/outsideris

*************************************************/

[Outsider (JeongHoon Byun)]

`--merges`라는 옵션이 있었군요...

rebase에 대해서는 제가 좀 헷갈리게 말했네요.
말씀하신대로 rebase를 하고 머지할 수도 있지만(사실 이방법이 좋아보이는데 맨날 혼자만 쓰다보니 습관이 잘 안들;;)
rebase냐 merge냐 했던 질문은 merge커밋을 남기냐 안남기고 브랜치에 합치냐 하는
의미였습니다.

git-flow는 모든 브랜치의 머지커밋을 남기는 방식을 쓰고 있긴한데
이러다보면 너무 히스토리트리가 복잡해지는것 같아서 간단한건
리베이스나 FF로 합치는 편인데
암튼 좀 더 생각해 봐야겠군요. 조언 감사합니다. ㅎㅎ

2013/3/7 Changwoo Park <pis...@gmail.com>