기획은 2월28일 ~ 3월2일 3일에 걸쳐서 이루어졌고
3월2일 저녁에 보낸 기획에 대한 피드백이 3월4일 점심쯤 도착했다
3월3일 하루를 그냥 보낼 수 없어서
깃헙초기세팅 이후 기본적인 틀과 CSS를 작성하면서 하루를 보냈다
포트폴리오를 보고 참여를 선택할 수 있다는 점이 매력적이었으나
코딩전문으로 타겟을 좁힌 것의 장단점을 설명해주셨다
장점으로는 분명한 대상을 알고 서비스를 제공할 수 있게 되고
단점은 시장이 매우 좁아진다
서비스하는 시장의 풀이 이미 꽤 큰 경우라면 문제가 없지만 코딩 프로젝트 시장은 어떨지 조금 의문을 제기해주셨고
그래서 기획을 다시 일단은 코드를 타겟으로하는 서비스로 하되
코드에서 개발으로 타겟을 넓혀 기획자와 디자이너 마케터 PM도 가입, 사용가능 하게 확장 가능성을 뒀다
기능을 구현가능한 선에서 구분해준 점이 좋았고
CRUD에 맞게 빠진 부분없이 채워주신 점도 좋았다고 잘했다는 피드백을 받았다
프로토타입과 와이어프레임이 각각 무엇을 말하는지 정확히 이해하고 있는지에 대해서 다시 알아보면 좋겠다는 피드백을 받았다
첫번째 회고글에서 작성이 되어있다
다른 피드백들은 API 문서 수정과 같은 전체적인 기획에 대한 큰 변화는 없었다
그리고 마지막에 배포를 먼저 하라고 강력하게 권장을 해주셨는데
프로젝트 마지막 쯤에 가서야 그 이유를 알게되었다🥲
git clone <코드스테이츠 깃헙 레포 주소>
- 한명만 클론하면 된다npx create-react-app client
- 이때 클라이언트는 리액트를 사용할 것이기 때문에 앞의 명령어로 폴더를 만들어 줬다npm init
, gitignore
추가 등등이 있다git push origin main
- 초기세팅 이후 pushgit checkout -b Dev
- Dev 브랜치를 만든다git push origin Dev
- Dev 브랜치에 pushgit clone <본인 깃헙 레포 주소>
git remote add upstream <코드스테이츠 깃헙 레포 주소>
그 다음부터는 각자 팀의 규칙에 맞춰서 밑과 같이 진행하면 된다
git checkout -b feature/27-login
만약 태스크카드가 없다면 생성 후 번호 작성
git status
- 변경 파일 확인
git add App.js
- 파일 추가
git commit
→ 커밋 메세지 작성
git push origin feature/27-login
브랜치 확인
git branch
브랜치 전환
git checkout Dev
pull → 각자의 dev 브랜치에서 받아와야함
git pull upstream Dev
my repo 최신화
Fetch upstream 버튼
Github Repository 연결 확인
git remote -v
깃 로그 삭제 (기록 충돌)
$ git stash // 변경사항을 숨깁니다.
이후에 본인의 깃허브로 들어가서 코드스테이츠 Dev로 Pull request를 하고 merge하면 된다
Upstream의 Dev에서 각자 팀원들의 Dev 브랜치에서 pull 받아와서 사용하면 된다
이때 주의할 점은 Dev에서 pull 받기전에 만들어놨던 브랜치에서는 pull받고나서의 내용이 적용이 되지 않기 때문에 그곳에서는 더이상 작업하면 안된다!
무조건 Dev브랜치에서 pull 받고 난 뒤 -> 다시 브랜치를 생성해 그곳에서 작업해야한다
git checkout -> git switch
checkout의 기능이 switch와 restore로 분리되었다고 한다
switch에 대해서 팀원분들께 알려드리고 파이널 프로젝트때 사용해야 겠다
참고링크