Razelo 기술노트

협업을 제대로 해본 적이 없어서 협업 방식에 대해서 정리하고자 한다. 코드 리뷰도 제대로 해본 적이 없어서 협업 컨벤션이나 구체적인 루틴에 대한 이해가 필요할 것 같다. 간단하게 정리하고자 한다. 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 을 실행