git
버전관리란?
파일을 버전별로 저장하고 나중에 특정시점에 버전을 다시꺼내올수있는 시스템
장점
- 지난 과정확인 가능
- 이전 버전으로 돌아갈수있음
- 다른 컴퓨터에 작업물 전송가능 → 백업본을 만들수있다. 협업이 가능하다.
git은 버전관리와 동시협업을 할수있게 도와준다.
git hub
깃으로 버전 관리 해놓은 프로젝트를 올려놓을 수 있는 원격저장소의 역할을 해주는 서비스
레포지토리 (저장소)
깃이 버전별로 바뀌는 모습(커밋)을 기록해놓는 곳이 레포지토리
<aside> 💡 .git 디렉토리 = 레포지토리
</aside>
커밋
프로젝트 디렉토리의 특정 모습을 하나의 버전으로 남기는 동작 & 결과물
git init
현재 디렉토리를 git이 관리하는 프로젝트 디렉토리로 설정하고, .git 디렉토리 즉, 버전관리를 해주는 git 디렉토리를 생성해준다.
커밋하기 전에는 깃에서 커밋한 사람을 알려줘야한다.
git config user.name "mer"
git config user.name "mer@mail.com"
커밋의 주의 사항
- 처음으로 커밋을 하기 전 사용자의 이름과 이메일 주소를 설정
- 커밋 메세지 남기기
- 커밋할 파일을 git add로 지정해주기
깃의 3가지 작업 영역
- working directory : 작업을 하는 프로젝트 디렉토리를 말한다. 즉, .git 디렉토리가 존재하는 파일
- staging area : git add를 한 파일들이 존재하는 영역. 커밋을 하게 되면 staging area에 있는 파일들만 커밋에 반영된다.
- repository : working directory의 변경 이력들이 저장되어있는 영역 즉, 커밋들이 저장되는 영역 = .git 디렉토리
git status
깃이 인식하고 있는 프로젝트 디렉토리의 현재 상태를 보여준다.
→ staging area에 파일이 올라와있는 지 확인할 때 사용하면 좋다.
깃 파일의 상태
- untracked 상태 : 추적되고 있지 않는 파일 git에 의해서 그 변동사항이 전혀 추적되고 있지 않는 상태(파일을 생성하고 한번도 git add를 안해주면 이 상태이다.)
- tracked 상태 : 파일이 git에 의해 그 변동 사항이 추적되고 있는 상태
- staged 상태 : 파일의 내용이 수정되고 나서 staging area에 올라와있는 상태
- unmodified 상태 : 현재 파일 내용이 최신 커밋의 모습과 비교했을때 전혀 바뀐게 없는 상태인 파일 (커밋을 하고 난 직후에 working directory안의 모든 파일들이 이상태가 된다.)
- modified 상태 : 최신 커밋의 모습과 비교했을 때 조금이라도 바뀐 내용이 있는 상태
git reset [파일이름] : git add를 통해 staging area에 올라온 파일을 staging area에서 제거한다.(변경된 새모습은 남아잇다.)
working tree = working directory
git hub
깃허브의 레포지토리 = 원격 레포지토리
내컴퓨터의 레포지토리 = 로컬 레포지토리
git push : 로컬 레포에서의 새로운 커밋을 리모트 레포(깃헙)로 반영한다
- git push --set-upstream(-u) origin master : 로컬 레포지토리의 내용을 처음으로 깃헙 리모트 레포로 보낼 때
git pull : 리모트 레포(깃헙)에서 새로운 커밋을 로컬 레포로 반영한다.
리모트 레포를 두고 push pull을 하면 좋은점
- 안정성 : 백업가능
- 협업 가능
- 원칙적으로 자신의 리모트 레포지토리에는 자신만 git push 가 가능하다
- 만약 다른 사용자도 git push를 할수잇게 해주려면 그사용자를 해당 리모트 레포지토리의 collaborator로 지정하면된다.
git clone : 깃허브 프로젝트의 레포지토리를 그대로 복제
commit 히스토리
git log
커밋 히스토리 필드
- 커밋 아이디
- 커밋한 사람
- 커밋 날짜
- 커밋메세지
git show [커밋아이디]
해당 커밋과 전 커밋의 차이점을 보여준다.
-m 옵션 없이 git commit 만으로 텍스트 에디터에 커밋메세지 남기기
⇒ 복잡하고 긴 커밋 메세지를 쉽게 남길수있다.
—amend
최신 커밋을 수정해서 다시 새로운 커밋으로 만들기
커밋의 3가지 정보
- 커밋을 한 사용자 아이디
- 커밋한 날짜 시간
- 커밋 메세지
커밋 메세지 작성 가이드 라인
- 커밋 메세지의 제목과 상세설명 사이에는 한줄을 비운다.
- 커밋메세지의 제목뒤에 “.”을 붙이지 않는다
- 커밋 메세지의 제목의 첫번째 알파벳은 대문자로 작성
- 커밋메세지의 제목은 명령조로 작성
- 커밋 상세 내용
- 왜 커밋을 했는지
- 어떤 문제가 있었는지
- 적용한 해결책이 어떤 효과를 가지는 지
- 다른 사람들이 자신의 코드를 바로 이해할수있다고 가정하지 말고 최대한 친절하게 작성
커밋할 때 알아야할 가이드 라인
- 하나의 커밋에는 하나의 수정사항 하나의 이슈를 해결한 내용만 남기록 하세요 다양하게 수정을 하고 나서 하나의 커밋으로 남기는 것은 좋지 않다. 하나의 커밋이 하나의 사실만을 갖고 있어애 나중에 이해하기 쉽다.
- 현재 프로젝트 디렉토리의 상태가 그내부의 전체코드를 실행했을 때 에러가 발생하지 않는 상태인 경우에만 커밋하자 나중에 동료 개발자가 특정 커밋의 코드로 실행했을 때 에러가 발생한다면 혼란을 줄수있다.
정리하자면
- 나중에 다시봤을 때 이해하는데 어려움이 없도록
- 다른 동료 개발자와 협업하는데 방해가 되지않도록
aliasing
특정 명령어에 별명을 붙여주는 명령어
git log --pretty=oneline을 git history라는 별명으로 바꿀 수 있는 명령어
⇒ git config alias.history 'log --pretty=oneline’
git diff [비교하고 싶은 커밋아이디] [비교하고 싶은 커밋아이디]
두 커밋 간의 차이를 출력
💡 staging area에 있던 것들은 커밋을 하고나면 사리지지않고 계속 남아있다. git add를 할때 마다 staging area에서는 새로운 파일이 추가되거나 원래있던 파일이 더 새로운 버전의 것으로 교체되거나할뿐이다.
HEAD
어떤 커밋 하나를 가르킨다.(보통 최근에 한 커밋을 가르킨다.)
HEAD가 가리키는 커밋에 따라 working directory 구성된다.
git reset [옵션][커밋 아이디] : 옵션에 다라 하는 작업이 달라짐(옵션을 생략하면 —mixed 옵션이 적용됨)
- HEAD가 특정 커밋을 가리키도록 이동시킴(—soft는 여기까지 수행)
- staging area도 특정 커밋 처럼 리셋 (—mixed는 여기까지 수행)
- working directory도 특정 커밋처럼 리셋(—hard는 여기까지 수행)
그리고 이때 커밋아이디 대신 HEAD의 위치를 기준으로 한 표기법(ex . HEAD^, HEAD~3)을 사용해도 됨
git tag[태그이름][커밋아이디]
특정 커밋에 태그를 붙임 → 커밋을 한번에 잘 알아볼수있다.