실수로 실서버에 적용한 내용을 되돌리기 위해 Revert 작업을 수행하던 과정에서 겪었던 혼란.
1. 문제 상황
실서버 브랜치에서 갈라져 나온 A 브랜치에서 작업을 했다고 가정하자. 이때 A 브랜치에서 작업이 완료되었는데 실수로 테스트 서버 브랜치가 아닌 실서버 브랜치로 병합을 시켰다고 해보자. 그러면 우선 실서버 브랜치에서 Revert 브랜치를 만들어서 실서버 브랜치로 그걸 다시 병합시켜야 한다. 그래야 실서버에 적용된 A 브랜치의 작업 내역이 그대로 원상 복구될 것이다.
하지만 이렇게 한다고 해서 끝이 아니다. 이후 QA(Quality Assurance) 등의 과정을 통해 추가 개발 요구 사항을 전달받을 수도 있는데, 기존의 A 브랜치에서 추가 작업을 하고 실서버 브랜치에 병합을 시키면 충돌이 발생하기 때문이다. 왜 그럴까? 다음과 같이 생각해 보자.
A 브랜치를 실서버 브랜치에 (실수로) 병합시킨 이후, 우리는 Revert 브랜치를 따로 만들어서 그것을 실서버 브랜치에 병합을 시킴으로써 작업 내역을 되돌려 놓았다. 이것은 마치 어떤 다른 사람이 실서버 브랜치로부터 또 다른 브랜치 B를 파서 A 브랜치와 같은 부분에 대한 작업(다시 되돌리는 작업)을 한 후 실서버에 병합을 시킨 것과 같다. 이는 곧 A 브랜치와 B 브랜치가 같은 부분에 대해 작업을 했음을 의미하기 때문에 수정 사항을 반영하기 위해 A 브랜치를 실서버 브랜치로 병합시키려 할 때 충돌이 발생하는 것이다.
2. 해결
그러면 어떻게 해야 옳은 방법일까? 현재 실서버 브랜치는 Revert Pull Request를 생성하고(Revert 브랜치가 생성되고 이를 실서버 브랜치에 병합을 시키기 위한 Pull Request) 병합을 진행함으로써 A 브랜치의 작업 내역이 되돌아간 상태이다. 이때, 그 Pull Request에 대한 Revert Pull Request를 또다시 생성해야 한다. 그러면 또 다른 Revert 브랜치가 생성되는데, 이 브랜치는 A 브랜치의 모든 작업 내역들이 한 뭉텅이로 존재하고 있게 된다. 그러면 이제부터는 기존의 A 브랜치를 완전히 폐기하고, 그렇게 새로 만들어진 Revert 브랜치에서 추가 작업을 진행하면 된다. 이렇게 하면 기존 작업 내용을 포함하여 수정 사항까지 반영한 작업 내용들을 충돌 없이 실서버 브랜치에 병합시킬 수 있게 된다.
3. 결론
원격 서버에서 Revert를 수행했다면, 이후의 추가 작업은 Revert 브랜치를 다시 한번 만든 후 그곳에서 작업을 해야 한다.
