📒 오늘의 TIL

1️⃣ CSS 작업

• CSS 작업을 어느 정도 끝냈다. 추후에 더 수정하고 미디어 쿼리도 설정해야겠지만, CSS 작업은 어느 정도 뼈대를 잡은 것 같다. 아직 백엔드 API가 완전하게 나오지 않았고 나와도 로그인 기능이 완성되어야야, 미디어에서 데이터도 생성해서 백엔드로 보내고 그것들을 기반으로 데이터를 가지고 기능을 만들어 볼 수 있을 것 같다.

2️⃣ 배포와 깃허브

• 나는 Git 관리를 맡고 있다. 우리는 매일 오전 10시에 함께 모여서 각자 전날 작업한 내용을 Git에 올리고, 충돌이 있는지 확인한다. 충돌이 발생하면 해결하고, 충돌이 없다면 develop 브랜치에 병합한다. 병합이 완료되면 각자의 로컬 환경에서 master 브랜치를 업데이트하고, 작업 내용을 이슈에 작성한 후 feature 브랜치를 생성하여 그날의 작업을 진행한다.

• 하지만 이번에 프론트엔드 배포를 진행하며 GitHub 관리가 어려워졌다. 작업 중간마다 배포를 위해 자주 Git 풀 리퀘스트를 요청하고, 한 명만 올릴 수 없어서 팀원 전체가 함께 올리고 내려받는 과정을 반복했다. 이로 인해 피쳐 이슈가 지나치게 많아졌다. 사실 이런 관리 방식은 옳지 않다는 생각이 들었지만 배포가 급한 상황이어서 어쩔 수 없이 이와 같은 방식으로 Git에 반복적으로 올리고 내려받게 되었다.

🧑‍💻 궁금한 점

• 현업에서 깃허브 관리를 어떻게 하는지

  현업에서 Git 및 GitHub를 사용한 관리 방법은 조직이나 팀의 요구사항, 프로젝트의 규모와 복잡성에 따라 다양할 수 있다. 그렇지만 일반적으로는 아래와 같은 관리 방법이 널리 사용된다.

  *️⃣ 브랜치 전략 : 주로 Git Flow나 GitHub Flow와 같은 브랜치 전략을 사용한다. 이는 개발, 테스트, 배포를 위한 다양한 브랜치를 구성하여 기능 개발, 버그 수정, 배포 등을 병렬로 처리하는 방식

  *️⃣ 이슈 트래킹 : GitHub의 이슈 기능을 활용하여 기능 추가, 버그 수정, 작업 요청 등을 관리한다. 이슈에는 제목, 설명, 레이블, 마일스톤 등을 활용하여 상세한 정보를 기록하고, 팀원과의 소통과 작업 추적에 활용한다.

  *️⃣ 코드 리뷰 : Pull Request를 통해 코드 리뷰를 수행한다. 팀원들이 작성한 코드를 서로 검토하고 의견을 주고받으며, 품질 향상과 버그 예방을 위해 리뷰 과정을 거친다.

  *️⃣ 자동화와 테스트 : CI/CD 파이프라인을 구축하여 코드의 빌드, 테스트, 배포 등을 자동화한다. 이를 통해 개발자들은 코드 변경 사항이 자동으로 검증되고 배포되는 과정을 확인할 수 있다.

  *️⃣ 협업과 소통 : 커뮤니케이션 도구나 이슈 트래커를 활용하여 팀원들과 소통하며, 작업 상황, 계획, 이슈 등을 투명하게 공유한다. 또한, 코드에 대한 문서화와 지속적인 피드백 공유를 통해 팀원들 간의 지식 공유를 도모한다.

  이 외에도 현업에서는 코드 스타일 가이드, 버전 태깅, 릴리즈 노트 작성 등의 관리 작업도 함께 이루어진다. 중요한 것은 팀의 요구사항과 프로젝트의 특성에 맞게 Git 및 GitHub를 유연하게 활용하여 효율적이고 협업을 원활하게 할 수 있는 방법을 찾는 것이다.

• 깃을 FR날리는 시간은 정해져 있는가? 하루에 몇 번 정도 하는가?

  깃을 푸시하는 시간은 조직 또는 팀의 개발 프로세스에 따라 다를 수 있다. 팀마다 다른 요구사항과 개발 방식이 있기 때문에 푸시하는 시간에 대한 구체적인 규정은 없다. 일반적으로는 다음과 같은 패턴이 일반적이다.

  *️⃣ 작업 완료 후 푸시 : 개발자는 기능 또는 버그 수정 등의 작업을 완료한 후, 해당 작업 브랜치를 원격 저장소에 푸시한다. 이는 작업이 완료되었으며 다른 팀원들과 공유할 준비가 되었음을 의미한다.

  *️⃣ 코드 리뷰 후 푸시 : Pull Request를 통해 코드 리뷰를 받은 후에 리뷰어의 피드백을 반영하여 작업 브랜치를 푸시한다. 이는 리뷰 과정을 거쳐 코드 품질을 향상시키고 팀원들의 검토를 받았음을 의미한다.

  하루에 푸시하는 횟수는 프로젝트의 규모, 작업의 복잡성, 개발자의 작업 속도 등에 따라 다르다. 작은 프로젝트의 경우, 하루에 몇 차례 푸시할 수도 있지만, 대규모 프로젝트의 경우에는 한 번 이상의 코드 리뷰를 거친 후 푸시하는 것이 일반적이다. 중요한 것은 팀원들과의 협의를 통해 일관된 규칙을 정하고 프로젝트에 맞춰 푸시하는 시간을 조율하는 것이다.

✍ 알게된 점

• 깃허브 관리

💫 느낀점

• 초반에 팀에서는 규칙을 정리하고 사전에 많은 준비를 했지만, 이번 프로젝트는 처음 직접 참여하는 경험이어서 프로젝트 진행 중에 준비가 미흡한 부분들이 계속해서 보인다. 실제로 백엔드는 프로젝트 시작과 동시에 배포가 진행되지만, 우리는 상대적으로 늦게 배포 작업을 진행했다. 그래서 로그인과 관련된 프론트엔드 배포도 급하게 진행해야 했는데, 생각보다 어려움을 겪고 있다. 이번 경험을 기억하고, 다음에는 이런 상황을 더 원활하게 해결할 수 있도록 노력해야겠다.