Git source 충돌날때 내가 시도했었던 해결법들

#Git충돌 #Gitsource충돌

오늘 아침에 무심코 신규 브런치로 마구마구 개발하다가 해당 브런치를 검증계 브런지에 merge하려고 하니 충돌(conflict)이 나기 시작했다.

일단 git source conflict이 나기시작하면 머리가 아프기 시작한다. 깃자체의 버그도 많은데 얘가 기존 변경점을 다 커버하지 않고 같은 부분에 대해서 다르게 변경한 것이 있다고 인지한 순간부터는 쉽지 않아진다.

필자가 생각할때 변경한 내용이 많지 않다면 제일 좋은 점은 변경한 내용을 특정 폴더나 텍스트로 저장해 두고 최신소스를 git checkout ‘최신소스 브런치’
git pull 한 이후 다시 브런치 생성하여 하는 방법.

다른 방법으로는 최신 소스 브런치로 내용을 다시 다 변경해놓은 다음 merge 성공하는거 보고
다시 변경된 내용을 추가 후 commit —> git push

결국 어떤 방법을 사용하더라도 최신 브런치로 소스를 한번 맞춘 이후 변경점을 반영해야한다는 불변의 진리
사실 당연한거고, 아니 충돌이 왜 나는거지? 이해할 수가 없네라고 생각할 수 있는데 아마도 그렇게 생각하는 사람은 코딩에 손 놓은지 최소 3년은 넘었거나 관리자… 관리자 중에서도 답답한 관리자이거나
아니면 겁나 뛰어난 개발자형 중 하나일듯.

필자는 겁나 뛰어난 개발자 형이 아니니깐
자주 이런 깃 소스 충돌을 겪는다.
이런 핵 노가다를 말이다 ㅋㅋㅋ

근데 중요한건 확실히 노가다를 해야 머리속에는 확실히 인지하고 기억된다. 그리고 그 기억은 오래간다 ㅋ

오늘 알게 된 나름 꿀팁은
신규소스 반영에 대한 Git Merge conflict이라면,
이런 방법도 고려해보면 좋을 것 같다.
아마 같은 소스를 다른 사람도 손을 대어서
그 타인이 먼저 깃 커밋을 때리고 그 이후 내가 깃 커밋을 치려고 하는데 난 과거 소스 기준으로 수정했기에 충돌나는 경우가 대부분일 것이다.
이때 기존 소스 변경이 아닌 신규 소스라면

기존로직 제일 아래에 신규소스를 그대로 붙여넣고
또는 기존로직 변경이 있더라도 함수이름 다르게 해서 마치 신규 로직인양 소스 제일 하단에 넣고 merge 한 이후 다시 원 소스를 고치면 신기하게 반영이 잘 된다.

필자는 이 방법이 가장 간편했던것 같다.
이게 참… 설명하기가 굉장히 어려운데
이해가 되었을지 모르겠네

실제 충돌날때 충돌나는 소스들 메모장에 쭉 나열하고
하나씩 이렇게 커밋해서 올려서 충돌 갯수 줄어드는 것을 보면 엄청난 희열인데.
이런거 보면 참 코딩도 머리가 나쁘면 손이 바쁜 작업인듯…ㅋㅋ 코딩부터 하기전에 생각하고 그림부터 그리고 머리속 정리부터 하고 해야하는데 잘 안된다.