- git reset 은 Head가 가리키는 브랜치가 가리키는 커밋을 변경함 - git reset --hard 커밋id1: working directory의 내용이 커밋id1 때까지로 변경됨 - history를 보면 커밋id1 때까지의 커밋이 보이고, 파일도 그 커밋에 알맞게 변경됨 - But, hard 작업을 해도 커밋 자체가 삭제되지는 않음, reset 커밋id2(id1 이후의 커밋) 해도 정상적으로 작동 (최신커밋으로 되돌아갈 때는 그 최신커밋의 id를 알고 있어야 함) >> Head가 가리키는 브랜치가 새로운 커밋을 가리키게 됨 1. reflog - 최신 커밋의 id를 모를 때는 git reflog를 사용해서 확인 가능 - git reset --hard abad 와 git reset --hard ..

맨 처음에 한 commit을 root commit 이라고 함 git은 이 루트 커밋을 기점으로 가지가 갈라지는 나무의 모양을 띠는 구조 git branch 브랜치명: 브랜치 생성, 지금까지 작업한 내용들이 이 브랜치에 속하게 됨 git checkout 가고싶은 브랜치명: 브랜치가 변경이 되고 git status 등으로 조회해도 변경된 브랜치가 뜸, 그리고 커밋들은 기존의(main) 브랜치와 상관이 없게 됨 ex) 텍스트 파일을 변경하고 main이 아닌 브랜치에서 커밋하고 checkout을 이용해서 변경했을때 변경된 브랜치에 원래(변경전) 텍스트파일이 있을때 cat을 통해 확인하면 변경되기 전 파일이 출력됨 git branch: 브랜치 조회 git branch -d 브랜치명: 브랜치 삭제 git check..

(본 내용은 코드잇 강의를 참고하여 작성했습니다.) git push -u origin master : 로컬 레포지토리의 내용을 처음으로 리모트 레포지토리에 올릴 때 사용 아래의 경우 userName 과 비밀번호 입력해야함 - 로컬 레포지토리를 github에 업로드 하면 리모트 레포지토리가 깃허브 페이지에 생성됨 (로컬 레포지토리 수정 후(새롭게 커밋 후) 'git push' 를 해줘야 리모트 레포지토리가 수정됨 ) - git push는 리모트 레포지토리의 주인(본인)만 가능, 다른 사용자는 추가 작업 거쳐야 함 settings > Manage access > invite a collaborator 버튼 > 검색 통해 사용자 찾고 버튼 눌러 초대 - 리모트 레포지토리가 변경이 됐을 때 'git pull'을..

버전 관리를 통해 지난 과정을 확인 가능하고 이전 버전으로 돌아가거나 등의 작업이 가능 이러한 버전관리는 프로그래밍 코드에 필요한 것! Git > 작성한 코드를 각각의 버전으로 관리 가능하게 해줌, 협업에도 유용 (작업한 내용을 다른 컴퓨터에서도 사용 가능 > 결과물의 백업을 생성한다는 것) 1. Repository(저장소) Git을 쓰면 프로젝트 디렉토리안에 .git이라 하는 디렉토리가 생성됨 .git 디렉토리(프로젝트의 변경 사항들이 저장됨)가 바로 레포지토리. 커밋이 저장되는 곳이 레포지토리 2. commit 프로젝트 디렉토리의 모습을 하나의 버전으로 남기는 것을 '커밋한다'라고 표현. 버전으로 남긴 그 결과물 자체를 '커밋'이라고 표현 mkdir 디렉토리명 // mkdir: 디렉토리 생성 // 디..