Razelo 기술노트

아침에 좀 코드를 짜는데 git 동작 중에 내가 모르던 부분이 있어서 잠시 헷갈려서 이참에 내용 다시 정리한다.코드 좀 짜고 git diff를 했는데 왜 추가된 내역이 안나오지? 싶었다. diff는 분명 working tree staging간에 비교하는거 아닌가? 싶었다. 그런데 결론은, git diff의 경우는 파일이 새로 추가된 경우는 보여주지 않는다고 한다. 즉 추가되었는데 아직 untracked상태라서 git diff를 해도 보이지 않고 추가한 뒤에 수정을 하면 tracked가 되므로 그때부터는 약간의 코드 수정을 하고 git diff를 하면 보인다고 한다. 그리고 untracked상태인 파일이 추가된게 있는지 보려면 git status를 하면 된다. ㅋㅋㅋ... 이런건 가끔 가다가도 분명 ..

협업을 제대로 해본 적이 없어서 협업 방식에 대해서 정리하고자 한다. 코드 리뷰도 제대로 해본 적이 없어서 협업 컨벤션이나 구체적인 루틴에 대한 이해가 필요할 것 같다. 간단하게 정리하고자 한다. https://backlog.com/git-tutorial/kr/ git 기본 명령어 정리 https://wecandev.tistory.com/152 인덱스(index): 커밋할 변경사항을 모아놓은 궁간임. 작업 폴더(work Tree)의 변경내용을 인덱스에 기록하는 것을 스테이지(Stage)라고 한다. 머지(Merge): 선택한 브랜치에 다른 브랜치에서 커밋한 내용을 병합하는 동작임. 컨플릭트(Conflict):동시에 같은 파일의 유사한 부분을 수정한 경우 발생하는 코드충돌을 의미하고 의도에 맞는 코드를 선택..

성공적인 git flow 모델이라고 하는 글이 있다. 개념 잡기에 좋은 글이다. https://nvie.com/posts/a-successful-git-branching-model/ A successful Git branching model In this post I present a Git branching strategy for developing and releasing software as I’ve used it in many of my projects, and which has turned out to be very successful. nvie.com

아래와 같이 조금 더 디테일하게 적어줄 수 있을 것 같다. 이전에는 feat, docs, style, chore 등은 쓴 적이 없고 Delete, Add, Fix, Test와 같은 type만 적어줬는데 아래 처럼 feat, docs, refactor 등을 활용할 수 있을 것 같다. 이모지로 표현하는건 개인적으론 별로 좋지 않은것 같다. 근데 이건 그냥 개인 취향이라 하고 싶은 사람은 팀에서 잘 논의해서 결정하면 될 것 같다. 아래 양식 정도만 따르면 큰 문제는 없을 것 같다. feat : 새로운 기능 추가 fix : 버그 수정 docs : 문서 수정 style : 코드 포맷팅, 세미콜론 누락, 코드 변경이 없는 경우 refactor : 코드 리펙토링 test : 테스트 코드, 리펙토링 테스트 코드 추가 ..

아래와 같은 명령어를 입력한다. git config --global init.defaultBranch 이후에 아래 명령어를 통해 바뀐 default branch name을 확인할 수 있다. git config --global init.defaultBranch 아래와 같이 보여질 것이다. 참고로 원격에 있는 github 에서도 default branch 를 변경할 수 있다. 굳이 하지 않긴 하는데 방법은 아래와 같다. settings -> 좌측 메뉴에서 branchs 선택 -> Default branch 에서 switch to another branch 선택 -> 변경

최근 실습때문에 Hyper-v 를 on으로 바꿀 일이 있었는데 이후에 코딩을 하던 중 git push origin main이 먹히질 않는 문제를 발견했다. 보기에는 단순히 로그인 access가 만료되었다고 떠서 다시 로그인하면 될 것 같은데 사실 문제는 그게 아니다. Hyper-v를 켜둬서 문제가 생긴거다. 왜 Hyper-v가 영향을 준건진 모르겠지만 방금 확실하게 테스트해본 결과 Hyper-v를 켜두면 git push 가 안먹히고 Hyper-v를 꺼두니 이제서야 git push 가 잘 먹힌다. 어떤 연관관계가 있을까. 지금은 모르겠다. 확실한건 도커든 뭐든 간에 뭘쓰다가 이상하다 싶으면 혹시 며칠전에 Hyper-v 관련해서 작업해본 적이 있었는지 떠올려보면 될 것 같다.

private repository 에서 작업하면서 인증키를 등록해놓은 상태여서 push 하는데 문제가 없었다. 다만 문제는 근 몇주간 클라우드 세팅때문에 코드 작업을 거의 진행하지 못했는데 갑작스레 인증키가 invalid 하다는 에러가 떠서 push 가 되지 않았다. 우선 아래와 같은 명령어를 입력해주자. $ ssh-keygen 이후 passphare 등을 묻지만 그냥 엔터로 입력하고 지나가도 무방하다. 그리고 나서 키가 생성되는 위치와 함께 키 생성이 완료됬음을 알 수 있다. 그리고 cat 명령어를 통해 id_rsa.pub 키를 알아낸다. 자 이제 이 pub 키를 github 에 가서 등록해줘야지만 private repository 에 push 를 할 수 있다. 그리고 이후 아래와 같은 과정을 거쳐서 ..

저번에 프로젝트 하다가 충돌나서 그지점부터 로그 전부다 잃어버리고 고생꽤했던 기억이 있는데 기말고사 끝나면 이 영상으로 내용 좀 확실하게 알아놔야겠다. (참고로 복구못함 ㅠ) https://www.youtube.com/watch?v=wVUnsTsRQ3g

오늘 프론트 팀에서 api 하나를 추가하달라고 하셔서 잠깐 이것저것 만지고 있었다. 오랜만에 들어와서 만지는거라 잠깐 어색한 순간에 에러가 나는 것을 그냥 --force로 눌러버렸다. (솔직히 말하면 살짝 귀찮았다. 근데 대가가 너무 참혹했다.) git push -u --force origin main 문제없겠지하고 깃허브에서 리포를 살피는데 이런... 커밋 히스토리가 모두 날라갔다. 엥 왜 1커밋이 있지? 하고 살폈는데 이전 기록이 모두 사라졌다. 사실 예전에도 이런 경우가 한번 있었다. 170 커밋정도가 있었는데 정말 말 그대로 시원하게 싹 날렸었다. 아마 세달전이었던 것 같다. (근데 그때는 사실 혼자 작업하는 기간이어서 크게 문제가 되진 않는다고 생각하고 계속 진행했었다. ) 그런데 이번에는 팀원..

왜 언제가부터인가 .gitignore가 적용되지 않는다는 사실을 발견했다. 현재 프로젝트를 진행하면서 yml 파일을 제외시키려고 사용하고 있었는데 갑자기 안된다. 브랜치들을 살펴보니 그리 오래된것 같지는 않았고 커밋 서너번 전부터 이런 현상이 나타났던 것 같다. 해결법은 간단하다. git의 캐시문제라고 한다. git bash 에서 아래와 같은 명령어를 친다. (마지막에 점 찍는거 빼먹으지 마시구) 들고있던 캐시 전부 비워주자. git rm -r --cached . 그 다음은 하던대로 똑같이 진행해주면 된다. git add -A git commit -m "removed git cach" 뭐 이런 식으로 하던대로 진행되면 된다.

git init git branch -m main git remote add origin "github.com/your_ropo.git" git add . git commit -m "first commit" git push -u origin main 만약 git push -u origin main 에서 error: failed to push some refs 에러가 발생한다면 git push -f origin main 을 실행

유용하게 쓸 수 있는 깃 컨벤션을 정리해놓았다. 우리 팀에서 쓰던 건데 팀원분께서 친절히 정리해서 올려주셨다. 기왕이면 지켜서 쓰자. 🧬 Git Branch Convention 형태 : 이름/기능이름_날짜 1️⃣ 각 단어 전부 소문자 - E.g. nickname/signin 2️⃣ 한 기능을 자주 수정해야 할 때 날짜 붙이기(날짜 양식 : YYMMDD) - E.g. nickname/signin_211125 📝 Git Commit Convention 형태 : 커밋타입: 커밋 메시지 - E.g. Add: 카카오 로그인 구현 커밋 타입 리스트 - Add: 기능 추가 - Fix: 코드 수정 ❗️ 잘못된 코드 수정 - Delete: 기능 삭제 - Refactor: 코드 리팩토링 ❗️ 잘 되어있는 코드 수정 - T..

1. git checkout // 변경할 branch로 checkout 2. git branch -m // 새로운 이름으로 local branch의 이름을 바꿈 3. git push origin -u // 새로운 이름으로 된 branch 를 remote에 push 4. git push origin --delete // 변경 전 branch 를 remote에서 삭제