기능 분기에서 작업하는 동안 코드 품질을 개선해야하는 경우

11

코드 / 캠프 사이트를 찾은 것보다 더 좋은 상태 로 유지하는 방법에 대한이 기사를 정말 좋아 합니다. 실제 환경에서는 코드 청결도를 유지하는 실용적인 방법 인 것 같습니다.

또한 피처를 독립적 으로 개발하는 방법으로 피처 브랜치 를 좋아 하므로 마음에 들지 않으면 쉽게 병합 할 수 없습니다.

그러나 기능 분기에서 작업 중이고 못생긴 코드가 발견되면 수정해야합니까?

그것을 고치는 데 많은 단점이있는 것처럼 느낍니다.

분기를 다시 병합하면 diff가 지저분하고 변수 이름 바꾸기 또는 함수 추출로 복잡해집니다.
이 기능이 중단되면 정리 커밋을 선택해야합니다 (이것은 근처의 코드가 지저분한 병합을 어떻게 변경했는지에 따라 작동하거나 작동하지 않을 수 있음). 다시 실행하거나 포기하십시오.

반대로, 내가 파일에있는 동안 그것을하지 않으면 분명히 지점을 병합 할 때 며칠 안에 그것을 잊어 버릴 것입니다.

나는 이것이 의견에 근거한 것이라는 경고를 should받았지만 ( 제목에 포함 된 사실을 벗어난 것 같아요 ) 대답이 있다고 생각합니다 (확실히 사람들은이 두 가지 방법을 모두 사용하므로 대답이 있어야합니다). 또한에 관한 질문은 development methodologies주제에 관한 것이며 어느 정도의 의견이 필요하다고 생각합니다.

refactoring code-quality branching

— 킬리
소스

1

모든 개발이 브랜치에있을 때 리팩토링하는 방법에 대한

— gnat

@gnat 유용한 읽기 감사합니다. 시간이 오래 걸리는 가지에 관한 것이기 때문에 나는 그것이 속임수라고 생각하지 않습니다. 나는 기능 브랜치 dev로 리팩토링에 대한 좋은 캠프 방식을 조정하는 방법에 대해 구체적으로 묻고 있습니다.

— T. Kiley

프로젝트가 진행중인 개발 단계에 따라 달라집니다. 프로젝트가 상당한 양의 테스트를 거쳤고 현장에 들어간 경우 수정해야 할 부분에 속하지 않는 것을 변경하는 것은 매우 위험하다고 생각합니다. 많은 사람들이 아무 것도 영향을 미치지 않아야 할 것들을 바꾸는 버그를 삽입했습니다. 프로젝트가 개발 단계에 있다면 코드가 더 깨끗하게 시작하는 것이 좋으므로 필요한 경우 전체 파일을 정리합니다.

— 덩크

8

어쨌든 기능의 일부로 해당 코드 조각을 변경하는 경우 기능 분기에서 코드를 '수정'해야합니다.

예 : '토끼 인쇄'기능을 작업 중이며 프린터 코드를 찾습니다.

Public class Printer(string type)
{
    If(type=="bunnies")
    {
        //print a bunny
    }
.....
}

나는 그것을 다음과 같이 바꾼다.

Public class Printer(string type)
{
     PrintFunctionDictionary[type].Print();
}

왜:

코드 작업 중입니다.
기능을 추가하려면 변경해야합니다.
추가 된 기능은 문제를 해결하는 리팩토링 된 방법을 제안합니다.

나는 코드베이스의 다른 부분에 무작위로 충돌하지 않고 다음과 같이 '더 좋게 만듭니다'.

다른 기능을 사용하는 사람들과 충돌하십시오.
기능 개발에 할당해야하는 시간을 사용하십시오.
기능이 완료되지 않은 경우 기본 제품에 병합되지 않을 수있는 분기에 임의 코드를 추가하십시오. 마찬가지로, 기능을 롤백하면 리팩토링이 손실됩니다.

— 이완
소스

1

나는 이것이 시도하는 것이 좋으며 이상적인 세상에서는 이것이 항상 효과가 있다는 데 동의합니다. 그러나 실제 코드에서는 상황이 더 복잡합니다. 기능을 작업 할 때 일반적으로 기능과 독립적으로 리팩터링해야 할 코드 부분을 찾을 수 있습니다. 이 코드는 기능의 구현을 방해 할 수 있지만 기능과 직접 관련된 메소드 나 클래스로 제한되지는 않습니다. 그리고 변화가 반드시 다른 사람들을 방해하지는 않습니다.

— Doc Brown

1

물론 별도의 리팩토링 브랜치를 할 수 있습니다. 내가 알 수 있듯이 기능 분기는 주로 "기능 X는 완료되지 않았지만 다른 모든 기능과 함께 릴리스 할 수 있습니다"와 "기능 X는 릴리스되었습니다"라는 기능을 수행하는 프로젝트 관리 작업이지만 기능 Y가 변경되는 것을 기대하지는 않습니다. 기능에 리팩토링을 추가하면 다음과 같은 이점을 누릴 수 있습니다.

— Ewan

5

리팩토링이 현재 기능 분기에서 "무관심하게"유지되도록하려면 변경하지 마십시오. 대신 기본 개발 지점 (또는 팀에서 변경 사항을 개발자 지점에 직접 적용하지 않는 경우 "리팩토링 지점")에서 리팩토링을 수행하십시오. 따라서 귀하를 포함한 모든 팀원이 변경 사항을 작업중인 활성 기능 분기에 병합 할 수 있습니다. 그러나 동료들에게 먼저 허가를 요청하지 않고 "코드베이스의 절반"에 전역 리팩토링을 적용하지 않도록주의하십시오.

여기서 개선 사항이 해당 기능 분기에서 정확히 터치하는 코드베이스 부분에 국한된 경우 "새 기능"과 다른 수명주기를 제공하는 것은 의미가 없습니다.

— 닥 브라운
소스

3

branch형식 의 목적은 형식 을 처리 하기위한 의도 를 제공 하는 것입니다. 유형이 좋아하는 당신은 분기의 GitFlow 스타일을 다음과 같은 경우, 당신은 가능성이 feature, hotfix, release, 등 기능 지점의 경우, 그 의도는 다른 지점 (즉,로 병합을 캡슐화하는 것입니다 develop)에 대한 것을 보여준다 개발자 책임 병합,이 기능이 무엇인지. 정리하는 코드가 해당 기능의 일부가 아닌 경우 변경하지 마십시오.

대신, 못생긴 코드가있을 가능성이 가장 낮은 분기를 찾아서 그 지점에서 분기하십시오 develop. 코드를 변경하고 기능으로 병합하도록 제안하십시오. 현재 작업중인 코드가 필요하고 특히 병합 충돌을 피하려면 해당 분기를 분기로 병합하십시오.

다음은 다양한 전략에 대한 좋은 설명입니다. https://www.atlassian.com/git/tutorials/comparing-workflows/

— 톰 쇼버
소스

0

기능 분기에서 작업 중이고 못생긴 코드를 발견하면 수정해야합니까?

프로젝트의 템포, 코드의 '추 악성'등에 따라 '추악한 코드'를 수정하는 것이 좋을 수도 있지만 기능 분기 자체 에서이 작업을 수행하지 마십시오.

기능 분기가 완전히 로컬 인 경우 저장되지 않은 변경 사항을 숨기거나 커밋하려면 개발 분기를 확인하고 변경 한 후 기능 분기로 돌아가서 개발을 중단하십시오.
개발을 리베이스 할 수없는 경우 (예 : 기능 브랜치가 퍼블릭 서버에 있음) 개발이 필요하거나 나중에 충돌을 피하려는 경우 여전히 커밋을 해제 할 수 있습니다.
파일을 편집 중이고 실제로 수정을 못생긴 코드에 커밋해야하고 실제로 개발로 전환 할 수없는 경우 수정, 수정에 사용 git add -p, 변경 만 커밋 , 병합 / (실제로 다음 커밋 후에) 푸시, 대화식 리베이스를 사용하여 해당 커밋을 지점에서 가능한 한 가장 빠른 지점으로 옮기거나 심지어 역사에 따라 개발에 체리 피킹 할 수도 있습니다.

또한 개발 브랜치를 '고정'하는 다른 방법으로도이 작업을 수행합니다 ( '수정'은 코드가 표준을 준수하도록 사용자 또는 다른 개발자가 눈에 띄는 변경 사항 임). 이것은 도움이됩니다 ...

수정 사항과 기능이 다른 그룹에 커밋되어 로그를 더 읽기 쉽게하기 위해,
개발을 언제든지 릴리스 할 수 있도록 최대한 가깝게 유지
작업의 중복을 피하기 위해 (여러 사람들이 다른 지점에서 미묘하게 다른 방식으로 동일한 문제를 해결).

— 사용자
소스