.gif&blockId=743d12a5-f17c-4b91-a76d-8a3aa6fd4c06)
협업 가이드
1.
노션 페이지 내 할일 목록에서 맡을 일을 정한다.
2.
해당하는 업무에 대해 GitHub 이슈를 생성한다.
•
담당자 지정 필수 !!! → 담당자를 지정해야 브랜치가 자동으로 생성된다.
•
라벨, 마일스톤 설정하기
3.
해당하는 업무에 대해 생성된 브랜치를 로컬로 가져온다.
•
원격 저장소의 브랜치 리스트를 확인
git branch -r
Bash
복사
•
로컬 저장소의 브랜치 리스트를 확인
git branch
Bash
복사
•
로컬, 원격 모든 저장소의 branch 리스트를 보려면
git branch -a
Bash
복사
•
원격 저장소의 브랜치 가져와 이동
◦
위의 상황에서 만약 원격 저장소의 feat/issue-3 branch를 가져오고 싶다면,
◦
-t 옵션과 원격 저장소의 branch 이름을 입력하면 로컬의 동일한 이름의 branch를 생성하면서 해당 branch로 checkout을 한다.
git checkout -t origin/feat/issue-3
Bash
복사
•
만약 branch 이름을 변경하여 가져오고 싶다면
git checkout -b [생성할 branch 이름] [원격 저장소의 branch 이름]
Bash
복사
4.
해당하는 업무를 진행한다.
•
작업을 시작하기 전에는 git pull을 습관화하자!!(업데이트 되지 않은 코드로 다른 작업을 시작하면 나중에 merge할 때 충돌이 발생한다.)
•
해당하는 노션 페이지에 그 업무를 하면서 어려웠던 점, 해결한 법 등을 메모하면 좋다!
5.
작업을 완료하면 작업한 브랜치에서(main브랜치 X) 코드를 푸시한다.
•
git add
•
git commit -m “종류: 한 일”
•
git push 한다.
6.
깃허브 레포지토리 페이지로 이동하면 푸시한 브랜치에 대해 compare & pull request 버튼이 활성화된다.
•
PR(pull request)이 오픈되었다는 것을 공유하고, 푸시한 본인 외 다른 팀원이 코드를 확인하고 main 브랜치에 merge한다.
◦
성준: 수현 → 세민 → 혜지
◦
수현: 성준 → 혜지 → 세민
◦
세민: 혜지 → 수현 → 성준
◦
혜지: 세민 → 성준 → 수현
7.
노션 페이지에서 완료한 할일을 Done 상태로 변경한다.
팀 규칙
불참해야 할 일 생길 때, 하루 전에는 말을 해주기
공부하다 모르는 내용 생기면 공유하고 서로 같이 고민하기
프로젝트 시작시 고려할 부분(출처: 윤철님)
)•
팀원간 커뮤니케이션
◦
의미없어보이는 의견도 꼭 제시하기
◦
의견에 대한 의견(찬성, 반대)등은 의견에 대한 찬반이지 그 사람에 대한 찬반이 아니므로 너무 마음쓰지 않기 (꼭 이 의견에 반대하는 것이 아니라도 자신의 의견을 제시하고 투표식으로 진행가능)
▪
반대일 경우 아주 작은것이라도 의견을 갖고 말하기 (이렇게 하는건 어떨까요? 등등)
◦
리액션을 잘하기
▪
와~너무좋아요 이런것도 좋지만 넵!, 확인했습니다 등등 대답을 잘하는 것을 의미
◦
당연하지만 서로 배려 존중
◦
한사람만 말하거나 의견을 제시하는 분위기 피하기 => 본인이 살짝 부족하다 생각해도 개의치 않고 따라가려는 것 보다 능동적 참여
◦
서로 모르는 것이나 애매한 것은 적극적 소통
◦
더 추가될 내용 생각해보기
•
프로젝트 시작 (여기서부터는 팀원간 소통을 통해 진행)
◦
프로젝트 진행 방식 결정 (스택 설정, 주제 선정, 페어프로그래밍 등등)
◦
간단한 ui 그리기 ( 컴포넌트 쪼개기 용 )
◦
관련 도메인 사이트 or 프로젝트 (레퍼런스) 탐색
▪
우리 프로젝트에 추가할만한 기능 탐색
◦
컨벤션 정하기 (깃 컨벤션, 폴더 구조 컨벤션, 파일명, 변수명 컨벤션)
▪
eslint 같은 것도 고려, create react app이나 vite같은 프로젝트 생성 방법 고려
◦
역할 분담하기
•
이력서나 포트폴리오를 작성하기 위한 팁
◦
왜 이러한 라이브러리를 사용했는지 생각
◦
왜 이러한 코드를 작성했는지 (조금 신경써서 구현한 부분) 생각
▪
항상 기록하기 => 에러 기록, 코드 기록, 그때그때의 생각 기록
개인적으로 진짜 반대를 하려는게 아니라 의문을 던지면서 한번더 생각보는 것을 좋아함
•
그렇게 생각한 이유는 뭐지? => 이 대답에 답을 할 수 있어야 진짜 본인의 생각이고 본인이 알고 있는 것
혜진님 팁
•
기능별로, 페이지별로, 페어프로그램 방식으로, 한명의 PM을 두고 진행하는 방식으로.. 여러 방식이 있음
•
팀프로젝트는 연습이다. => 앞으로 사회생활에서 경험할 것을 미리 경험해보는 것 => 포기만 하지 말자(비교도 하지 말자)
•
처음 만나면 각자 자신의 소개를 솔직하게 하는 것을 추천한다. (나는 현재 를 할 수 있고 를 공부할 것이다.)
•
코드짜는것만 팀프로젝트의 전부가 아니다. 소프트 스킬, 팀 분위기 향상, 아이디어, 적극적 태도 등등 여러 도움이 될 수 있고 이러한 점이 실제로 회사에서 원하는 인재이다. (팀에 잘 녹아들 수 있는 사람)
•
좋은게 좋은거지~ 좋게 생각하며 긍정적 마인드 갖기
•
프로젝트 시작 팁
◦
HTML, CSS, JS 진행 방식 (프레임워크 라이브러리 정하기)
◦
작업 나누기 => 기능, 페이지, 공통 UI로 나누기 (공통된 부분부터 )
◦
컨벤션 맞추기 (어쳐피 지저분해진다.. 그래도 일단은 맞추자)
•
발표 자료, 영상 잘 남겨 놓기
누리님
•
프로젝트 기간이 길어지면 당연히 서로에게 할말이 생길 수 있다.
◦
너무 직접적으로 강하게 말하는 것이 아니라 부드럽게 의견을 전달하며 조율하길 !
◦
주간 회의 같을때 잘 조율하는것도 좋다.
•
사람마다 각자 사정이 있고 각자 좋은날 나쁜날등이 있을 수 있다.
◦
만약 누군가에게 친절하지 못하게 대하거나 그런 태도를 받았다면 최대한 이해해보기.. ㅎㅎ
▪
나중에 다시 말해보자.
•
프로젝트를 꼭 고정하지말고 자유로운 아이디어가 있으면 꼭 제시하기
◦
1기, 2기 레파지토리가 존재하기 때문에 참고를 하다보면 그 레파지토리에 갇히는 경향이 있게된다. (맞는말인듯,.. )
▪
너무 깊게 따라하지말자 참고만 !! => (중요)
프로젝트 시작 전에 참고하면 좋을 것 같은 내용 정리해봤습니다
