공부 기록일지📚

🟡 gh(github cli)를 사용하게 된 이유? - 1월 원티드 프리온보딩 FE 챌린지에 참여하면서 gh에 대해서 알게됐다. bash를 통해 git을 사용하고 있었기 때문에 gh가 뭔지 알지 못했고 찾아보니 github CLI였다. 이슈 생성이나 원격 리포 페이지 열기(gh browse 명령어 등..) 간편한 명령어가 매력적이라 사용해보고 싶었다. 🟠 gh 다운로드 및 세팅하기 for window 제가 사용하는 운영체제는 window로 window에서는 homebrew(macOS용 오픈소스 소프트웨어 패키지 매니저)와 같은 패키지 매니저가 마땅하지 않은 거 같아서 그냥 .msi 확장자 파일로 다운받아 설치하였습니다. 파일은 공식 repo를 통해서 찾을 수 있습니다. msi 는 microsoft Ins..

브랜치 종류 main(구: master) : 프로젝트 최종 배포 중심 브랜치 develop: 개발이 진행되는 브랜치, 배포할 수준의 기능을 갖추면 relese 브랜치로 머지 feature: 기능을 개발하는 브랜치, develop 브랜치에서 파생되는 브랜치며 develop 브랜치로 머지 release: 개발된 내용을 배포하기 위해 준비하는 브랜치, 충분한 테스트를 통해 버그를 검사하고 배포할 준비가되었다고 판단하면 main으로 머지하여 배포한다. 버그 수정 내용을 develop 브랜치에도 반영하고, 최종적으로 main에 머지 hotfix: 출시 버전(main)에서 버그를 수정하는 브랜치, main브랜치에서 생성되며, 수정이 완료되면 dev, main 브랜치에 수정 사항을 반영 브랜치 네이밍 feature:..

git을 소수 인원으로 사용할 때에는 push, pull, merge만 사용해도 큰 문제가 없습니다. 개인 프로젝트할 때에는 그렇게 했구요. git history도 깔끔했습니다. 하지만 소수인원이 아닌 회사에서 협업하게 된다면 git history가 엉망이될 겁니다. 이럴 때 우리가 사용할 수 있는 기능이 rebase입니다. 개인적으로 sourcetree라는 git GUI툴을 사용하지만 사용하면 사용할수록 시각적인 매력 외에 불편함을 느끼고 있었습니다. CLI가 익숙해지면 계속 그것만 사용하게 될거라는 분도 계셨구요. CLI로 진행하게 된다면 git history가 깔끔하게 정렬되어 있는 게 좋을 거 같았습니다. Merge와 Rebase의 차이? Git에서 한 브랜치에서 다른 브랜치로 합치는 방법으로는 ..

깃허브 → 내 PC 로 브랜치 내용 덮어쓰기 [문제상황] 로컬과 원격의 main 레포 작업 내용이 뒤엉켜서 pull로 땡겨온다 해도 로컬의 main에서 commit을 해놨기 때문에 변경사항이 존재함 즉 땡겨와도 보내도 컨플릭트가 불가피한 상황 -> 제가 원했던 건 가장 최신화된 main브랜치의 내용을 로컬 main으로 가져오기만 하면 되는 것이라서 로컬 main의 이전 데이터가 날라가도 상관이 없었습니다. 즉, 깃허브에 있는 원격 main 브랜치의 내용을 가져와서 로컬 저장소의 main 브랜치에 덮어쓰고 싶은 상황 👉방법 (vscode에서 bash사용, 운영체제: window) *평소에는 sourcetree를 사용하나 git 명령어로 하는 것이 더 편리하여 아래와 같은 방법으로 해결하였습니다. *여기서 ..

.gitignore 파일을 수정해서 무시할 파일들을 추가했는데 sourcetree에서 해당 파일들을 무시하지 않고 그대로 반영했다. 노드 모듈을 다 올리는 건 오바잖니... 이를 해결하기 위해서는 아래의 명령어로 Git의 캐시를 지워주면 된다. 2,3 번째 줄은 bash에서 실행해도 되고 나처럼 sourcetree에서 스테이징하고 커밋 메세지를 작성한 뒤에 push해도 된다. git rm -r --cached . git add . git commit -m "fixed untracked files" + yarn.lock 파일을 gitignore에 넣어서 무시해야할까? A. yarn.lock은 github에 올려서 같이 관리해야한다. gitignore에 포함시키면 안됨! 부가설명: yarn.lock 파일은 ..

Merge conflict - 서로 다른 브랜치에서 같은 파일을 수정하고 그 브랜치들을 합칠 때(merge) 충돌이 일어나는 상황을 말합니다. 일부러 merge conflict 상황을 만들어봅시다. feature/stock feature/jjigae_rtan 두 개의 새로운 브랜치를 생성하고 둘은 같은 파일 jjigae.txt를 수정한 뒤, stock을 먼저 main에 merge (이 때는 충돌나지 않습니다.) 그 다음 jjigae_rtan을 main으로 병합(merge)하려고 할 시 아래와 같은 충돌 병합 메세지가 뜬다. 우측 하단에 GIt에서 자동으로 작성해준 파일내역입니다. jjigae.txt 충돌 병합은 같은 파일을 수정했을 시 어떤 코드를 반영할 거냐고 묻는 것과 같다고 했습니다. HEAD의 경..

conflict(충돌)은 같은 파일을 다른 팀원들이 같이 수정했을 때, Git이 어떤 것을 원격 repo에 반영할거야? 하고 물어보는 것이다. 이런 '충돌'을 해결하기 위해서는 아래와 같은 작업방식이 필요하다. ✅협업 프로젝트 3단계 누가 이 작업을 할 것인지 정한다. (이슈할당) - Issue 각자 맡은 것을 작업한다. - Branch 각자 작업을 프로젝트에 합칠 수 있게 공유한다. -merge (경우에 따라) 작업한 내용을 리뷰하고 최종적으로 프로젝트에 반영한다. - PR 후 merge 프로젝트에서 issue는 프로젝트에서 해결해야하는 문제로 아래와 같은 것이 있다. 버그(프로그램이 원하는 대로 작동하지 않는 것)를 신고(bug report) 기능 추가 등의 프로젝트 개선 제안(enhancement)..

+ 2022 08 10 추가 프로젝트를 진행하면서 sourcetree관련 인증오류의 8할은 결국 github의 내 accessToken 기한이 만기된 이유가 가장 컸어요! 혹시 내 토큰이 기한이 만기된 것은 아닌 지 우선적으로 확인해봅시다. Github에서는 2021년 8월 13일부로 password authentication을 공식적으로 제거하고 personal access token만을 사용하도록 정책을 변경했습니다. 우리가 이전에 repo에 접근할 때 아이디 패스워드를 이용하던 것이 아이디 토큰 방식으로 변경된 것이라고 생각하면 됩니다. 하지만 sourcetree에서는 인증에 실패하였을 때도 새로 비밀번호를 입력하게끔 해주지 않는다고 합니다. 소스트리를 삭제하고 새로 깔았을 시에도 계속해서 비밀번호..