개발 일기

Critical ● 공개 저장소와 비공개 저장소 ● 공동 작업자 추가하기Important ● README.mdNice to Have ● 마크다운 ● Github Gists, Github Pages 공개 저장소는 누구나 접근이 가능하다. 단, 저장소의 내용을 변경할 수 있는것은 아니다.비공개 저장소는 공동 작업자로 추가되어야만 접근할 수 있다. 공동 작업자로 추가된 사람은 변경 사항을 저장소에 푸시할 수 있게된다. * 깃허브 공동 작업자 추가 방법 * README.md프로젝트가 무슨 일을 하는지 설명하기 위한 마크다운 파일이다. 루트 폴더에 추가해두면 깃허브에서 내용을 렌더링해서 페이지에 보여준다.마크다운이란?형식화된 텍스트를 만드는 간결하고 편리한 구문이다.텍스트..

Critical ● 원격 추적 브랜치 ● git fetch/pull 협업을 하지 않고 로컬 저장소만 사용할 거라면 fetch, pull은 필요없다. 하지만 협업할 계획이라면 매우 중요하다. * 원격 추적 브랜치로컬에서의 브랜치는 앞서 다뤄봤으므로 익숙할 것이다. 하지만 clone이나 remote를 통해 원격 저장소와 동기화를 이루고 나면 "origin/main"과 같은 새로운 브랜치가 생성된다. 이 브랜치가 원격 추적 브랜치이다.마지막으로 원격 저장소와 통신한 시점을 기억하는 포인터라고 생각하면 된다. 추가로 커밋 후 git status 실행 시, 로컬에서만 작업했을 때와는 다른 메시지가 출력된다. "origin/main" 브랜치에 비해서 커밋 1개가 앞서있다는 얘기이다.앞서 말했듯이 원격..

Critical ● 깃허브가 하는 일 ● git clone ● 깃허브 등록 및 SSH 키 설정 ● 깃허브 저장소 만들기 ● 원격 작업 ● git push * Github 란?깃 저장소를 위한 호스팅 플랫폼이다.깃 허브에 등록한 저장소가 포트폴리오가 될 수 있다.최신 정보를 얻기에도 매우 유용하다. git clone 로컬에 없는 저장소를 가져온다.깃허브의 공개 저장소에 있는 것들은 모두 클론이 가능하다. 단, Push는 불가능하다.그리고 거의 대부분의 경우에 깃허브가 쓰일 뿐이지 깃허브만 가능한것이 아니다. git clone 명령어도 github와 관계가 없다. 깃허브 등록 및 SSH 키 설정 (Windows 기준) * 왜 SSH 키를 사용하는가?✅ 1. 보안 강화 ●..

Critical ● 커밋 체크아웃 ● 분리된 HEADImportant ● 변경사항 무시하기 ● git restore(복원)/reset(재설정)/revert(되돌리기) git checkout 명령어로 브랜치를 생성하거나 이동하는것 말고도 이전 커밋을 확인 할 수도 있다. git checkout HEAD를 해당 커밋으로 이동시킨다. 명령어 실행 시 HEAD가 분리된 상태라는 메시지가 출력된다.브랜치는 언제나 해당 브랜치의 최근 커밋을 가리키고 HEAD는 그 브랜치를 가리키게 된다. 일반적으로 HEAD는 커밋이 아닌 특정 브랜치를 참조하게 된다.하지만 해당 명령어를 통해서 HEAD가 특정 커밋을 참조하도록 바꾼다. 원래 브랜치를 참조하던것이 커밋을 참조하게 되었으므로 분리된 상태가 된 것..

Important ● 스태시의 기초 ● git stash save/popNice To Have ● git stash 적용 ● 스태시 삭제 ● 여러개의 스태시로 작업하기 스태시는 유용한 기능이지만 반드시 사용해야 하는 상황은 발생하지 않는다.대부분 save와 pop을 사용한다. 브랜치에서 작업을 하다가 완료되지 않은 상태라서 커밋을 하지 않고 다른 브랜치로 이동해야 하는 경우에는 상황에 따라 해당 작업이 이동하는 브랜치로 따라오거나 깃에서 브랜치를 이동하지 못하도록 막는(병합 커밋 발생 예상 시) 두 가지 옵션이 존재한다.이 때 스태시를 사용한다. git stash (=git stash save)커밋되지 않은 변경사항을 저장하고 변경사항들을 모두 초기화 시킨다.내용이 삭제되는것이..

Critical ● git diff 명령어 실행 결과 읽기 ● git diff 명령어의 기본적인 사용 방법Important ● 브랜치, 커밋, 특정 파일의 비교 ● git diff --stage git diff는 깃에서의 변경 사항들을 보여주는 명렁어이다.git status나 git log처럼 저장소에 아무런 영향을 미치지 않는 명령어이다.git diff스테이지에 등록되지 않은 작업 영역의 변경사항을 모두 나열한다.(아직 스테이지에 올라가지 않은 상태)(작업 영역 파일의 변경사항을 알려준다)(각 라인을 해석하면 위와 같다)a는 커밋된 파일, b는 작업 영역의 파일이다.git diff HEAD마지막 커밋이 실행된 이후의 변경사항을 모두 나열한다.마지막 커밋 이후 변경 사항을 스테이지에..

Critical ● Fast-Forward(빨리 감기) 병합 ● git merge & merge commits ● 병합 충돌과 해결 방법Nice To Have ● VS Code 사용을 통한 충돌 해결 방법병합의 2가지 원칙 ● 특정 커밋이 아닌 브랜치를 병합한다. ● 항상 현재 HEAD 브랜치에 병합한다. ● Fast-Forward(빨리 감기) 병합 1. 목적지(병합하려는) 브랜치로 이동한다. (B를 A에 합치고 싶다면 A로 이동) 2. git merge B 실행 3. A의 브랜치가 B의 브랜치를 따라잡게 된다. 병합을 하더라도 병합 대상의 내용들이 브랜치에 추가되는 것은 한 순간이고 동기화가 계속 이뤄지는것은 아니다. 여전히 별개의 브랜치로 존재한다...

Critical ● 브랜치는 무엇이고 왜 사용하는가? ● HEAD에 대해 이해 ● 명령어 git branch/switch/checkoutImportant ● 브랜치 삭제와 이름 변경 ● 브랜치 이름 (master vs main)Nice To Have ● HEAD & Refs behind the scenes 브랜치도 커밋처럼 매일 또는 자주 다루게 될 것이다. 커밋은 고유의 해시를 가지고 부모 커밋 하나를 참조하고 있다. 어떤 팀에서 각각 진행하는 작업의 내용이 진척도가 서로 다르고 작업 내용이 추후 적용된다고 했을 때, 순차적인 커밋은 불가능하다고 볼 수 있다.이 때, 브랜치로 작업을 분기시켜서 별도로 진행하다가 추 후 합칠 수 있다. 작업은 항상 브랜치 위에 존재한다. ..

Critical ● git ignoreImportant ● 커밋의 원자적 유지 (Atomic commits) ● 좋은 커밋 메시지 작성법 ● 깃 문서 탐색Nice To Have ● GUI 사용 ● Amending commits (커밋 변경) 깃의 문서는 https://git-scm.com 에서 볼 수 있다. 명령어의 기능이 궁금할 때 레퍼런스를 참조하면 된다. ● 커밋의 원자적 유지 (Atomic commits)가능하다면 커밋은 단일 기능이나 단일 변화, 수정만을 포함시켜야 한다.한 커밋에 모든 변경사항들을 통합한다면 커밋을 롤백할 때 많은 작업들을 취소해야 할 수도 있다. ● 커밋 메시지 작성현재 시제의 명령형 커밋 메시지를 사용할 것을 공식적으로 권장하고 있다.예를들어..

Critical ● 깃 저장소의 개념 ● 명령어 git init/status ● 커밋의 흐름 (명령어 git add/commit/log)Important ● .git 폴더에 대한 이해 깃 저장소는 작업 공간이다.git init현재 있는 디렉토리를 새 저장소의 홈으로 만든다. init을 실행하기 전에 status로 먼저 확인해 주는 것이 좋다.git status현재 저장소의 상태를 확인한다. .git 폴더를 삭제하면 저장소의 이력까지 모조리 사라진다. 저장소 안에 또 다른 저장소를 넣지 말아야 한다. (초기화된 저장소 안에서 또 초기화를 하지 말라는 뜻)깃이 깃을 추적하기 때문에 혼란스러워진다. ● 커밋이란?프로젝트의 변경 사항이 있는 일종의 체크포인트.깃은 3개의 다른 영역으로 구분..