리팩토링은 GitFlow 지점 이름 지정 모델에서 어디에 속합니까?


22

최근 비트 버킷으로 구현 된 GitFlow 모델 작업을 시작했습니다. 그리고 나에게 완전히 분명하지 않은 것이 있습니다.

리팩토링 작업을 백 로그, 계획 및 구현하여 기술 부채를 정기적으로 해결하려고합니다. 이러한 리팩토링 브랜치는에 병합 된 풀 요청으로 끝납니다 develop. 내 질문은 리팩토링 브랜치가 GitFlow에서 어디에 속합니까 ?

  • feature접두사를 사용 하는 것이 가장 논리적으로 보이지만 리팩토링은 새로운 기능을 추가하지 않기 때문에 완전히 올바른 느낌은 아닙니다.
  • 그러나 bugfix접두사를 사용하는 것은 실제 버그 리팩터링 수정 이 아닌 것 같지 않습니다 .
  • 반면에 사용자 지정 접두사를 만들면 과도하게 엔지니어링하지 않으면 복잡해 보입니다.

그런 상황이 있었습니까? 이 문제를 해결하기 위해 어떤 연습을 사용하십니까? 이유를 설명하십시오.


왜 리팩터링을위한 브랜치가 필요합니까? 정의에 따라 제품의 기능을 변경하지 않으므로 개발시 직접 수행 할 수 있어야합니다.
jonrsharpe

@jonrsharpe는 간단히 말하면 더 편리하고 제어 가능합니다. 일반적으로 리팩토링을위한 Jira 티켓이 있으며 풀 요청 중에 코드를 검토합니다. 또한 빌드 및 테스트가 병합되기 전에 실행됩니다. 우리는 지점을 녹색으로 유지하려고 노력합니다.
AMA

4
이 경우 프로세스를 과도하게 엔지니어링하고 있습니다. 개별 작업 패키지가 아니라 시스템에서 작업 할 때 리팩토링하십시오.
Mr Cochese

2
그 경우 : 1. 당신은 나의 동정심을 가지고 있습니다. 2. use이라고 말하면 refactor각 병합이 제품에 어떤 변환을 수행해야하는지 분명합니다 (버그 픽스 : 깨진 동작 수정, 기능 : 새 동작 추가, 리팩터링 : 이전 동작 유지). 그러나 @MrCochese는 옳습니다. 실제로 별도의 작업이 아닌 다른 작업의 일부 여야합니다. 또한 리 팩터가 빌드를 중단하면 리팩터링되지 않습니다!
jonrsharpe

당신이하고있는 리팩토링 작업 중 일부는 실제로 주요 작업의 일부 여야합니다. 나는 리 팩터 브랜치를 일상적으로 만들지는 않지만 더 큰 정리 노력의 일환으로 만 할 것입니다. 이를 습관화하면 정리 작업을 "리 팩터"브랜치로 연기하는 것과 같은 다른 나쁜 습관을 장려 할 것입니다.
Robert Harvey

답변:


27

리팩토링 작업은 기능 분기로 진행되어야합니다.

접두사 "feature"는 개별 프로그래밍 작업을 설명하는 단어 일뿐입니다. 원하는 단어를 선택할 수 있습니다. 개발의 모든 분기는 "feature"분기 또는 "release"분기입니다.

"리팩토링"과 같은 새로운 접두사를 추가하는 것은 문제가 있습니다. 기능을 추가 할 때 리팩토링을하는 경우가 많으므로 이름 지정 문제와 혼동을 추가하기 만하면됩니다. 즉. "우리의 기능 분기 중 일부는 '리팩토링'이라고하며, 모든 리팩토링 작업을 포함하지 않으며 때로는 버그 수정이나 기능이 포함되어 있습니다. '

마찬가지로 "핫픽스"브랜치는 핫픽스를 포함하기 때문에 핫픽스라고하지 않지만 개발보다는 마스터에서 분기하기 때문에


1
감사합니다. 이것은 합리적으로 들립니다. 조금 더 기다릴 것이고, 다른 답변이 없으면 당신의 것을 받아 들일 것입니다.
AMA
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.