오뚝이개발자

Git을 처음 다운받으면 초기에 설정해주어야 하는 것이 있다. 무작정 git을 다운받았다고 해서 바로 git clone을 사용해 레포지토리를 클론할 수 있는 것이 아니다. git config 명령어를 사용하여 user name과 user email을 입력해주어야 한다. 깃허브에 가입 시에 적었던 본인의 email과 user name이 필요하다. 이 두가지 정보는 보안과 관련된 정보들이니 본인만 알고 있어야 한다.(깃헙에서 사용자를 indentify하는 일종의 authentication information이라고 생각하면 된다.) 아래와 같은 명령어를 커맨드 창에 입력하여 두 가지 정보를 입력할 수 있다. git config --global user.name=본인의 깃허브 name git config --..

README란? readme란 프로젝트에 대한 간단한 설명을 담고 있는 문서이다. 일반적으로 git에서 특정 레포지토리에 들어가면 가장 먼저 보이는 main page가 바로 readme이다. 이런 readme 파일은 일반적으로 markdown 문법으로 작성된다.(확장자는 md) 쉽게 말해 readme를 작성한다는 것은 구현한 프로젝트를 문서화하는 작업이다. 그렇다면 readme 파일은 도대체 왜 작성해야 할까? 나를 위해 - 시간이 지나면 자신이 작성한 코드도 다시 읽어보아야 이해가 간다. 이처럼 나중에 자신이 보았을 때에도 쉽게 이해할 수 있도록 readme를 작성해두면 도움이 된다. 함께 작업하는 동료를 위해 - 협업을 할 때 동료에게 내가 작성한 readme는 좋은 지침서가 될 수 있다. 다른 사용..

커밋 메시지를 통일된 양식으로 작성하면 추후 어떠한 부분이 변경되었는지 알기도 쉽고 협업을 할 때도 도움이 된다. 따라서 메시지를 작성하는 컨벤션을 정리해보려고 한다. 커밋 메시지는 크게 제목(Title), 본문(Body), 꼬리말(Footer)의 세 부분으로 구성된다. Type : Title Body Footer Type 커밋하는 메시지의 타입을 설명해준다. 예를 들어, 버그 수정인지 새로운 기능의 추가인지 등이다. feat : 새로운 기능, 코드 추가 add : 파일 추가 fix : 버그 수정 refactor : 코드 리팩토링 docs : 문서 수정 style : 코드 형식, 정렬, 주석 등의 변경(동작에 영향을 주지 않는 변경사항) test : 테스트 코드에 관련된 변경 사항 chore : 빌드 업..

git init -> git저장소 시작 git status -> 파일들의 상태 확인 git add filename -> file을 git 저장소에 추가 git add * -> 변경사항 전부 추가 git commit -m "commit message" -> commit(확정) git log -> 커밋 로그 확인 git checkout branch name -> 해당 브랜치로 이동 git branch -> 존재하는 branch 확인 및 현재 있는 branch 확인(*가 붙어있음) git branch test -> test라는 브랜치 생성 git merge branch name -> 해당 브랜치를 마스터에 병합시킴 git branch -d branch name -> 해당 브랜치 제거(-d 옵션으로 인해) gi..

https://git-scm.com/book/ko/v2 Git - Book git-scm.com 위의 링크는 깃 사전과 같이 다양한 기능 및 활용법들을 모아둔 링크이다. 참고하면서 깃에 대해서 배워가며 필요한 내용들을 포스팅할 계획이다.

분명 .gitignore에 추가를 했는데 계속 반영되지 않고 변경사항에 포함되는 경우가 있다. 이 경우 git의 cache에 데이터가 남아있어서인데 아래와 같이 cache를 지워주고 다시 add all 해주면 된다. git rm -r --cached . git add . git commit -m "fixed untracked files"