원격 push 내용에 대한 git rebase

병합과 기준 재지정(rebase) 비교 | Atlassian Git Tutorial

이미 push하고 PR 후 머지까지 한 내용에서 추가가 되었으면 하는 부분이 생겨서, 이에 대해 git rebase를 해 보려 한다.

여기 두 번째 커밋 내용에서 수정을 해서 다시 올릴 수 있을까? 로컬에서는 아직 브랜치가 남아있지만, 원격에서는 브랜치가 삭제가 된 상태이다.

수정을 해서 커밋을 한 후 squash로 rebase를 하려 했지만, previous 커밋이 존재하지 않아 일단은 실패했다.

squash

git rebase -i 베이스로_삼을_브랜치

pick 첫번째 커밋
squash 두번째 커밋

이렇게 하면 두 번째 커밋이 첫 번째 커밋과 합쳐지면서 새로운 커밋이 만들어지게 된다.

굉장히 복잡해 보이는 로그인 플로우 computed 사용해 간단하게 코드에 나타내기

유저의 상태가 일반 U, 플리토 F, 관리자 A이냐 혹은 글의 상태가 Editing, Waiting, Rejected, Published냐 로그인을 했느냐 하지 않았냐 isAuthorized에 따라서 각각의 버튼들이 보여지고 사라지는 로직을 짜는 데 있어 if문 안의 조건문이 너무 복잡해지는 어려움이 있었다.

좀 더 간단하게 코드에 나타내기 위해서 일단 각 컴포넌트들의 v-if 조건문들을 생각해봤다.

글 status 배지 
: isAuthorized && (writer_id === USER.id || USER.user_type === ‘A’)

수정하기 삭제하기 
: isAuthorized && (writer_id === USER.id || USER.user_type === ‘A’)

거절사유 이의제기 
: isAuthorized && POST.status === ‘R’ && (writer_id === USER.id) || USER.user_type === ‘A’)

좋아요 
: !isAuthorized || (USER.user_type !== ‘A’ && POST.status === ‘P’)

그리고 해당 조건문들 중에서 공통적으로 줄일 수 있는 부분들을 줄인다.

지금의 경우에는 줄여서 만들어 낸 조건들이 asyncData로 받아온 POST, USER 데이터를 활용하기 때문에 asyncData안에 const 변수로 선언해주고, 밖에서 선언해도 괜찮은 종류들은 computed로 계산해주었다.

어떨 때 computed를 사용해야 하는 것인지는 좀 더 찾아볼 필요가 있을 거 같다. 지금에서는 몽땅 다 asyncData에 넣어도 되는 게 아닌지 의심이 든다.