React Session
create-react-app setting
- 서비스 워커 : 인터넷이 끊기면 동작 X, 하지만 오프라인에 대비해 어느정도 이벤트가 작동하도로고 미리 js를 캐시해서 돌아가게끔 도와줌
- GNB(Global Navigation Bar) : 공통적으로 사용하는 컴포넌트
- 라우터 작동 원리 : 페이지 이동시 통신 없이 js만 작동하는 원리, 클라이언트 사이드 렌더링 방식(서버와 계속 통신하는 것이 아닌 이벤트 처럼 돌아감)
Git sesstion 정리
Git 이용시 Tip
- 새로운 브랜치 생성 시 feature/~~ 규격을 사용
- 브랜치 네임은 모두 lower-case 사용
tig
merge(fast-forward 병합)
- 변경 내용의 이력이 모두 그대로 남아 있기 때문에 이력이 복잡
- 통합 브랜치에 토픽 브랜치를 불러올 경우에는 우선 rebase 를 한 후 merge
마스터 브랜치 흐름과 피쳐 브랜치 흐름이 같은 경우
- 'bugfix' 브랜치를 'master' 브랜치로 병합할 때, 'master' 브랜치의 상태가 이전부터 변경되어 있지만 않으면 매우 쉽게 병합
- 병합은 'fast-forward(빨리 감기) 병합
마스터 브랜치 흐름과 피쳐 브랜치 흐름이 다른 경우
- 'master' 브랜치 내의 변경 내용과 'bugfix' 브랜치 내의 변경 내용을 하나로 통합
- 새로운 브랜치에서 남은 이력(커밋)들이 병합이 실행되면 기존 이력도 남게 되어 지저분 해짐
- merge는 병합이 이루어지는 순간 머지 포인트가 남아서 나중에 log 볼 때 불편함
merge는 마스터로 체크아웃 한 후 새로운 브랜치를 merge
rebase (non-fast-forward병합)
- 토픽 브랜치에 통합 브랜치의 최신 코드를 적용할 경우에는 rebase 를 사용,
- 'bugfix' 브랜치를 'master' 브랜치에 rebase 하면, 'bugfix' 브랜치의 이력이 'master' 브랜치 뒤로 이동, 하나의 줄기로 이어짐
- 커밋 X와 Y 내에 포함되는 내용이 'master'의 커밋된 버전들과 충돌하는 부분이 생기면 각각의 커밋에서 발생한 충돌 내용을 수정할 필요
- merge 커밋 포인트가 안 남는 상태로 병합이 이루어져 나중에 로그 볼때 간략하게 볼 수 있음
- rebease는 새로운 브랜치에서 마스터와 병합할 때 새로운 브랜치로 체크아웃 한 후 rebase master를 하는데 그러면 master 앞 포인트로 이동해 master로 체크아웃 한 뒤 merge를 한 번 더 해줘야 함
- rebase는 conflict 수정 뒤 add, commit을 하는게 아니라 continue를 해줘야 함
git add myfile.txt
git rebase --continue
Applying: pull 설명을 추가
rebase --continue해줘야함
git reabse i- HEAD~~
merge --squash
브랜치의 모든 커밋을 하나의 커밋으로 병합
$ git checkout master
Switched to branch 'master'
$ git merge --squash issue1
Auto-merging sample.txt
CONFLICT (content): Merge conflict in sample.txt
Squash commit -- not updating HEAD
Automatic merge failed; fix conflicts and then commit the result.
$ git add sample.txt
$ git commit
[master 0d744a7] Conflicts: sample.txt
1 files changed, 4 insertions(+), 0 deletions(-)
- 'master' 브랜치로 이동한 후, '--squash' 옵션을 지정하여 merge 를 실행
- 스쿼시를 사용하는 경우는 드물다!
- 위의 명령 대로 하게 되면 마스터브랜치 기준 최신으로 되기 때문에 시간정보가 바뀌지 않는다
rebase를 할 경우 마스터를 pull 받아와 정보를 최신화 시키고 시간정보는 변경된 상태로 마스터의 최신버전으로 들어가게 됨!
3.10 은우님 추가 세션
base 의미 : 브랜치를 딴 곳
fast-forward vs non-fast-forward
- fast-forward는 본인이 딴 base가 가장 최신인 경우
- 아닌 경우에는 merge commit 지점이 생기면서 내 브랜치가 마스터에 병합
rebase
-
reabase는 6번을 기준으로 base가 변경 되고 내 브랜치가 그 브랜치 앞으로 전부 이동
-
commit 지점별로 컨플릭트를 해결 해줘야 함
=> 이런 문제를 해결하기 위해 git pull origin master를 해줘 conflict를 가능한 최소화 시킴
-
rebase 하기 전 내 로컬 마스터 브랜치에 git pull origin master를 해줘 최신상태로 반영한다음에 적용
-
rebase 할 때 자주 쓰는 명령 --squash(rebase -i 옵션)
=> 피쳐 브랜치를 하나로 된 커밋으로 묶은 다음에 rebase하는 옵션
rebase 순서
1. 로컬 마스터 브랜치를 최신으로 반영
git pull origin master
2. git rebase -i master의 기준점 2가지 경우(마스터 브랜치, 피쳐 브랜치)
- 피쳐 브랜치로 checkout 한 후 git rebase -i master
- 마스터 브랜치에서 git rebase -i master 피쳐브랜치
3. -i 옵션 설명
- 위의 처럼 pick은 squash의 기준점이 되고 s는 병합할 다음 커밋
- squash는 한 커밋 한 커밋 차례차례 진행이 되므로 보통 제일 첫 번째 단계를 pick으로 하고 나머지를 s로 하여 단계별로 confilct를 해결해 나간다.
4. confilct 발생한 파일을 수정
5. conflict 발생 시 해결 하고 git add . => git rebase --continue
6. git push origin 피쳐브랜치
7. 코드 리뷰를 받고 커밋 다시하기
- 코드 수정하고 git add
- git commit -m "메세지"
- git rebase -i master
- confilct 있으면 수정하고
- git push origin 피쳐브랜치 --force (force push는 본인 피쳐 브랜치에서만 해야 함)