TIL. 최종프로젝트(8) git rebase 활용법
[오늘 한일]
- 퀴즈결과 처리 기능 작성.
- 웹소켓 알림기능 준비.
팀 진행
- 소셜로그인+simpleJWT 토큰 연계까지 포함 기능 완성
- 이메일 인증, 이메일 패스워드 초기화 기능 작성
- 웹소켓, 쿠키이용 사용자 인증, 인증정보 활용까지 진행
[오늘 배운점]
DRF
<몇가지 알게된 점>
팀원분들이 작성하신 기능을 동작해보고 살펴보면서 몇가지 포인트를 알게되었다.
- allauth 라이브러리는 장고 설정 settings에 SITE_ID 설정을 필요로 한다.
그리고 이는 DB에 생성된 site 인스턴스의 pk값을 가르켜야 한다.
allauth.socialaccount.models.SocialApp.DoesNotExist: SocialApp matching query does not exist.
이런 site나 socialapp설정이 올바르지 않을때 만날수 있는에러, status code 500과 함께 발생한다.
- 카카오 소셜 로그인은 다른 형태의 소셜로그인과 이메일이 겹칠 여지가 있다.
이메일이 겹치고 해당 소셜로그인을 먼저 연결했다면,
소셜 사용자가 아닙니다라는 카카오 안내페이지가 나오는데, 메세지가 정확하진 않아서 헷갈릴수 있다.
- 이메일 인증기능은 장고의 core, contrib에 포함되있는 모듈로 작성할수 있다.
이메일 인증기능을 적용하면 모듈이 내포한 db 몇개가 필요해진다.
모델 변경사항은 없더라도, migrate를 한번 진행시켜서 모듈내 필요 db가 생성되게 해야 잘 동작한다.
migrate를 진행하지 않았다면, smtplib.SMTPSenderRefused: 에러를 만날수 있다.
- simpleJWT와 장고channels는 연계 사용이 불가능하다.
GIT
<git rebase로 최신 커밋에 재배치하기>
새로 배운점은 아니지만 오늘 팀원분들께 공유해드린 내용이다.
최신 커밋으로 재배치하고 싶은 순간은.
내 작업커밋을 pull request하려고 할때일 것이다.
나는 22번째 커밋에서 작업브랜치를 만들어 작업사항을 1개의 커밋으로 만들었다고 가정해보자.
내가 작업하는 사이 어느새 develop브랜치가 23번째 커밋까지 진행이 된것이다.
이때 내 작업 브랜치의 내 1개 커밋을 22번째에서 파생된 것이 아닌,
23번째에서 파생된것으로 재배치 시킬수 있다.
과정은 이렇다.
1. 메인 레파지토리 develop 브랜치 ↔ 내 fork 레파지토리 develop브랜치를 sync fork하여 맞춘다.
(내 develop브랜치는 (작업브랜치가 아니니) 깔끔할 것이고 fast forward로 병합된다.)
(여기서 충돌이 난다면, 내 fork 레파지토리 develop브랜치에 작업커밋이 반영되서 그렇다. reset등으로 없애주자)
2. 내 fork 레파지토리 develop브랜치 ↔ 내 로컬 develop브랜치. git pull로 내려 받는다.
(여기서도 충돌이 나지 않고 fast forward로 병합된다. 내 로컬 develop도 작업 커밋이 없어야 한다.)
3. 최신화된 내 로컬 develop 브랜치 ↔ 내 작업 브랜치. 내 작업브랜치로 체크아웃하여, git rebase develop을 입력한다.
여기서도 왠만하면 충돌이 발생하지 않는다.
내 작업커밋을 그대로 뽑아서, 22번에서 파생되었던 것을 23번에서 파생되게 만들기 때문이다.
※ 충돌이 발생한다면 23번 커밋과 내 작업커밋이 완벽히 같은 것을 건드린 부분이 있다는 것이다.
하지만 보통은 같은 부분을 건드릴 일이 잘 없으며,
23번까지가 커밋 반영된 시점에서 내 커밋이 반영되는 식이니,
코드 줄이 스마트하게 위치를 잡으며 충돌이 생기지 않는다.
반면, 다른 두 커밋 파생을 머지하는 경우에는 많은 부분을 충돌로 잡게된다.
그래서, 어떤 저장소를 어디로 pull 할건지에 유의해야한다.
최신화한 내 레파지토리 develop브랜치를 내 작업브랜치로 바로 병합하는건,
같은 22번에서 파생된 다른 두 커밋트리를 병합하는 거라서 충돌해결과 추가 커밋이 발생하게 된다.