논란의 여지가 적은 것부터 답변 드리겠습니다.

2번 질문: 예. git flow feature finish foo 명령의 기본 동작은 feature/foo 브랜치를 삭제하는 것입니다. 모든 기능브랜치는 develop에 통합되어 사라질 목적을 갖는다고 보시면 됩니다. 오히려, "아직 이 기능브랜치 삭제하면 안돼요" 하고 남겨두고 계속 가져가는 기능브랜치가 있다면, 그게 더 문제입니다.

4번 질문: 그냥 머지받으시면 됩니다. 애초에 "dev브랜치에서 다시 prod브랜치 소스를 땡겨"오는 것 자체가 항상 해야 하는 일입니다. git flow release finish bar 명령의 기본 동작은 release/bar 브랜치를 master에 붙이는 것뿐만이 아니고, 그 직후의 master를 develop에 붙이는 것까지 포함돼 있습니다. 머지를 받고 있는 거죠.

git flow를 모범적으로 따를 경우, 항상 master보다 develop이 더 큽니다. 가장 최신 develop은 가장 최신 master를 모두 갖고 있어야 합니다.

3번 질문: 각 피처가 끝났다고 해서 그걸 무조건 finish 해서 develop에 붙일 필요는 없습니다. 일단 feature/a만 끝내서 그 상태의 develop을 릴리즈하고, 그 다음 feature/b를 끝내서 b 기능을 가진 develop을 릴리즈하는 순서대로 하면 됩니다.

그게 정 안 되면, 그러니까 이미 git flow feature finish a도 해버렸고 git flow feature finish b도 해버렸는데 이번 릴리즈에는 a만 내보내야 할 경우... 다음과 같이 할 수 있을 겁니다.

1. git flow release start without-b
2. git checkout release/without-b (git flow 기본동작에 의해 자동 수행됨)
3. feature/b가 develop에 병합된 커밋의 SHA 일련번호 확인 (ex: f00ba1)
4. git revert f00ba1
5. 위 리버트에 의해 발생한 커밋의 SHA 일련번호 확인 (ex: abc123)
6. git flow release finish
7. git checkout develop (git flow 기본동작에 의해 자동 수행됨)
8. git revert abc123

요컨대 릴리즈를 할 때에 한해서만 b 기능 관련 변경점을 제거하고, 다시 develop에서 원복시킨다는 것이죠. 이해가 되시나요?

1번 질문: 기본적으로 맞는데, 왜 그러한지에 대해서는 기본 원칙을 기준으로 이해하시면 좋을 듯합니다. develop 브랜치의 기본 개념은, 여러 기능들이 모두 합의해야 하는 공통된 최신 정보를 공유하는 브랜치라는 것입니다.

• develop 브랜치에서는 항상 새 기능 개발을 시작할 수 있음
• 어떤 기능브랜치 개발을 종료할 때는, 항상 최신 develop 브랜치 기준으로 충돌/모순이 없어야 함
• 최신 develop 브랜치는 최신 master 브랜치 내용을 모두 가지고 있음

바로 이런 맥락에서 develop 브랜치를 개발자 테스트 브랜치로 쓸 수 있는 것이지요. 애초에 "테스트서버 배포용" 브랜치는 release 브랜치를 쓰는 편이 좋을 겁니다. (사실 릴리즈 브랜치란 것 자체가 이런 용도 말고는 별로 쓸모가 없지요.)