8주차 - 금요일

mangjell·2022년 5월 6일
0

목차

  1. 앞으로의 프론트엔드 >>> Frontend
  2. 서비스 안정성 높이기 >>> isSubmitting
  3. git으로 협업하기 >>> Gitflow-Workflow

React - input 알고리즘 -

  • 년월일을 입력했을때, 자동적으로 .이 붙게 하는 것

  • sentry.io => 에러가 어디서 났는지 수집하고, 어떤 ip에서 발생했는지 확인해준다!
    => 슬랙이랑 연결가능

사용법: 

try {
	
} catch (error) {
	sentry.send(error) // 이부분
}

gitflow workflow

새로운 브랜치 만드는 명령어: git checkout -b 브랜치명
각각의 브랜치에서 만든것들을 develope이라는 브랜치에 합치는 것
-> 중간에 버그가 있으면 못합치게하고, 여러사람이 만든것을 하나의 develop에 합치게 되는 형태이다.

배포 시, develop을 master에 합치고, 배포는 master의 결과물을 배포하는 것이다.
이때, 문제가있다!!!
해놓고 봤더니 버그가 와장창 쏟아진다!
그렇다면 어떻게 해야하는가?

-> 보조 브랜치를 둔다(release branch)
release branch에 합치고, 버그를 발견 시 수정하고, 또 수정하고, 버그가 안나올때까지 한다. => 그러면 이때, master 브랜치에 합치는 것이다.
=>>> 그 master 브랜치를 배포하게 된다는 것이다.

-> release branch에 올라오면 기능을 추가하지않는다. (버그만 잡는 용도)

-> 기능 추가는 develop에 하는 것!!

그런데 마스터 브랜치에서 우리가 잘 배포를 했는데, release branch에서 버그를 충분히 잡았다고 생각했는데, 그런데, 배포 시 버그가 또 발생했다!!

=> 어쩔 수 없다. master에서 고쳐버리자해서 => hotfix 브랜치로 이동하는 부분이다!
(git checkout -b hotfixes) <- 이 명령어는 마스터 브랜치에서 명령을 치는 것이다.(위치가 *master) 이라는 소리

다른 브랜치에서 checkout -b 해서 만드는 거랑 master 브랜치에서 checkout -b 하는 것이랑 다르다.

=======================================================

위치가 굉장히 중요하다.(어디서 checkout했느냐가 굉장히 중요!!)

다시 말하면, develop브랜치에서 초록색을 놔두고, release branch로 checkout을 한것이다(아래그림 노랑이 초록이 부분)

master브랜치에서 hotfixes로 checkout을 한 것이다(위에그림 하늘이 다홍이 부분)

develop에서 feature branches로 checkout한 것이다(아래
그림 노랑이 분홍이 부분)

예를 들어 develop 브랜치에 상품결제, 로그인 부분의 코드들이 있다고 가정하자, 현재 위치를 develop 브랜치에 두고, git checkout -b feature-branches를 하면, feature-branches에 develop안에 있는 상품결제, 로그인 부분의 코드들이 다 들어가있게 되는 것이다!!!

=========================================================
예시)

회사 레파지토리가 있고, 아래에 철수, 훈이, 영희 레파지토리가 있다고 가정하자.
fork를 뜨면, 회사 레파지토리안에 있는 내용이 그대로 만들어진다.

그 후 철수, 훈이, 영희가 각자 자신의 레파지토리에 있는걸 clone을 받아서 vscode로 가져온다.

(접근 권한을 주어서 master branch는 접근 못하게 해야한다던지 이런방식을 추천!)

다시,

철수는 게시판등록
훈이는 상품등록
영희는 결제하기 기능을 맡는다고 가정하자.

=> 그렇다면 각자의 branch가 있을 것이다.(feature createboard, feature product, feature payment등)

=> 철수는 본인의 feeature createboard를 철수 레파지토리에 push해야한다. 회사 레파지토리에 push하면 막혀있을 것이다.
=> 훈이는 훈이 레파지토리에, 영희는 영희레파지토리에 push한다.

(여기까지 그림)

그렇다면 회사레파지토리에 pull request를 올린다. (팀장님 풀 해주세요!)
그렇다면 회사레파지토리에서 철수레파지토리, 훈이레파지토리, 영희레파지토리의 내용을 pull한다.

합칠 때의 케이스가 많다

매일 아침에 다같이 모여서 코드리뷰를 한다던지 수정해서 다시 pr날려달라는 얘기를 많이 한다.(pr = pull request)

pull을 하게 되면 develop브랜치에 합쳐지게 되고, 버그가 있는 부분은 수정후에 다시 합치게 된다.

=>>> develop 브랜치가 업데이트가 되었다.

그 후, 모두가 자리에 돌아간다. (회사 레파지토리에서 pull 받는 법)
철수는 develop 레파지토리에서 pull을 받는다 (git pull upstream develop)
훈이도 develop 레파지토리에서 pull을 받는다 (git pull upstream develop)
영희도 develop 레파지토리에서 pull을 받는다 (git pull upstream develop)

그렇다면 develop은 업데이트가 되었으니 해당 위치에서 금일 해야하는 일들 기준으로 git checkout 을 따서 작업을 하는 것이다!!

회사레파지토리: upstream

철수 훈이 영희 레파지토리: orgin

git pull origin master => 철수 레파지토리에서 땡겨 받는것
(여기까지 그림 아래)

주의사항

  1. 서로 겹치지 않는 기능 만들기
  2. 잘하는 사람이 공통 모듈 만들기
  3. 머지가 안된 상태에서 의존적인 기능 추가하지 않기

철수가 등록 만들고, 훈이가 조회, 영희가 수정을 만들고 있다고 가정하자.
-> 회사레파지토리에서 셋을 합칠 때, 충돌이 일어난다!!!!(conflict!!!)

그래서, 서로 다른 기능들을 만들어야한다(겹치지 않는!!)

겹치는 기능들은 있을 수 밖에 없다. 그렇다면, 팀에서 잘하는 사람이 공통 모듈을 만들어서 develop에 merge한다(내부에서 사용하는 라이브러리를 만드는 것 (여러사람들의 상황을 고려해서 만들어야한다)) => 한번 잘못만들면 진짜 망한다!!!!!진짜진짜!!!!!꼭!!!꼭!!!

만약 철수가 등록부분을 빠르게 만들어서 시간이 남았다. pr만 올려놓고 수정하기 부분을 만든다? 이때 문제가 발생할 수 있다!!!
=> 등록때 만들었던 컴포넌트를 재사용해서 수정페이지를 만든다? (pr만 올려놓고 merge도 되지 않았는데?) >>> 문제가 될 수 있다!!!!!!!!!

원본에가면 Issue라는 것이있다. => 할당량을 관리하는 부분
ex) 트랠로, 지라 등을 활용!

-> new issue 해서 issue 작성!

-b : 없는 브랜치를 만들고, 이동하기!
그냥 git checkout 브랜치이름: 그냥 이동하기!

#넘버를 가지고 feature branch를 만들기!
git checkout -b "feature-#2" >>> 이런식으로!

잘못만들면, git checkout main하고, 다시 브랜치를 다시 딴다!!

git remote -v:
git add .
git commit -m "내용"
git push origin 본인 레파지토리
master로 push 하는 것이 아니다

커밋 컨벤션 => 커밋 규칙!!!

git remote add upsream 원본주소 : upstream 추가!

git remote -v 하면, 아래와 같이 origin두개, upstream두개가 나오게 된다!

그 후에,

git checkout develop

git branch 해서 develop에 초록불 들어오는지 보고,

회사 레포에서 버그가 없는 부분들을 확인하고, merge를 한다 그 후에,

git pull upstream develop

하고, 다시 금일 할당량을 해야하는 부분을 git branch 따서 만들고의 반복이다!!

profile
프론트엔드 개발자

0개의 댓글