협업

최근 간단한 협업 프로젝트를 하면서 .gitignore때문에 고생한 적이 있었다. 그래서 개념을 확실하게 잡아두고, 다음부터는 .gitignore때문에 스트레스를 받지 않고싶어서 게시글을 작성한다. 내가 겪었던 상황을 그대로 재현했고, 이를 해결하는 과정도 담았다 초기 세팅 폴더를 2개 만들어줬다 src 폴더는 소스파일이 올라가는 곳으로, 깃허브에 올려야하는 파일들이 저장된다 bin 폴더는 컴파일된 .class파일이 올라가는 곳으로, 굳이 깃허브에 올릴 필요 없는 파일들이 저장된다 각각 올려야하는 파일, 올리면 안되는 파일을 넣어두고 초기 커밋했다 clone 받기 일단 클론을 받고 내가 수정할 곳을 수정해준다 bin 디렉토리 내부 파일은 변경시켰고 src파일에는 새로운 파일을 추가시켰다 i_want_pu..

상황1: 이전 커밋 메시지를 바꾸는 법: amend 이렇게 오타를 내서 feat라고 적어야하는데 fat으로 적어버렸다!! 이 상황에서는 amend를 사용하면 된다 git commit --amend i를 눌러 오타낸 커밋 이름을 바꿔주고 esc :wq를 해주면 된다 잘 수행된 걸 볼 수 있다 잘못된 커밋메시지를 덮어썼다! 상황2: 이전이전의 커밋메시지를 바꾸는 법: rebase 로그를 보다 이상한 커밋을 발견했다! (fat??) 이전 커밋이 아니라서 --amend를 사용할 수 없는데, 어떻게 해야하지? 이 상황에서는 rebase를 사용하면 된다 git log 일단 수정해야할 커밋의 위치를 확인한다 최근에서 2번째 커밋이므로, 다음을 입력한다. git rebase -i HEAD~2 (2번째 이전이라면 해당 ..

학습계기 이전에 프로젝트를 하며 깃허브를 많이 사용해봤고, 풀리퀘스트를 날리거나 간단한 이슈생성도 해본 적이 있다. 하지만 commit, push, ammend 등 자주 사용하는 명령어만 계속 사용했고, 제대로 된 깃허브공부는 해본 적이 없었다. 그래서 깃허브의 head 개념도 잘 몰랐고, 커밋메시지를 바꾸는 등의 다양한 상황에서의 깃허브의 명령어도 사용해보지 못했다. 우테코 프리코스 과제를 진행하는 중에도 커밋메시지를 잘못 작성했을 때 많이 헤맸었다. 그래서 이번 기회에 테코톡 등을 보면서 깃허브 사용법에 대해 공부해보려고 한다! 첫 번째 학습 강의: merge, rebase, cherry-pick (해당 강의를 듣고 정리합니다) https://www.youtube.com/watch?v=b72mDco4..

https://github.com/angular/angular/blob/22b96b9/CONTRIBUTING.md 커밋 메시지를 잘 적는건 중요하다. 형식을 정해두고 커밋을 할 경우 더 읽기 쉽고 한 눈에 들어오게 된다. 위의 문서를 참고하여 커밋메시지 가이드라인에 대해 간단하게 정리해보려고 한다! 위에서는 개념을 정리하고, 밑에서는 다양한 예제를 보며 커밋메시지에 익숙해지려고 한다. 커밋메시지 구성요소 (): header는 필수이며, 헤더 내부의 scope는 선택사항 body가 있고 footer에는 issue에 대한 closing reference가 포함되어야 한다 간단한 예시 docs(changelog): update changelog to beta.5 fix(release): need to depe..

프론트와 협업하여 프로젝트 몇 개를 진행하면서 늘 CORS에러를 겪었다. 열심히 백엔드 개발을 마치고 API를 배포하면 프론트쪽에서 항상 연락이왔다. CORS에러가 난다고.... 그 외에도 preflight라는 OPTIONS 메서드를 쓰는 요청을 보내시곤 CORS에러가 난다고 말씀하셨던 적도 있다. 당시 검색해봤을 때는 본 요청을 보내기 위한 사전요청이라고 하였는데, 왜 보내는지에 대한 이해하지 못하고 급하게 OPTIONS 요청만 열어서 에러를 처리했던 기억이 있다. 다른 사람들도 협업 과정에서 CORS에러를 많이 만난다고 하는데, 다신 보고싶지 않은 에러다 ㅜ 이번에 싹 정리해보려고 한다! https://www.youtube.com/watch?v=-2TgkKYmJt4 해당 영상을 많이 참고하여 공부하고..

보호되어 있는 글입니다.