피쳐 브랜치에서 작업 할 때 리팩토링해야하는 코드가 브랜치와 관련이 없다는 것을 제외하고는 내가 작업하고있는 동일한 파일에 있음을 발견했습니다.피쳐 브랜치에서 접선 리펙터 러블 코드를 처리하는 방법
새 사용자 스토리를 만들어야하나요?
또한 코드 리팩터링을위한 사용자 스토리를 작성 하시겠습니까?
작은 수정 사항의 경우 PBI 및 수정할 분기를 만드는 것이 정당한가?
가장 가까운 관련 사용자 이야기를 찾고 시도하는 것이 바람직하지 않은 관행입니까?
대답은 팀이 사용자 스토리와 작업 및 리팩토링에 대한 접근 방식을 사용하는 방법에 따라 달라집니다. 그들은 당신이 항목을 작업하는 커밋을 연결하는 강제 임의의 정책이있는 경우
을 커밋하는 작업 항목을 연관
은, 당신은 정책을 무시하거나 연결해야 하나. 이 연관성은 릴리스의 모든 변경 사항을 볼 수 있도록 일종의 릴리스 보고서에 필요합니다. 아마도 팀이 연관 시간을 사용하여 작업 시간을 추적하고 있습니까? 그렇다면 커밋을 연결할 작업을 만듭니다.
그래서 답변은 팀에서 연결을 사용하는 방법에 따라 다릅니다. 과거에는 리팩토링을 연관시키기 위해 User Story "Improve Component X"를 사용했습니다. 이 사용자 스토리는 개선 사항을 추적 할 수있는 장소로 열려 있습니다. 일반적인 조언은 불필요한 노력 (예 : 작업이 실제로 가치있는 용도로 사용되지 않을 때 작업 만들기)을 피하고 가능한 가장 간단한 작업을 수행하는 것입니다. 리팩토링을 가능한 한 쉽게 만들고 싶습니다.
기능과는 다른 시간에 본선에 갈 수있는 리팩토링 필요가
을합니까 분기? 그렇다면 별도의 지점이 필요합니다. 리팩토링 기능을 기능과 동시에 사용할 수있는 경우 기능 브랜치에서 리팩터링을 간단하게 유지하십시오. 적어도 리팩토링을 위해 별도의 커밋을 사용합니다.
안녕하세요 아담 것 당신은 대답을 http://softwareengineering.stackexchange.com/questions/342503/how-to-address-tangential-refactorable-code-in-a-feature-branch에 복사하십시오. 소프트웨어 엔지니어링 SE는이 질문에 대해 더 나은 결과를 보았습니다. 저는 KISS-esque 솔루션을 높이 평가하고 있으며, 현재 대표적인 의견을 제시하고 있습니다. –
십자가에 답변을 게시했습니다 - 감사합니다. –
교차 게시 : http://softwareengineering.stackexchange.com/questions/342503/how-to-address-tangential-refactorable-code-in-a-feature-branch –
@DanCornilescu 덕분에 댄 –