이번 팀 프로젝트를 마치며 팀끼리 KPT 회고록을 작성하는 시간을 갖게 되었다. 여기서 KPT란 프로젝트가 끝났을 때, 프로젝트를 하면서 좋았던 점이나 앞으로 유지하면 좋을 점 (Keep), 프로젝트를 진행하면서 문제나 오류가 생겼던 부분 (Problem), 새로운 팀 프로젝트를 진행할 때 부족한 점을 어떻게 고치고 새로운 기능들을 시도해볼지 (Try) 에 대해 작성하는 시간이다. 이번 프로젝트에서 팀장을 맡고 진행을 주도하면서 앱을 개발하는 시간만큼 많이 쏟았던 것이 Github에서의 git push와 merge 시의 충돌을 관리하는 것이었다.
git push 시 나타난 에러
Github에 소스코드를 업로드할 때, 가장 많이 났던 에러였다. 해석하자면, 원격 레포지토리에서의 모든 변경 사항을 pull 했는지 확인하고 다시 시도하라고 뜬다.
보통 다른 사람들이 push된 것에 내가 pull을 땡기지 않고 작업하다가 push를 할 때 많이 나타나는 오류이다. 이런 오류가 나지 않게 하기 위해 각자가 개발하는 기능들을 파일 별로 나눠 놓고 모든 팀원들에게 중첩이 되는 viewcontroller.swift 같은 파일들은 수정을 최소화 하고, 수정이 되었다면 git commit & push를 하여 나머지 팀원들에게 pull request를 하는 것이다.
그럼 각자 개발하던 파일들은 건드리지 않고 수정된 viewcontroller만 github에 있는 viewcontroller로 바뀌는 것이다.
1. 나를 포함한 팀원 모두가 협업을 처음하고, github의 git 관리 개념이 생소했기 때문에 각자의 기능에 맞춰 입맛에 맞게 각자의 기능 구현 branch에 신나게 push를 했다.
2. 그렇게 기능 구현이 끝나고 서로가 만들었던 view들을 이어줘야 하는 과정이 있기 때문에 각각의 branch들을 merge를 한다.
3. 당연히 merge과정에서 충돌이 난다. 왜냐? 각자 viewcontroller와 main.storyboarod에 서로의 코드들을 휘갈겼기 때문이다.
4. 이렇게 얽혀버린 코드들은 수정시간이 너무나도 오래걸리고 수정이 되더라도 제대로 작동하지 않을 때도 많다. 특히 main.storyboard는 아주 기가맥히게 수정이 되도 오류가 난다.
5. 시간에 쫓겨서 프로젝트를 진행중이던 우리 팀은 결국 main브랜치에 있던 viewcontroller파일에 각자의 코드들을 한명씩 차례대로 pull -> code 입력 -> commit & push 진행하여 merge중에 충돌을 해결했다.
- 우리 팀은 pull request의 중요성을 아무도 제대로 알지 못했고, 파일의 수정내역을 request해서 자신이 진행하는 local 파일에 pull해야 한다는 것을 과제가 거의 끝나갈 때 쯤에 알게 되었다
- git과 관련된 문제는 에러가 나서 해결하기 보다는 에러가 날 요소들을 미리 관리해서 사전에 차단하는 게 효율적인 것을 뼈저리게 느꼈다.
git pull에 붙어있는 rebase
위의 에러들을 해결하기 위해 에러문에 나타난 대로 git pull을 먼저하려고 한다. 이 과정에서 git pull을 하면 rebase할 건지 말건 지에 대한 선택 사항이 뜬다.
A---B---C feature
/
D---E---A'---F main이걸 rebase 누르면 어떻게 변하게 될까?
B'---C' feature
/
D---E---A'---F main내가 기능 구현한 A와 다른 사람이 구현해서 올린 A'는 커미터 정보가 다르기 때문에 상위 브랜치의 코드를 덮어쓰게 되고 내가 구현했던 코드는 사라지게 된다. rebase 클릭하고 pull 땡기다가 정말 많은 파일을 날려버렸고, 그만큼 개발력이 지체되었다.
- 결론은 에러가 나기 전에 미리 상황에 대비하는 것이 가장 좋다.
다만, 의도치 않게 에러가 날 경우, rebase는 신중하게 생각하고 써야한다.
