뼈대잡기
오늘 할일
- 로또당첨 핸들러 구현
오늘 한일
- 로또당첨 핸들러
- 피셔 예이츠 셔플 적용
- dev에 merge -> conflict 대박적으로 남
- 첫 mainline merge
for문과 forEach문 중에 뭘 써야 할까? 뭐가 빠를까?
유정 튜터님이 splice 대신 shift나 pop을 써보는 것이 좋겠다고 말씀해주셨는데, 뭔가 성능에 대한 궁금증이 생겨 찾아보았다. 🤔
for: ES1부터 있었던 문법
forEach: ES5부터 추가된 문법
dev 브랜치에 머지가 안돼요 - 브랜치 보호 룰과는 상관이 없었다
문제상황
feat/lh -> dev로 merge하던 도중 conflict가 많아 깃헙에서 solve가 안되는 상황 발생
VS CODE에서 conflict solve 완료
의문 - 컨플릭트를 다 고쳤는데 왜 PR화면이 바뀌지 않을까?
브랜치 프로텍트 룰때문에 컨플릭트 솔브가 안되는건가? 원인을 알 수가 없어서 고민해보다 튜터님을 찾아뵈었다.
- 상황: VS Code에서 컨플릭트는 다 고쳤는데 이거 어떻게 반영하지? -> 에서 헤맴
튜터님의 말씀
- 일단 브랜치 프로텍트 룰과는 상관이 없다
- 본인 피쳐 브랜치에 먼저 반영되고 dev로 넘어가야 한다
- 코드가 완전히 같지는 않았을것 같다. 완전히 같았다면 커밋이 되었을 것
- IDE에서 고쳤어도 고친 코드를 커밋해줘야 로컬에 반영 -> 푸쉬 해야 리모트에 반영
- 커밋하고 올린 상태로 다시 들어가보지 않았을 것이다!
나의 의문
그럼 깃헙 상에서 solve가 가능한 경우는 자동으로 제 피쳐에 커밋푸시를 해주나요?
-> 그건 아님. 깃헙에서 솔브하는 경우는 커밋할거야? 라고 묻겠지. 커밋푸시는 컨플릭트 해결하고 내가 알아서 해야 하는 것
깨달음
IDE에서만 다 고쳤다고 conflict가 solve되는게 아니다
-> IDE에서 컨플릭트 다 고쳤으면 내 피쳐 브랜치에 다시 커밋 - 푸쉬 해줘야 dev와 컨플릭트 없이 맞아들어가는 것
-> 여기서 안 해줬으니까 conflict solve 안되는 건 당연함
Git은 파일명의 대소문자를 구분하지 못한다 - 설정에서 변경할 수 있구나
이걸 입력하면 파일명의 대소문자가 바뀌었을 때 구분해서 변경점으로 잡아준다.
git config core.ignorecase false
갑자기 왜 춤춰?