서로 다른 분야가 한 레포를?

우테코 팀 프로젝트를 서로 다른 분야 프론트엔드-백엔드 또는 안드로이드-백엔드 가 한 팀이 되어 하나의 Github Repository 에서 작업을 같이 하게 됩니다.

저희 팀 펭쿡 은 안드로이드 3명, 백엔드 5명으로 구성되어있었는데요, 안드로이드 1명과 백엔드 1명이 서로 머리를 맞대어 브랜칭 전략을 담당하여 몇 시간 회의를 끝으로 결론을 짖고 팀에게 알려주기로 하였습니다.

최종적으로 성공하여 아래와 같이 깔끔한 브랜치 그래프를 그릴 수 있게 되었고 모두 팀원들이 잘 작업을 해주고 있다는 증거입니다!

토론 및 기초 작업

팀원들이 믿고 맞겨주었기에 둘이서 한 컴퓨터로 작업을 시작하였습니다.

main 브랜치 폴더 분리

폴더를 유지하기 위해 .gitkeep 이라는 빈 파일을 만들고 README.md 를 우선 전부 지우고 업로드 하였습니다.

prod 및 dev 파생

이제 main 에서 각 파트별로 브랜치를 분리하게 될텐데 여기서 추후에 있을 CI/CD 작업을 위해 prod(production) 와 dev(develop) 브랜치가 각각 있어야 한다고 판단하여 아래와 같이 분리되었습니다.

• main
  • an/prod
    • an/dev
  • be/prod
    • be/dev

1. main 브랜치를 기준으로 an/prod 와 be/prod 를 각각 만들어주었고
2. 만들어진 파트별 prod 브랜치에서 dev 브랜치도 만들었습니다.

아래는 CI/CD 가 용어가 나와 간략하게 정리한 것으로 추후에 나올 글에서 더욱 자세히 기술하게 되니 모두를 이해하려 하실 필요는 없습니다.

CI (Continuous Integration)

각 팀원이 자신의 코드를 개발 서버에 적용하기 위해 be/dev 브랜치로 Pull Request 를 보내게 될텐데 목표 브랜치로 오려는 기반 브랜치 be/feat/00 에서 빌드와 테스트를 수행하여 잘 문제가 없는지 점검한 후 코드를 안전하게 병합하기 위한 사전 작업입니다.

CD (Continuous Deployment)

be/dev 또는 be/prod 로 새로운 커밋(Push가 아닌 Pull Request의 병합) 이 발생할 때 개발서버 또는 실제서버로 배포를 자동화 하는 작업입니다.

be/ 의 의미

be/dev 와 같이 중간에 / 를 준 이유는 Intellij 와 같은 IDEA 에서 편리하게 보기 위함입니다.
보통 - 로 하는 경우도 많은데 / 로 하게 되면 폴더로 정리가 알아서 됩니다.

그러면 자신이 열어 볼 필요가 없어지는 다른 파트의 브랜치 폴더를 닫고 작업을 할 수도 있게 됩니다.
또한 최상위를 be 나 an 으로 둔 이유 또한 최상위를 분야로 구분함으로써 서로의 브랜치를 볼 필요가 없어지게 되는 것이죠!

팀원들과 실습

팀원에게 앞으로 Git 이렇게 사용해주세요 알리는 것은 굉장히 중요하고 큰 문제입니다.
저희는 대부분 Git 에 대한 두려움이 크기 때문에 따로 시간을 내어 다 함께 연습용 리포지토리에서 깃 연습을 해보았습니다.

1. 미리 위의 기초 작업을 기반하여 브랜치 3개 main prod dev 만들기
2. 모두 각자 dev 를 기반으로 번호 하나씩 선택하여 feat/1 feat/2 등 만들기
3. README.md 에 서로 다른 내용을 적거나 수정하는 랜덤한 작업 해보기 (모두가 병렬로 작업하는 부분)
4. 각자가 작업한 feat/1 브랜치에서 dev 브랜치로 Pull Request 작성하기

여기까지 모두 작성하였다면 PR 에서는 문제 없이 다 Merge가 가능하고 Conflict 가 없다고 할것입니다.

5. 이제 제일 처음 작업인 feat/1 을 가서 Rebase and Merge 를 누릅니다!
   

만약 Create a merge commit를 한다면...

모든 커밋들이 다른 줄로 기록되고 기존 feat 브랜치를 지워도 아래처럼 그래프가 유지되어 가시성이 확 떨어질 것입니다.

또한 Pull Request 를 Rebase and Merge 하게 되면 커밋들이 dev 로 합쳐진 커밋들 위해 자신의 작업들이 올라가게 됩니다. (이전 날짜의 작업임에도 불구하고)

6. 이제 feat/2 에 대한 Pull Request 를 가면 Conflict가 나거나 회색으로 Rebase and Merge 가 작동이 불가능한 것을 보실 수 있을겁니다.

여기서 커밋들 유지하고 싶은 욕심과 브랜치를 깔끔하게 만들고 싶은 욕심으로 인해 한가지 트릭이 들어가게 됩니다.

7. feat/2 브랜치에서 dev 브랜치를 git pull git rebase 하여 Conflict 난 것을 해결하거나 그냥 합치게 됩니다.
   이제 git push -f 로 강제 푸시를 하여 오리인의 피쳐 브랜치 커밋들을 재정렬 해주는 겁니다...!
   이 방법은 팀에서 회의를 통하여 결정하여야 하고, 추후 CI 가 빌드와 테스트를 하여 검증을 해줄 것이기에 이런 선택을 하게 되었습니다.

8. feat/2 브랜치에 대한 Pull Request 에서 Rebase and Merge 를 한다.

9. 나머지 팀원들도 6부터 작업 반복

이슈 기반 feat 브랜치

기능 구현을 하거나 버그를 픽스할 때 항상 Github Issue 를 먼저 생성하자는 팀 컨벤션이 있습니다.
62 번 이슈에 대해서는 be/feat/62 와 같이 브랜치를 생성해 작업한 후 be/dev 로 Pull Request 를 보내도록 정하였습니다.

이로써 각 팀원이 각자의 브랜치에서 개발을 하고 코드를 하나로 합치는 것을 완료할 수 있었습니다.

팀 프로젝트에서 이렇게 브랜칭을 나누어 잘 다루어 보는 것도 처음이었기에 많이 두렵고 걱정되었지만 결과적으로 현재 브랜치 그래프도 너무 안정적인 직선이고 기능 구현 및 코드 합치기도 잘되고 있어 정말 만족스럽습니다.

사전에 연습은 했음에도 불구하고 실수를 어쩔 수 없이 생기기 마련이었습니다.

최종 브랜치 구조 및 후기

• main
  • an/prod
    • an/dev
      • an/feat/1 1번 이슈에 대한 기능 개발
      • an/feat/4 4번 이슈에 대한 문서 작성
  • be/prod 실제 서버로 배포
    • be/dev 개발 서버로 배포
      • be/feat/2 2번 이슈에 대한 기능 개발
      • be/feat/3 3번 이슈에 대한 버그 수정

브랜치 main 혹은 an/prod 어느 곳에서 앱 배포 할지에 대해서는 조금 더 상의를 해볼 것 같습니다.

• main 에 모든 코드를 합치고 Github Release Tag 도 붙이고 배포도 할지
• main 은 단순 README, an/prod 에 따라 배포 할지

브랜치 가지가 잘못 엇나가 영영 사라지지 않고 따라 다니는 것을 두려워 하지 말자 라고 생각했습니다.
그 이후로 팀원들 모두 도전해보게 되었고 실수나 충돌이 생기면 같이 해결해 나감으로써 실전으로 Git 공부를 할 수 있었습니다.

추후 Issue Automation 작업을 통해 이슈를 생성하면 브랜치를 자동으로 생성하는 Workflow 를 제작할 예정입니다.