Resolve merge conflict between issue #25 and #34

[Queue-ri]

문제상황

feature/34 -> develop으로 merge를 시도하는 과정에서 auto merge가 불가함을 인지

브랜치 상태

2d7137f 와 c8137e7 이 서로 충돌하는 것으로 추정됨

원인

1. 신규 기능 개발이 동시다발적으로 짧은 기간에 이루어지는 상황에서, 이전에 작성한 PR(feature/25)의 리뷰가 비교적 늦어짐
2. 1에 의해 feature/34는 feature/25가 merge되지 않은 develop의 revision에서 파생
3. feature/34에서 feature/25의 변경사항에 포함된 파일을 수정
4. 3에 의해 feature/34를 그대로 merge할 수 없게 됨

해결방안

1. feature/34에서 conflict가 발생하는 파일은 stock 도메인의 mapper 파일임을 확인 (stockMapper.xml, StockMapper.java)
2. 해당 파일 관련 commit이 브랜치의 최상단에 놓여있지 않으므로, 별도의 브랜치에 conflict 문제가 없는 commit을 cherry-pick
3. 문제의 commit을 마지막으로 체리픽하고 git reset
4. mapper 파일을 제외한 나머지 파일 다시 commit
5. 신규 브랜치를 feature/34로 재지정하고 force push
6. 3으로부터 돌려받은 mapper 파일 수정사항 백업하고 discard changes
7. develop을 pull한 후 resolve/34 브랜치 생성
8. 7의 브랜치에서 문제의 mapper 파일 수정
9. resolve/34를 본 이슈와 연결하여 PR

결과

충돌 해결 완료~

참고

관련 commit message에도 해당 이슈를 기록.

resolve 정책은 팀마다 다를 수 있습니다.

[gunny97h]

이번 이슈를 통해 충돌 관리 및 브랜치 전략의 중요성을 느꼈습니다. 향후 작업 시 충돌 가능성을 줄이기 위해 작은 단위로 더 자주 머지, 브랜치 간 의존성 최소화 등의 개선 방안을 논의하면 좋겠습니다.

[Queue-ri]

이번 이슈를 통해 충돌 관리 및 브랜치 전략의 중요성을 느꼈습니다. 향후 작업 시 충돌 가능성을 줄이기 위해 작은 단위로 더 자주 머지, 브랜치 간 의존성 최소화 등의 개선 방안을 논의하면 좋겠습니다.

맞아요!
실제로 이러한 오픈소스 프로젝트들은 리뷰가 매우 신중하고 오래 걸리기 때문에
한 브랜치의 작업 단위를 크게 잡지 않는 것이 conflict 가능성을 줄이는 방법 중 하나입니다.

상당히 생산적이고 저에게도 생각의 여지를 주는 좋은 코멘트네요. 감사합니다!