모든 코드가 결국 요청 코드 검토를 거치도록하기 위해 우리는 기능에 대한 브랜치와 git-flow style을 따르는 개발 중 버그 분기를 만들기 시작했습니다.분기 분기 및 버그 수정을위한 gitflow 프로세스가 있습니까?
유일한 문제는 릴리스 분기에서 버그가 발견되면 릴리스 분기로 다시 풀 요청을하기 위해 릴리스 분기에서 분기를 만들어야한다는 것입니다. 그러나 버그가 릴리즈 브랜치 (bug)를 수정할 때 릴리즈 브랜치의 브랜치를 처리하는 명백한 git-flow 프로세스가없는 것 같습니다.
릴리스 분기 버그 및 코드 검토를 해결하기위한 git-flow 프로세스는 무엇입니까?
버그를 수정하고 새 릴리스 지점을 만드시겠습니까? 릴리스 분기의 분기가 유효한 git-flow입니까? 릴리스 지점 버그 수정에서 끌어 오기 요청 코드 검토를 처리하는 가장 좋은 방법은 무엇입니까?
내가 처리하는 방법은 릴리스 지점에서 핫픽스 분기를 갖는 것입니다. 버그를 고친 후에 나는 master/release 브랜치에 병합 할 것이고 Dev 브랜치로 합쳐져서 다른 기능으로 넘어 간다.
master 또는 dev에 기록되므로 핫픽스가 삭제됩니다.
버그 수정 분기는 마스터 (또는 프로덕션 코드를 나타내는 모든 분기)에서 분기되어야합니다. git flow를 사용하고있는 경우에는, 브랜치 (branch) 코드의 변경을 벌써 완료 한 경우, 버그 수정 브랜치 (branch)에 커밋을 선택해야 할 필요가있는 경우가 있습니다.
그래서 본질적으로 정기적으로 버그를 수정하고 gitflow 분기를 수정 한 다음 코드 검토를 통해 배포 분기를 선택합니다. –
아니요, 이전에 "핫픽스"로 선언 한 지점에서 이미 버그가 수정 된 경우에만 수행합니다. 그래도 버그를 수정해야한다면, 그 버그를 수정하고 일반 릴리즈와의 동기화를 해제하기 위해 master의 새로운 브랜치를 만듭니다. –
방금 전이 문제와 관련이있었습니다. 내가 릴리스 지점에서 정상적인 지점을 만드는 것이 좋습니다. 거기서 수정하고 릴리즈 분기에 병합 할 해당 분기에 대한 풀 (pull) 요청을 만듭니다. 이것은 Git Flow 명령이 아닌 일반 분기 및 병합 명령을 사용하고 있습니다.
단계의 세부 사항. 여기서 2017.05.24는 릴리스 지점의 이름입니다.
희망. Git-flow 명령에서 많은 단계와 브레이크가 있지만 풀 요구가 발생할 수 있어야합니다.
plus 1 - 이것은 내가하는 일에 관한 것입니다. 이것을하기위한 공식적인 gitflow 방법이 있었으면 좋겠다. –
아직 마스터에없는 새로운 기능에 대해서는 아직까지 언급되지 않았습니다. – smurphy
기능은'dev'에서 분기 될 것이고 일단 기능이 완료되면'dev'에 병합되고'dev'에 충분한 기능이 축적되면'master'에 릴리스로 병합됩니다. –
@smurphy 기능은 이전 릴리스의 핫픽스/버그가 아닐 수도 있습니다. 새로운 기능은 dev에서 나온 것이고 Mike가 제안한 것과 같은 새로운 릴리스로 발표 될 것입니다. – HankCa