2013-07-16 10 views
0

'git bisect'의 일반적인 사용 사례는 참조의 끝을 '나쁜'상태로 선언하고 가장 최근의 '양호한'상태에 대한 기록을 검색하는 것이다. 이것은 버그를 도입 한 커밋을 검색 할 때 의미가 있습니다.버그를 찾아서 _fixed_ a 버그를 찾는다

그러나 최신 커밋에서 수정 된 이전 코드에서 버그가 발견되는 경우가 있는데,이 버그는 어떤 버그가 수정 되었습니까? git bisect을 "좋음"과 "나쁜"의 반대 의미로 사용할 수 있습니다. 즉, 고정 된 버그를 "나쁜"상태로, 버그를 "양호한"상태로 간주합니다. 그러나 이것은 다소 혼란 스럽습니다. "좋은"상태에서 이등분을 시작하고 "나쁜"상태를 다시 찾는 것이 더 분명 할 수 있습니다. 그러나 자식은 그 접근 방식을 좋아하지 않습니다 :

$ git bisect start 
$ git bisect good 
$ git checkout <commit with known bug> 
$ git bisect bad 
Some good revs are not ancestor of the bad rev. 
git bisect cannot work properly in this case. 
Maybe you mistake good and bad revs? 

이 경우를 처리하는 좋은 방법은 무엇입니까?

+5

[가능한 첫 번째 GOOD를 찾기 위해 git bisect를 어떻게 사용할 수 있습니까?] (http://stackoverflow.com/questions/15407075/how-could-i-use-git-bisect-to-find- 첫 - 좋은 - 커밋) – Zaz

답변

2

당신은 git가 "예쁘게 보이는"것과 "직관적 인 인터페이스"에 그다지 그다지 주목하지 않았을 것입니다. 당신은 대답과 적절한 git 방법을 추측했습니다 : 단지 나쁜 것으로 고정되어 좋은 것으로 고정되어 있지 않다고 생각하십시오.

약간의 추악함과는 별개로 (거의 공통적이지 않은) 케이스를 완벽하게 처리하므로, git에서는 특별한 지원이 필요하지 않으며 결코 존재하지 않을 것이라고 가정 할 수 있습니다.

+0

공정한 .... – gcbenison