병합 된 브랜치를 재사용하는 것이 좋습니다.

현재 응용 프로그램에 새 기능을 추가해야 할 때마다 새 분기를 만들었습니다.

기능이 완료되고 작동하면 마스터 브랜치와 병합합니다.

그러나 나중에이 기능 (예 : 개선 사항)을 업데이트해야 할 때 새 분기를 만드는 것이 더 낫거나 마스터로 이전 분기를 리베이스 해야하는 경우 업데이트를 수행 한 다음 다시 병합합니까?

예를 들어 Ruby on Rails 애플리케이션에 modeling-member라는 브랜치가 있습니다. 나중에 멤버 모델 (이 분기에서 작성된)에 일부 속성을 추가해야합니다. 어떻게해야합니까? 이 브랜치를 마스터로 리베이스하고 모델을 업데이트 한 후 다시 병합하거나 단순히 새 브랜치를 생성합니까?

다음과 같은 이유로 새 분기를 만듭니다.

• 완전히 새로운 브랜치가 완료되면 병합 충돌이 발생하지 않으며 마스터로 병합하려고합니다. 병합 충돌을 수정하는 것보다 오류가 발생하기 쉬운 것은 거의 없습니다.

• 이 기능은 원래 구현 이후 여러 변경 및 업데이트를 거쳐 원래 분기가 완전히 사용되지 않을 수 있습니다. 최신 상태로 유지하는 유일한 방법은 마스터를 기능 분기에 병합하는 것입니다.이 시점에서 불필요하게 복잡한 방식으로 마스터를 분기합니다.

• 단순성을 위해서만 업데이트, 버그 수정 및 새로운 기능에 대해 동일한 워크 플로를 갖는 것이 좋습니다. 이는 브랜칭, 코드 검토, 버그 추적기 사용법 및 기타 모든 것에 적용됩니다. 기존 기능 업데이트, 새 기능 추가 및 버그 수정의 차이점은 종종 주관적입니다.

새로운 지점을 사용하십시오.

이름 지정을 위해 this_work 가 확장이거나 that_work로 변경 되는 내부 형식 사용을 고려할 수 있습니다.

예를 들어 두 번째 지점의 이름을 지정할 수 있습니다

modeling-member--attributes

-왼쪽의 이름 이름이 원래 브랜치라는 신호

지사 이름에 Jira 티켓 번호를 사용할 때 비슷한 문제를 해결합니다. 때때로 같은 티켓에 대한 추가 작업이 있습니다. 때때로 데이터베이스 변경 사항을 롤백 할 수 없습니다. 이러한 경우, 예를 들어 원래 지점 SEND-123과 두 번째 지점을 SEND-123a로 사용합니다.

마스터의 병합에서 커밋 만 저장하고 github을 사용하는 경우 모든 새 기능에 "Fork"를 사용하고 모든 새 기능이 완료된 후 풀 요청을 수행하고 풀 요청을 수락 할 수 있습니다.

나는 오래된 지점에서 일하는 것을 권장하지 않습니다. 왜냐하면 마스터 헤드에 병합 할 때 충돌이 생길 수 있으며 물론 할 필요가 없기 때문에 ...