github

태그 앞에 공백(두칸이상)이 없어야 함

이번에 팀프로젝트를 진행하면서 깃허브로 협업하는 방법에 대해 알아보려 한다.private : 나와 내가 초대한 특정 사용자들만 볼 수 있음git add .git commit -m "message"commit message를 작성하는 방법 알아보기https://

details 태그가 적용이 안돼서 github pull request 게시글에 같이 있던 내용을 따로 분리한 내용GUI toolgithub desktop을 처음에 사용하다가cli에 익숙해지고 싶어서 cli로만 작업을 했었다.그런데 branch가 많아지고 merge 같

충돌이 일어난 부분을 일일이 확인해서 수정 후 다시 커밋default로 작업하는 branch를 sub branch에서 진행하자pull로 받을 때에도 sub branch로 받기 때문에 수정을 자유롭게 할 수 있음수정한 코드가 정상 동작하는 지 확인 후 master bra

git clone (원격 레포 git)현재 위치에서 원격레포 이름으로 폴더가 생기면서 그 안에 프로젝트가 다운 됨

github의 pull request가 아니더라도로컬에서 테스트용으로 branch를 만들고git checkout -b (A new branch name)브랜치를 새로만들고 그 브랜치로 스위칭자유롭게 수정 후 merge 할 수 있다.git checkout (merge할

개인마다 혹은 팀마다 깃허브로 협업하는 방식은 다르겠지만내가 하는 방식을 정리해보겠습니다.깃허브 collaborator로 초대를 받으면 메일로 수락또는 collaborator를 받지 못 했지만 기여하고 싶은 경우, fork를 떠서 자신의 레포로 가져간 후 수정 후 원조

진행하던 팀프로젝트를 organization을 만들어서 그곳에서 관리하자는 의견이 있어서 기존 repository를 organization에 import 해서 레포를 옮겼다.그리고 처음으로 커밋 후 푸시하려는데 이런 에러가 나왔다.인터넷에 검색을 해보니 remote u

원격(github)에 올라가지 말아야 할 파일을 올리고 gitignore를 설정한 뒤github에서 직접 파일을 삭제하면 fetch 후 pull하면 로컬의 파일도 삭제 된다.그래서 로컬파일은 보존한채 깃허브에 올라간 파일을 gitignore에 맞게 정리하는 방법이 있다

오늘 처음으로 1000 contributions을 달성했다.이대로면 꾸준히 하면 2500도 가능할 것 같다.

많이 사용하는 git cli는 암기해서 사용하고 있었다.git push origin 브랜치 이름git pull origin 브랜치 이름origin이 항상 들어가서 local에서 현재 내가 위치한 브랜치로 생각했었다.git push origin \[브랜치 이름]: 내가

github에서 코드리뷰를 하는 중팀원들한테 질문이 들어온 것에 답글을 달았는데 확인이 안되는 문제가 있었다.내 코멘트엔 pending으로 표시되었고오직 나만 확인할 수 있었다.검색해보니 submit을 하지 않으면 review에 반영되지 않아서 그렇게 보였던 것이었다.

이번에 리팩터링 스터디를 위해 github에 새로운 organization을 만들었다.https://github.com/Metacognition-Polymath스터디 인원을 슬랙으로 모았고 슬랙과 깃허브를 연동하는 작업을 했다.처음 해봤는데 생각보다 되게 쉽게

종종 다른 브랜치에 작성한 코드를 보기 위해 현재까지 작성한 코드를 임시로 커밋 후 브랜치를 바꾸곤 했다.오늘 git stash라는 것을 알게 되었고 다음에 그럴 상황이 생기면 git stash를 이용해서 의미없는 커밋을 하는 것을 지양해야겠다.참고git stash 사

새로운 브랜치를 만드는 경우엔 원격(github)을 기반으로한 브랜치로 만들자git checkout -b 새로 만들 브랜치 이름git checkout -b newFeature origin/main원격의 브랜치를 가져올 땐 origin/을 붙여줘야 한다.로컬의 main

새로운 브랜치 만드는 방법git checkout -b 새로운브랜치이름 origin/masterorigin(Github)의 master브랜치에 있는 코드를 기준으로 브랜치를 새로 만들겠다는 의미git add .git commit -m "커밋 메세지"좋은 커밋 메세지를 작

node.js 환경에서 git hook을 손쉽게 제어하도록 도와주는 매니저https://www.npmjs.com/package/huskypre-commit : 커밋이 만들어지기 전에 호출Git 과 관련한 어떤 이벤트가 발생했을 때 특정 스크립트를 실행할 수 있

git rebase -i HEAD~합칠 커밋 개수https://cjh5414.github.io/git-rebase/https://madplay.github.io/post/squash-git-commits-with-rebase

PR을 올리고 보니 git commit message에 이슈번호를 누락해서 수정해야 될 일이 있었다.로컬에서 수정을 하고 force push로 현재 올라간 PR에 덮어쓰기해서 변경된 커밋메세지가 적용되도록 했다.i => 편집모드(편집을 종료하고 싶다면 esc):wq =

회사에서 commit 시 git hook(husky 라이브러리)에서 ESLint를 먼저 검사 후 에러가 있으면 commit이 되지 않는 설정이 좋아서 세팅을 해보았다일단 차이점은 husky는 버전4 일때와 달리 버전6 이상 부터 shell script로 구성이 된다hu

이전에 husky를 사용해서 git hooks을 설정 하여 eslint를 강제하는 것에 대한 포스트를 작성했었다.https://velog.io/@gth1123/ESLint-%EA%B0%95%EC%A0%9C-%ED%95%98%EA%B8%B0-lint-staged

1. squash merge 2. rebase

github과 slack을 slackbot으로 연동하는 경우 PR(Pull Request)에 대한 알림은 구독할 수 있지만 해당 PR에서 리뷰어가 approve한 경우 알림을 받을 수 없었다github workflows를 설정해서 approve시 알림을 받을 수 있다S