🐧 들어가기 앞서
최종 프로젝트를 진행하기 앞서, 깃허브를 이용하는 방법을 다시 알아봤다.
아무래도 최종 프로젝트는 포트 폴리오와 연관될텐데,
팀원과 협업 하는 방법을 현업과 최대한 비슷하게 구성해서 진행하고 싶었다.
🐧 오늘 배운 것
- 이슈 생성
🐧 기억할 것 & 진행
이슈 기반 브랜치 생성 방식
-
Issue 생성: 작업을 시작하기 전에 이슈를 생성하여 작업 항목을 추적한다.
-
Branch 생성: 이슈에 따라 새로운 브랜치를 만들고 해당 브랜치에서 작업을 진행한다.
-
Pull Request 생성: 작업이 완료되면 Pull Request를 생성하여 이슈를 닫고 코드 리뷰를 요청한다.
-
Pull Request 병합: 리뷰가 완료되고 모든 변경 사항이 승인되면, Develop 브랜치로 Pull Request를 병합한다.
-
Branch 삭제 : 작업을 진행한 브랜치를 삭제한다.
장점
- 각 이슈는 독립적인 작업단위로 관리되므로, 코드 변경 사항이 명확하게 추정된다.
- 병렬 작업에 용이하다. 여러 사람이 동시에 다른 이슈를 처리할 수 있다.
- 이슈 완료 후 해당 브랜치를 삭제함으로써, 브랜치 관리가 비교적 간단해진다.
단점
- 많은 수의 이슈가 발생하면 그만큼 많은 브랜치가 생기게 되므로, 전체적인 관리가 복잡해질 수 있다.
즉 git flow를 따라가볼 생각!
https://hyeonic.github.io/woowacourse/dallog/git-branch-strategy.html#git-repository
개인 브랜치 생성 방식
장점
- 개인별로 고유한 작업 공간을 가지므로, 다른 사람들의 작업으로 인한 영향을 최소화 할 수 있다.
- 개인별 브랜치에서 자유롭게 실험하고 변경사항을 테스트할 수 있는 환경을 제공한다.
단점
- 개발자 간 코드 변경사항을 동기화하기 위해 자주 병합(Merge)하거나 리베이스(Rebase)를 해야 한다. 이런 과정에서 충돌(Conflict) 발생 가능성도 커진다.
- 모든 개발자가 동일한 코드 베이스에서 작업하지 않으므로, 통합 테스트 등에 어려움이 생길 수 있다.
후기
개인적으로 개인 브랜치 생성 방식으로 이때까지 협업을 진행했다.
장점도 좋았지만, 개인적으로 단점이 실제로 발생했을 때 치명적이였다.
-
1 커밋 1 PR 원칙을 잘 지키지 않는다.
-
메인 기능을 제작할 때, 메인 씬에 여러명의 작업이 몰리다보니 컨플릭트가 종종 생겼다.
개발자는 컨플릭트를 방어해야하는데, 발생하는 것 만으로도 치명적이라고 생각한다. -
소통이 부족했다. 개인적으로 작업을 진행하다보니, 실제로 만나서 하는 작업이 아닌 비대면 작업이 주로 이루어져 아무리 말을 해도 못듣는 상황이 종종 생겼다.
따라서 이번에는 일일 스크럼을 진행하고, 이슈를 생성해서 프로젝트를 진행하고 싶다.
자기가 할 일을 명확하게 정리하고, 팀원이 타인의 작업을 인지한다는 것 자체가 중요하다고 생각한다.
프로젝트 리더는 PM의 자질도 갖추고 있어야 한다고 생각한다.
