production / development 로 배포 환경을 분리하면 브랜치를 merge 할 때 development의 배포 환경이 production으로 merge 되어 버리는 문제가 발생한다. 이때 .gitattributes라는 것을 이용해 특정 파일이 merge 되는 것을 막을 수 있다. chat gpt에 따르면, .gitattributes 파일은 git의 동작을 지정하는 데 사용되는 파일이라고 한다. 이 파일을 사용하여 파일의 텍스트 인코딩, 줄 종료 스타일, 이진 파일 처리 등을 저장할 수 있다고 한다. 파일 패턴 다음에 병합 전략을 설정하여 해당 파일을 병합에서 제외한다. 가장 일반적인 전략은 “merge=ours”이다. 이 전략은 현재 브랜치의 변경 사항을 유지하고, 병합 대상 브랜치의 변경..
이번 글은 소스트리에서 'WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED' 에러를 해결한 기록입니다. 참고 자료 블로그를 읽어보니 접속 서버에서 새로운 서버나 ssh를 설치했을 때 발생하는 에러라고 하는 것 같았어요. 소스트리에서 다음과 같은 에러가 발생한 이유를 생각해 보면, (저의 추측으로는) bitbucket.org에 새로 서버나 ssh 설치를 하게 되었고, ip는 같은 걸 사용해서 기존에 연결 되어있던 ssh 인증이 새로운 서버, ssh 측에서 연결되지 않았기 때문 아닐까라는 결론을 내려보았어요 :) 저는 다음과 같은 방법으로 해결했습니다❗️ 1. 다음의 명령어로 /Users/[사용자 명]/.ssh/known_host에 있는 ssh-key를 삭제합니다. ssh..
git commit을 하려는데 다음과 같은 에러가 발생했다. nuxt 프로젝트 생성할 때, Style에 전부 체크 했더니 husky라는 것이 같이 받아졌는데 저걸 따로 추가하지 않아서 에러가 발생했다. yarn add husky --save-dev 설치 후 아래의 에러가 발생했는데 Code style issues found in the above file(s). Forgot to run Prettier? 이 에러는 아래의 명령어로 해결할 수 있었다. npx prettier --write . commitlint 까지 받아졌는지 아래의 에러도 발생했는데 이 부분은 git commit convention을 따라주면 해결이 된다. (ex. git commit -m "feat: 식당 뽑기 기능 추가")
깃 브랜치를 정말 아무렇게나 사용하고 있었는데 최근 깃 강의를 듣고 브랜치를 규칙에 따라 사용해보면 협업에 수월함이 있지 않을까 싶어 정리해보고 사이드 프로젝트에 먼저 적용해 보려고 한다. Git branch strategy 프로젝트 규모가 커지고 인원도 늘어나게 되면 하나의 레파지토리 내에 일정한 규칙이 존재해야 합니다. 저의 경우 소규모이지만 그래도 규칙은 필요한 것 같습니다 관리가 너무 어려워요ㅠ 오늘 공부한 깃 브랜치 관리 전략은 국내에서나 해외에서 통상적으로 사용하는 패턴이라고 합니다. 보통 Repository를 처음 만들고 나면 Branch 명은 Master로 생성이 됩니다. (인프런 깃 강의를 들어보니 요즘은 master보다는 main으로 사용하길 권장한다고 합니다.) 저는 main을 mas..
퇴근 하기 전에 커밋을 하고 가야하는데 가아끔 깜빡하고 그냥 집에 갈 때가 있다 그럴 때는 커밋을 아래와 같이 하면 된다고 한다 GIT_AUTHOR_DATE=2022-05-13T12:00:00 GIT_COMMITTER_DATE=2022-05-13T12:00:00 git commit -m "commit..!"
reset 옵션에 대해 이해하려면 깃의 3가지 공간에 대한 이해가 선행되어야 한다 깃의 3가지 공간은 아래와 같다 1. Working directory 2. Staging area 3. Repository 이렇게 세 가지 공간이 있는데 1번에서 file들을 저장하고 add 하면 2번으로 이동하고 2번에서 commit하면 3번으로 이동한다 파일을 수정하면 3번에서 다시 1번으로 돌아간다 git reset options --soft: repository에서 staging area로 이동 --mixed (default): repository에서 working directory로 이동 --hard: 수정사항 완전히 삭제 (repository에서 아예 세 가지 공간 중 어느 곳에도 속하지 않음) git check..
git rebase 는 merge와 다르게 브랜치를 남기지 않고 그 부분을 떼서 합치려는 브랜치의 최종 커밋 이후에 붙이는 방식이라고 한다. 보통 merge를 사용해서 작업했는데 굉장히 많은 사람이 작업하는 프로젝트에서는 merge를 하게 되면 브랜치가 너무 많이 남아서 지저분해질 수 있다고 한다. rebase를 하는 방법은 먼저 rebase 할 브랜치로 이동한 다음 아래의 명령어를 입력한다. git rebase [이동할 브랜치 이름] pull을 할 때도 merge와 rebase를 사용할 수 있는데 아래의 명령어를 입력한다. git pull --rebase pull을 하고 충돌이 일어나면 충돌을 해결한 후 아래의 명령어를 입력한다. git rebase --continue 앞으로는 merge와 rebase..
git merge를 하다가 충돌이 일어나고, 병합이 힘들다 생각되면 충돌의 상태에서 commit을 하지 않고 아래의 명령어를 입력하면 merge 전의 상태로 돌아간다 git merge --abort 제대로 파는 Git & GitHub - by 얄코 수강 하며 공부한 내용입니다!
