배경 및 문제
드디어 우리 팀이 와이어프레임과 기본 UI 디자인을 마치고 Git에 손을 대었다. 아직 Git에 익숙하지 않은 사람이 대다수라서 테스트도 해보고, 팀원이 팀원을 따로 가르치기도 하고, 원격 저장소에 접근하려니 Password를 요구하는데 알고보니 그게 단순히 패스워드가 아니라 직접 만들어야 하는 SSH Key 또는 Personal Access Token 이었고.. (이 토큰 문제를 해결하는 데 상당한 리소스가 투여되었다. 사실 같은 문제가 다른 팀원들에게도 순차적으로 발생했는데, 먼저 해결한 내가 좀 더 제대로 공유했다면 좋았겠지만 나도 처음 겪는 문제라 선뜻 나서기 쉽지 않았던 것 같다. 역시 아는 것은 힘이다..)
아무튼, 여러가지 일이 있었지만 가장 큰 문제는 Git 의 Branching이었다.
위 이미지는 GUI 툴인 GitKraken으로 우리 팀의 저장소를 본 건데, 보다시피 아주 혼란스러웠다.
gitignore 파일을 생성하는 것도 처음이었고, 제대로 initialize 하지 않은 상황에서 브랜치를 만들어 작업하려니 이래저래 꼬여버린 것이다.
결국 좋은 경험 했다 치고 새로운 저장소를 만들어서 작업하기로 했지만, Git을 사전캠프 때 나름 열심히 공부한 나는 꼬여버린 저장소를 풀어보고 싶다는 욕구가 생겼다.
문제 접근
문제 상황 파악
일단 만들어진 브랜치는 다음과 같았다.
main, develop, feature-ch, feature-dy, feature-ms, feature-sk, feature-sy그리고 순차적으로 Pull Request 및 Merge가 이루어지지 않고 마구잡이로 이루어진 것이 다른 브랜치들이 뒤처진 원인이었다.
그 기반에는 모든 팀원에게 저장소 어드민 권한을 준 것이 첫 번째, 그리고 그 권한을 그런 식으로 사용 한게 두 번째 이유가 있었다.
접근법 1
일단 다같이 작업을 하기 위해 모든 브랜치를 잘 병합해서 한 곳으로 모으고 싶다고 생각했다.
그래서 내 로컬에서 모두 직접 작업할 수 있도록 모든 원격 브랜치를 체크아웃해서 로컬 저장소에 띄었다.
괜히 헷갈리지 않도록 문제 없이 pull할 수 있는 로컬 브랜치는 모두 pull 하였다.
제일 끝에 있는 main 브랜치에 하나씩 merge 하려고 했는데, 첫 번째 merge는 무사히 했으나 두 번째 merge부터 conflict가 일어나 부담이 되었다.
(나중에 알게된 건, 충돌이 일어난 파일이 gitignore에 넣어도 될만한 파일들이었다. gitignore 설정에도 추가가 필요했던 것이다.)
(Stack Overflow 검색 결과: xcuserdata 폴더에 있는 건 개인 Xcode 설정 파일들이라 아래처럼 설정해도 문제 없다.)
// Xcode.gitignore
## User settings
xcuserdata/접근법 2
그래서 일단 부담이 되지 않는 선에서, 뒤처진 feature-ch와 feature-sy 브랜치끼리 병합을 시도하였다.
충돌이 되는 파일이 이 브랜치에 있어서, 파일을 대충 훑어본 후 문제가 없을 것 같아 덮어씌어서 conflict를 해결했다.
그런 후 main 브랜치에 그 병합한 브랜치를 다시 병합하였다.
그랬더니 드디어 그래프가 한 점으로 모여서, 브랜치의 위치를 다시 설정만 해주면 되었다.
문제 해결
그 이후로는 branch -f main develop 를 이은 branch -f main 나머지브랜치의 향연이었다.
브랜치를 강제로 옮기는 것에 다소 저항이 있었지만, 마지막 병합은 제대로 이루어졌으니 문제 없다고 판단하였다.
결국 원하는 것은 새로운 스타팅 포인트이었으니까...
느낀 점 및 예방 방안
어차피 새로운 저장소를 만들기에 쓸 데 없는 리소스 낭비가 아닌가 고민이 되었는데, 결국엔 Git을 다루는 역량을 늘린 것 같아 뿌듯했다.
문제 해결을 한 번 하고나니 다음에 비슷한 문제가 닥쳤을 때도 해결할 수 있겠다는 자신감이 생겼다.
앞으로도 비슷한 문제가 발생할 수 있겠다는 생각이 들었고, 미리 '예방'하는 게 더 중요하겠다는 생각이 들었다.
첫째로는 팀원과의 약속을 잘 하고, 저장소 권한도 잘 설정해야 한다. (Pull Request 처리 방식에 대한 주의)
둘째로는 main 브랜치 보호 설정이란 것도 발견했는데 아주 유용하게 활용할 수 있을 것 같다. (링크)
셋째로는 GUI 툴의 활용이다. 평소에 커밋과 브랜치들의 시각화해서 잘 봐야 문제를 더 잘 예방할 수 있다. 터미널에만 매달리는 것은 비효율적이다.
짧은 회고
오늘 이래저래 병렬적으로 진행하는 일이 많아서 여기저기에 참견하는 일이 많았는데, 그러다보니 팀원의 말을 끊어버리는 상황이 자주 발생했었다.
하루를 되돌아보니 직접 주도하는 일이 아님에도 의견을 내는 게 올바른 일인가 싶기도 하고, 말을 여러번 끊은게 (그때마다 죄송하다곤 했지만) 후회스럽다.
온라인이라서 그런가? 싶기도 했지만 오프라인에서도 나는 말을 내는 타이밍을 잡는 걸 꽤 어려워하는 것 같다.
이것도 숙련해야 될 스킬이다. 사람의 말을 들을 때는 충분히 경청한 후, 한 박자 쉬고 대답하자!
