브랜치 기준 차이로 발생한 DEV–PROD 설정 충돌 트러블슈팅

1. 문제

1. 회사 방침에 따라 origin/PROD 브랜치 기준으로 feature/modi-yml 브랜치를 생성했고, 해당 브랜치에서 URL 설정을 변경 했다. 

2. 이후 이 feature 브랜치를 origin/DEV 브랜치에 merge하려고 시도했으나, origin/DEV에는 username, password 관련 설정 변경이 미이 반영되어 있었고, 해당 변경 사항은 아직 PROD에는 반영되지 않은 상태였다.

-> 물론 나는 신입사원이라 해당 내용을 모르고 merge를 시도 했다.

3. 그 결과, 서로 다른 기준(PROD, DEV)에서 파생된 변경 사항이 충돌해 merge conflict가 발생했다.

 

이때, 머리가 아팠던 점은

* username, password를 어디 것을 따라야 하는지 -> 이건 물어서 origin/DEV 가져가기로함

* merge conflict 발생 시 어떻게 해야 했을까? -> feature의 URL 변경은 유지해야 한다.(이것이 업무였으니까.)

 

2. 해결

해결은 merge conflict 상태에서, origin/DEV 기준으로 소스코드를 수정하고 push를 했다. 이렇게 되면 문제가 생기는게

 

1. feature/modi-yml에 PROD와 DEV의 상태가 다르다는 히스토리가 남지 않는다.
- PROD 기준으로 URL 변경 시도 히스토리

- DEV에는 다른 설정(username/password)이 이미 존재 

- 이 차이를 feature 브랜치에서 남겼어야 함

2. merge conflict도 어떤 충돌이 일어났는지 히스토리가 남지 않는다.

3. feauter URL 변경을 유지 못했다.

 

따라서 DEV 브랜치에 URL 수정하고 push 해버렸다.

 

이를 gpt 선생님과 상의해서 어떻게 하면 좋았을지 고민해 보았다.

 

우선, 

1. merge 도중이고, 아직 커밋하지 않은 상태일 경우(충돌 화면에서 멈춘 경우)

-> git merge feature/modi-yml 치고 충돌(conflict) 상태

git merge --abort

위는 merge 시작 전 상태로 돌아감

 

2. merge 성공했고, merge commit까지 만들었지만 아직 push 전

git merge feature/xxx
# 충돌 해결
git commit   # merge commit 생성

까지 하면, origin/DEV에는 아직 안 올린 상태이다.

git reset --hard ORIG_HEAD
or
git reset --hard HEAD~1

mrege commit 자체가 삭제되고, 로컬에서만 작업 중일 때 가장 깔끔하게 되돌아간다.

 

3.  merge commit을 이미 origin/DEV에 push 해버린 경우 (가장 위험)

git revert -m 1 <merge_commit_hash>
// git revert -m 1 a1b2c3d4

원래 이미 올라간 것은 함부로 되돌리면 안되는데, 공부하는 거니까,,,

여기서 -m 1의 의미는 

 

• merge commit에는 부모가 2개 있음
• -m 1 → DEV 브랜치를 기준으로 되돌린다는 뜻
• feature에서 들어온 변경만 “취소하는 커밋”을 새로 만든다.

라고 한다. 위로 merge를 돌린 후 해야할 작업은

 

⭐⭐⭐ feature 브랜치를 DEV 최신으로 리베이스/머지해서 충돌을 feature에서 먼저 해결하고, 그 결과를 DEV에 머지

DEV에 이미 변경이 있으니, DEV를 feature로 먼저 끌고 와서(merge 또는 rebase) feature 쪽에서 충돌을 해결한 다음, “충돌 없는 PR”로 DEV에 넣는 방식이다.

• 절차(merge 방식):
  1. feature/modi-yml에서 git fetch origin
  2. git merge origin/DEV
  3. 충돌 난 yml에서 DEV의 username/password + feature의 URL 변경을 둘 다 살리는 형태로 수동 해결
  4. feature에 커밋
  5. 그 feature를 DEV로 PR/merge

장점

• DEV를 더럽히지 않고(feature에서 먼저 해결) PR도 깔끔해짐.
• “PROD 기준으로 feature를 만든 건 방침”을 유지하면서도, DEV와의 차이를 feature가 흡수.

위와 같이 했다면 깨끗하지 않았을까 생각해보았다. 하지만 이미 commit을 쳐버렸는걸,,,