6일간의 팀 프로젝트를 마치며 🎉
📆 프로젝트 기간 : 2025.02.12 - 17
6일간 정말 열심히 달려왔다고 생각했는데, 마지막 날이 되니 할 일이 엄청 늘어났다.
원래는 매일 과제를 하면서 생긴 트러블 슈팅을 블로그에 기록하려 했지만,
과제를 완성하는 데 집중하다 보니 나 뿐만 아니라 팀원들도 글쓰기에 소홀해졌다. 😭
그래서 오늘은 팀 프로젝트를 하면서 겪었던 깃(Git) 충돌 문제와 협업을 통해 배운 점을 정리해보려 한다. 그리고 곧 시작될 개인 과제에서는 이번 프로젝트를 통해 배운 기술적인 부분들을 블로그에 남길 예정이다. 💪
1. ISSUE와 PULL REQUEST의 중요성 📝
트러블 슈팅을 블로그에 남기지는 못했지만, 다행히도 GitHub의 Issues와 Pull Requests(PR) 에 내가 무엇을 커밋하고 어떤 메시지를 남기고 푸시했는지, 그리고 팀원들에게 어떤 작업을 요청했는지가 모두 기록에 남아있었다.
덕분에 나는
✅ 우리 팀의 진행 상황을 한눈에 파악하기 쉬웠다.
✅ 내가 어떤 작업을 했는지 돌아보는데 도움이 되었다.
✅ 팀원들 간의 피드백이 원활하게 이루어졌다.
✅ PR을 거쳐야 dev 브랜치에 코드가 추가되기 때문에, 실수를 방지할 수 있었다.
PR을 통한 코드 리뷰가 번거로워 보일 수도 있지만, 결국 안전장치 역할을 톡톡히 한다는 점에서 큰 장점이라 느꼈다.
2. Git 충돌과 Stash 활용하기 ⚡
개발을 하면서 가장 많이 겪은 문제는 내가 푸시하려는 순간 dev 브랜치가 업데이트되어 푸시가 막히는 경우였다.
처음에는 메모장에 작업한 내용을 옮겨놓고 pull을 받았었는데😅 나중에 git stash 기능을 알게 되면서 훨씬 편해졌다!
git stash가 유용했던 순간들
🔹 작업 도중 dev 브랜치의 최신 변경 사항을 받아야 할 때
🔹 코드가 수정된 상태에서 pull을 받아야 할 때
🔹 급하게 다른 브랜치로 전환해야 할 때
👉 stash를 사용하면 내가 작업 중이던 내용을 임시로 저장해두고 안전하게 pull을 할 수 있었다. 추가로, 오랫동안 작업한 후 한 번에 커밋과 푸시를 하면 conflict가 많이 발생한다는 것도 깨달았다. 그래서 작은 단위로 자주 커밋하고 푸시하는 습관이 얼마나 중요한지 배웠다.
3. 브랜치 간 Pull 대신 dev 브랜치를 활용하기 🔀
처음에는 같은 페이지를 작업하는 팀원과 브랜치 간에 pull을 직접 주고받기도 했다. 하지만 이렇게 하면❌
브랜치 간 merge가 복잡해지고 Issues에 기록된 변경 사항이 섞여버릴 위험이 있다.
위의 상황은 따로 작업했음에도 불구하고 팀원과 나의 이슈가 합쳐 버린 상황이다.
결국, 개발 브랜치(dev)에서 pull을 하고 merge하는 방식이 가장 안전하고 정석적인 방법이라는 걸 다시 한번 깨달았다.
👉 모든 코드는 반드시 dev 브랜치에 올리고, PR을 통해 관리해야 한다!
4. 협업 과정들
스크럼 내용 기록도 꼼꼼히 해주시고 늘 적극적으로 팀 프로젝트 참여하신 미경님
초반 DB설계 하는데 많은 정보 주시고 아는 꿀팁 많이 알려주신 애리님
매일 한시간 마다 팀원들 졸릴까봐 스트레칭하자고 해주시는 민경님
현업에서 일하고 온 경험으로 프로페셔널한 모습 보여주신 수민님
늘 새벽 늦게까지 미경님이랑 남아서 맡은 과제 해준 도현님
그리고 평일 주말 새벽 할거 없이 모르는거 있으면 다 알려주시는 준현튜터님 까지
모두 정말 감사합니다. 저는 운이 너무 좋아요 좋은사람만 만나서
3조 기엽조 화이팅 :)
🎯 느낀 점
이번 팀 프로젝트를 통해 협업의 중요함을 깨달았다.
특히 Git을 활용한 체계적인 작업 방식이 얼마나 중요한지 나를 포함한 팀원 모두 몸소 경험할 수 있었다.
앞으로 개인 과제를 진행하면서도 이번 플젝을 통해 배운 Issue 관리, PR 활용, 작은 단위의 커밋, stash 기능을 적극적으로 사용해볼 생각이다. 그리고 개인적으로 더 보완해야 할 부분도 많다는 걸 깨달았다. 😅
다음에는 팀 프로젝트를 하면서 배운 기술적인 내용도 정리해서 블로그에 올릴 예정 :)
