코드베이스의 다른 부분에서 작업하는 동안 버그 수정

이것은 나에게 적어도 한 번 일어났다. 코드베이스의 일부를 작업 중이며 다른 부분에서 작은 버그를 발견하면 버그로 인해 현재하려는 작업을 완료하지 못합니다. 버그를 수정하는 것은 단일 명령문을 변경하는 것만 큼 간단 할 수 있습니다.

그 상황에서 무엇을합니까?

1. 버그 수정 및 현재 작업과 함께 커밋
2. 다른 곳에서 현재 작업을 저장하고 별도의 커밋으로 버그를 수정 한 다음 작업을 계속하십시오 [1]
3. 해야 할 일을 계속하고 코드를 커밋하십시오 빌드를 중단 몇 가지 테스트에 실패) 버그를 수정 (및 빌드 별도의 커밋에서 테스트를 통과)

[1] 실제로 이것은 원래 저장소를 다른 곳에서 복제하고 버그를 수정하고 변경 사항을 커밋 / 푸시하고 작업중인 저장소로 커밋을 가져오고 변경 사항을 병합하고 작업을 계속한다는 것을 의미합니다.

편집 : 나는 실제로 의미하는 것을 반영하기 위해 3 번을 변경했습니다.

나는 1과 2를했으며 결국 # 2를 선호한다고 생각합니다. QA / 릴리스 노트 / 기타 개발자에게 중요 할 수있는 버그 수정에 대한 더 많은 가시성을 제공합니다.

나는 또한 내가 생각한 버그가 실제로는 아니었다 고 생각하는 상황을 보았습니다 (여기서는 그렇지 않다고 말함). 다른 커밋으로 버그를 "고정"하면 다른 개발자가 저에게 연락하여 무엇이 무엇인지 설명 할 수 있습니다 정상적인 체크인시 "수정"대신에 길을 잃었습니다.

나는 일반적으로 # 2로갑니다. 리포지토리를 더 깨끗하게 만들고 로그를 더 이해하기 쉽게 만듭니다. 다른 개발자가 동일한 커밋에서 15 가지 버그 수정, 기능 및 리팩토링 커밋으로 작업 할 때 나는 그것을 싫어합니다.

또한 팀에서 결함 추적을 수행하는 방법에 따라 결함 리포지토리를 검색하여 수정중인 결함이있는 경우 해당 항목을 완료로 표시해야합니다. 또는 결함 시스템과 코드 저장소가 일치하도록 새 항목을 작성하고 완료로 표시해야 할 수도 있습니다.

나는 # 2를한다. git과 같은 도구를 사용하면 여러 커밋으로 나누는 것이 쉽지 않습니다. 팀이 더 현대적인 도구로 전환하도록 설득력이 없다면 git-svn 은이 문제를 해결하는 데 사용하는 것의 적절한 부분을 제공합니다. 이 블로그 게시물은 해결하기 위해 노력하고있는 워크 플로우의 좋은 개요를 제공 힘내 소개 살아라을

작성되지 않은 옵션 (4)을 선택합니다. 프로젝트를 고도로 전문화 된 어셈블리 / 라이브러리로 나누면 관련없는 버그가 항상 버전 제어 트리에서 다른 위치에있게됩니다.

위의 소리가 들리면 죄송하지만 진심으로 의미합니다. 나는 서로 관련이없는 수백 가지 양식과 네임 스페이스가있는 모 놀리 식 프로젝트를 볼 때마다 울었습니다. 나는이 같은 딜레마에 자주 직면하여 다른 기능 영역을 다루는 커밋을 어떻게 그리고 어떻게 분리해야하는지 궁금해했다. 단 한 번의 커밋 가능한 프로젝트에서 이러한 서로 다른 기능 영역을 모두 갖는 것이 그 자체로 주요 디자인 결함이라는 것을 깨달았을 때까지는 훨씬 이르지 않았습니다.

특정 기능을 작업하는 동안 여전히 관련없는 버그를 자주 발견합니다. UI에서 작업하고 일부 비즈니스 로직에서 버그를 발견 한 후 계속 진행하기 전에 수정해야합니다. 차이점은 비즈니스 로직이 항상 UI와 다른 어셈블리 / 프로젝트에 있다는 것입니다. 따라서 BL에 약간의 변경을 한 다음 매우 작은 커밋을 계속 수행하고 계속 작업하면됩니다.

정말 좋은 프로젝트 조직을 보유하면 변경 사항을 묻거나 빌드를 중단하거나 자극적 인 브랜치 / 병합에 빠져들지 않고도 이러한 문제를 처리 할 수있을뿐만 아니라 이러한 문제를 쉽게 처리 할 수 ​​있습니다 (DVCS를 사용하는 경우에도 전혀 고통스럽지 않습니다) ).

이 옵션이 부족한 경우 (예 : 프로젝트 조직에서 아무 말도하지 않는 주니어 개발자), 나는 단순히 # 1로 가서 로그에 적절한 메모를 작성하여 다른 사람들이 왜 당신이 한 일을했는지 ​​알 수 있습니다. 크게 변경 한 경우 문제 추적 시스템에 버그 보고서를 제출하여 수정 한 내용과 이유를 파악할 수 있습니다.

# 2를하려고합니다. 실제로 별도의 문제인 경우 작업중인 파일과 다른 파일에있을 가능성이 높습니다. 작업중인 동일한 저장소에서 파일을 작성하더라도 별도의 커밋으로 파일을 체크인 할 수 있어야합니다. 이미 언급 된 모든 이유로 인해 변경 사항을 추적하고 잘못 변경 한 경우 되돌릴 수 있도록 가능한 한 독립적으로 커밋을 수행하는 것이 좋습니다.

나는 보통 버그를 고친 다음 작업하고있는 것을 계속한다. 커밋해야 할 때, 버그 수정이 별도의 파일에 있다고 가정하면 두 개의 동시 커밋을 수행 합니다. 첫 번째는 버그 수정 만 포함하는 부분 커밋 이고 두 번째는 다른 것입니다.

짧은 답변: # 2. 버전 기록에 해당 버그 수정 (트래커에 메모와 함께!)이 별도의 엔티티로 태그되어 있어야합니다.

더 긴 답변 :

• 버그를 우연히 발견
• 버그를 보여주는 테스트 또는 더 작성
• 시험 합격
• 단지 변화와 그 테스트를 커밋 ( git add --interactive또는darcs record -i VCS에서 수행) (*)
• 내가했던 일로 돌아가

(*) CVS에서 (아니, 실제로) 때때로 깨끗한 나무와 내가 작업 한 사본을 체크 아웃했습니다. 그런 다음 병합 (Winmerge)을 사용하여 버그 수정을 깨끗한 트리로 가져 와서 별도로 커밋 할 수 있습니다. 다른 옵션은 변경된 파일의 이름을 바꾸는 것입니다.cvs update 병합하는 것입니다. 변경 내용을 커밋하면 파일을 제거하고 이동 한 파일의 이름을 원래 이름으로 다시 바꿉니다.

그러나 주목할 점은 일반적으로 내가 작업하고있는 것과 관련이 있거나 어휘 근접성에 가까운 버그만 발견한다는 것입니다. 사람들이 코드베이스의 관련되지 않은 부분에서 버그를 찾는 것이 정상이라면 놀랄 것입니다. 버그를 수정할 때 왜 관련없는 코드를 읽습니까? (예, 이것은 Aaronnaught와 정확히 반대입니다!)

버그를 수정하고 각 수정 / 기능마다 하나씩 별도의 커밋을 수행 합니다.

대부분의 경우 변경 사항이 동일한 파일에 없으므로 커밋을 쉽게 분리 할 수 ​​있습니다. 변경 사항이 동일한 파일에있는 경우 TortoiseHg (mecurial GUI 프론트 엔드)를 사용하여 커밋하려는 diff를 정확하게 선택합니다 (명령 줄에서 명령을 수행 할 수 있다고 생각합니다. Record extension 하지만 덜 편리합니다) ).

일부 사람들 은 기능에 대해 작업하는 동안 Mercurial Queues 를 사용하여 사소한 수정 사항을 분리합니다. 사소한 수정 사항은 MQ에 누적되며 기능이 완료되고 커미트 될 때 큐의 컨텐츠도 커미트됩니다 (대기열의 각 항목마다 하나의 변경 세트).

나는 보통 # 2를한다. 현재 작업을 다른 곳에 저장 : 일반적으로 패치를 작성하면 정상적으로 작동합니다. 또한 일부 IDE (IntelliJ)를 사용하면 현재 작업을 다른 곳에 저장하면됩니다.

내가하는 일은 버그가 실제로 다른 부분에 있는지 여부에 달려 있습니다. 그렇다면 체크인은 반 변경과 무관합니다. 나는 변화를 만들고, 다른 부분을 만들어서 사소한 오류가 발생하지 않았는지 확인하고, (아마도 내가하지 못하게하는 일을함으로써) 테스트하고, 무슨 일이 일어나고 있는지 설명하면서 확인하십시오. 종종 작업 항목을 만들고 체크인 / 해결 후 WI를 테스터에게 할당합니다. 그런 다음 내가하고 있던 일로 돌아갑니다.

내가 반으로 변경 한 파일로 인해 문제가 발생하면 해당 부분을 독립적으로 빌드하고 테스트 할 수 없습니다. 이 경우 다른 WI를 만들고 변경 사항을 체크인하면 동일한 체크인으로 두 WI를 모두 해결합니다. 이는 일반적으로 원칙에 위배되지만이 경우에는 잘 적용됩니다.

두 가지 상황에서 버그 수정은 내가 테스트 한 결과 일종의 흔적으로 체크인되어 사람들이 그 날 그 코드를 무작위로 변경 한 이유를 이해하고 WI가 다른 사람에게 할당되어 현재 올바른지 확인합니다.

우리는 # 1을합니다. # 2는 잘 들리지만 # 1에 문제가있어 # 2가 고칠 것이라고 말할 수는 없습니다.

우리 회사의 또 다른 요소는 우리가 웹 앱을 구축한다는 것입니다. 테스트는 거의 전적으로 웹 인터페이스를 통해 이루어집니다. 대략 사람들이 단위 테스트가 아닌 기능 테스트라고합니다. 우리는 체크인하기 전에 모든 테스트를 통과했습니다. 커밋을 작은 비트로 나누면 각 비트에 대해 테스트를 한 번 실행하는 데 더 많은 시간이 걸립니다. 훨씬 더 빠른 테스트 스위트를 갖고 싶습니다. 더 작은 커밋을 수행 할 수는 있지만 우리는 그것을 가지고 있지 않습니다.