2023. 5. 5

Junghan Lee·2023년 5월 5일
0

TIL Diary

목록 보기
46/52

프론트엔드의 미래 & 나의 방향

웹 -> 모바일 웹 -> ReactNative, Flutter [크로스플랫폼]
코드를 직접 작성하는 것이 아니라 불러옴!

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

1) PWA : 모바일 앱의 기능을 웹서비스로 구현하는 것, 웹과 네이티브 앱의 기능 모두의 이점을 갖도록 수 많은 특정 기술과 표준 패턴을 사용해 개발된 웹 앱

2) 시각화(d3.js) : 현재에도 필수적임, 공부 필요

3) 인공지능(tensorflow.js) : 거의 백 영역이었지만...

4) webRTC webRealTimeCommunication(녹음, 영상기능) : zoom 등

5) webGL(2D, 3D 기능 확장; etc)figma, GoogleSpreadSheet ...)

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

PWA,시각화 필수, 나머지 하나 골라서 파보자

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

GitHub로 협업하기

1) Gitflow Workflow => 고전적인 방식

가장 유명하고 많이 쓴다.
주기적 릴리즈(1~2주) 사이클을 갖고 있는 프로덕트에 도입하기 좋음
브랜치가 많아 복잡하다(단점)
git flow는 main 브랜치, develop 브랜치의 2개의 디폴트 브랜치를 두고 서브 브랜치에서 작업한다.

메인 브랜치

사용자가 직접 쓰게 될 소스 코드만 존재한다. 절대 개발중인 소스 코드가 있으면 안됨.

📍hotfix 브랜치 : main브랜치의 서브용, 프로젝트 긴급 수정 시 사용하는 브랜치로 완료된 hotfix 브랜치는 하나는 main, 하나는 develop 브랜치로 넘긴다.

develop 브랜치

develop 브랜치에서 개발하며, 브랜치를 합쳤다가 지웠다가 등 develop 브랜치를 개발할 때는 feature 브랜치를 따서 feature 브랜치 위에서 작업한다.

📍feature 브랜치 : feature에서 작업하고, 결과물을 develop 브랜치로 집어 넣는 일련의 과정을 반복하며 기능을 쌓아 놓음 (작명 예시 feature-createBoard)

📍Release 브랜치 : develop 브랜치에 기능들이 어느정도 쌓이고 릴리즈 주기도 되고 해서 릴리즈를 하기로 팀에서 결정하게되면 Release 브랜치를 따서 작업(테스트 등) 후 main 브랜치에 1개, Develop 브랜치에 1개 똑같은 코드를 넘겨주고 끝낸다.

2) Trunk Based Development (Continuous Integration / Continuous Deployment/Delivey ; CI / CD) => 자동 EC2 배포, 테스트코드 작동

=> 배포 전문가가 있을 때(최신 방식)

Forking Repository?

과정

1) upstream(최상위 repository;회사)에서 fork(origin)
2) git clone
3) 작업 완료 후 push
4) pull request

📌 git pull upstream develop : upstream에서 local로 바로 당겨옴
📌 오픈소스 메인테이너 / 컨트리뷰터 : 라이브러리(ex.react-slick)
메인테이너 : 컨트리뷰터가 commit한 사항을 승인할지 말지 결정
📌 지켜야할 규칙들
1일1PR하기 : 커뮤니케이션의 중요성(호환 등의 문제)
commit convention 잘 지키기 ex) commit -m "fix:~"
각 PR에 독립적인 기능을 담기

fork

다른 사람의 Github repository에서 내가 어떤 부분을 수정하거나 추가 기능을 넣고 싶을 때 해당 respository를 내 repository로 그대로 복제하는 기능이다. fork한 저장소는 원본(fork한 대상 repository)와 연결되어 있다.

여기서 연결 되어 있다는 의미는 original repository에 어떤 변화가 생기면(새로운 commit) 이는 그대로 forked된 repository로 반영할 수 있다는 것이다. 이 때 fetch나 rebase의 과정이 필요하다.

그 후 original repository에 변경 사항을 적용하고 싶으면 해당 저장소에 pull request를 해야 한다. pull request가 original repository의 관리자로 부터 승인 되었으면 내가 만든 코드가 commit, merge되어 original 에 반영된다. pull request 하기 전까지는 내 github에 있는 forked repository에만 commit한 사항이 적용된다.

요약

Repository에 권한이 없는 사용자가 저장소를 fork하고 fork한 자신의 저장소에 변경 사항을 적용한 후 Push한다. 이 후 원래 저장소(original repository)에 내 저장소에 있는 브랜치를 Pull Request 한다. 내가 만든 코드가 승인되면 해당 저장소에 Merge 된다.

clone

clone은 특정 respository를 내 local로 복사해 새로운 저장소를 만드는 것이다. 이 새로운 저장소는 clone의 대상이 된 원본 repository를 origin으로 가지고 있으며 권한이 없을 경우 해당 저장소로 push 할 수 없다.

또한 기존의 제일 처음 original repository와 연결되지 못하기 때문에 저장소의 commit 등의 로그를 볼 수 없다.

소규모 팀에서 활용하는 예시

A, B가 팀 프로젝트 진행을 위해 github에 새로운 repository를 하나 만들고 각각 local 환경에 해당 저장소를 clone해 작업한다.

이후 변경 사항들을 commit하고 A가 먼저 github remote repository에 push할 경우 B가 push하기 위해서는 A가 먼저 push, origin/master에 변경 사항을 적용했기 때문에 해당 변경 사항을 로컬에 적용하기 위해 A가 수정한 commit을 B가 Fetch하고 Merge해야 한다.

profile
Strive for greatness

0개의 댓글