두 단어로 : git bisect

선형 이력을 사용하면 버그의 실제 원인을 정확히 파악할 수 있습니다.

예입니다. 이것은 우리의 초기 코드입니다.

def bar(arg=None):
    pass

def foo():
    bar()

지점 1 arg은 더 이상 유효하지 않은 일부 리팩토링을 수행 합니다.

def bar():
    pass

def foo():
    bar()

Branch 2에는 다음을 사용해야하는 새로운 기능이 있습니다 arg.

def bar(arg=None):
    pass

def foo():
    bar(arg=1)

병합 충돌은 없지만 버그가 도입되었습니다. 운 좋게도이 특정 단계는 컴파일 단계에 걸리지 만 항상 운이 좋은 것은 아닙니다. 버그가 컴파일 오류가 아닌 예기치 않은 동작으로 나타나는 경우 일주일 또는 2 주 동안 버그를 찾지 못할 수 있습니다. 그 시점 git bisect에서 구조!

젠장. 이것이 보이는 것입니다 :

(master: green)
|             \_________________________
|                \                      \
(master: green)  (branch 1: green)     (branch 2: green)
|                 |                     |
|                 |                     |
(master/merge commit: green)            |
|                         ______________/
|                        /
(master/merge commit: red)
|
...days pass...
|
(master: red)

따라서 git bisect빌드를 중단 한 커밋을 찾기 위해 전송 하면 병합 커밋을 정확히 찾아냅니다. 글쎄, 그것은 약간 도움이되지만 본질적으로 하나의 커밋 패키지가 아닌 커밋 패키지를 가리키고 있습니다. 모든 조상은 녹색입니다. 반면에 rebasing을 사용하면 선형 이력을 얻을 수 있습니다.

(master: green)
|
(master: green)
|
(all branch 1 commits: green)
|
(some branch 2 commits: green)
|
(branch 2 commit: red)
|
(remaining branch 2 commits: red)
|
...days pass...
|
(master: still red)

이제 git bisect빌드를 깨뜨린 정확한 기능 커밋을 가리킬 것입니다. 커밋 메시지는 다른 리팩토링을 수행하고 버그를 즉시 수정하기에 충분한 의도를 설명하는 것이 이상적입니다.

관리자가 모든 코드를 작성하지 않았을 때 큰 프로젝트에만 영향을 미치므로 주어진 커밋이 수행 된 이유 / 각 분기의 목적을 반드시 기억할 필요는 없습니다. 따라서 정확한 커밋을 정확하게 찾아 내면 커밋을 검사 할 수 있습니다.

즉, (현재) 여전히 병합을 선호합니다. 릴리스 브랜치에 기반을두면 git bisect일상적인 작업에 대한 실제 기록을 유지하면서 와 함께 사용할 선형 기록을 제공합니다 .

답변