버전 관리 : 파일의 변화를 시간에 따라 기록했다가 나중에 돌아갈 수 있음
- 지난 과정 확인 가능
- 이전 버전으로 돌아갈 수 있음
동시협업
다른 컴퓨터의 작업물 보기 (백업본 만들기)
깃허브 : 원격 저장소
Git
Repository
커밋이 저장되는 곳, 저장소
디렉토리의 초창기 모습부터 최근 모습까지 나와있음
commit
프로젝트 디렉토리의 특정 모습을 하나의 버전으로 남기는 행위& 결과물
commit할 당시의 디렉토리 모습이 사진처럼 레포지토리에 저장
레포지토리 만들기, 커밋하기
git init
git init-> 현재 디렉토리를 Git이 관리하는 프로젝트 디렉토리(=working directory)로 설정하고 그 안에 레포지토리(.git 디렉토리) 생성
- 처음으로 commit을 하기 전 사용자의 이름과 이메일 주소를 알려줘야 함
config : 설정하다 구성하다
git config user.name "이름"git config user.email "이메일"
- 커밋할 파일들 지정해줘야 함
.을 하면 변경 사항이 있는 모든 파일 내용 다 반영
git add .
git add a.txt- 커밋메시지 남기기 (옵션 -m)
git commit -m "커밋메시지"Git의 작업 영역
working directory (working tree)
작업을 하는 프로젝트 디렉토리
staging area (index)
git add를 한 파일들이 존재하는 영역
커밋을 하게되면 staging area에 있는 파일들만 커밋에 반영된다.
repository
working directory의 변경 이력들이 저장되어 있는 영역 (커밋들이 저장되는 영역)
.git 디렉토리가 repository이다.
git add
git status깃의 현재 상태 출력 (staging area에 수정한 내용들이 다 포함되어 있는지 확인)
깃으로 보는 파일의 4가지 상태
Untracked 상태
파일이 Git에 의해서 그 변동사항이 전혀 추적되고 있지 않는 상태
파일을 새로 생성하고 그 파일을 한번도 git add 해주지 않았을 때
Tracked 상태
파일이 Git에 의해 그 변동사항이 추적되고 있는 상태, 3가지 상패로 나뉜다.
1. Staged 상태
파일의 내용이 수정되고나서, staging area에 올라와있는 상태를 Staged(스테이징된, stage area에 올려진) 상태
새로 생성한 파일에 내용을 쓰고 git add를 해주거나
내용을 수정하고 git add를 해준 상태
2. Unmodified 상태
현재 파일의 내용이 최신 커밋의 모습과 비교했을 때 전혀 바뀐 게 없는 상태
커밋을 하고 난 직후 working directory의 상태
3. Modified 상태
최신 커밋의 모습과 비교했을 때 조금이라도 바뀐 내용이 있는 상태
git reset
git add 취소하기
staging area에서 파일 제거
변경된 새 모습은 그대로 working directory에 남아있음
git reset calculator.pystaging area에서 calculator.py를 없앰
특정 git 커맨드의 사용 방법을 알고 싶을 때
git help [알고 싶은 커맨드 이름]man git- [알고 싶은 커맨드 이름]Github
git push -u origin master : 로컬 레포지토리의 내용을 처음으로 리모트 레포지토리에 올릴 때 사용
Local->Remote
git push
Remote->Local
git pull
리모트 레포지토리 사용 이유
1. 안전성
2. 협업 가능
git clone [프로젝트의 GitHub 상 주소] : GitHub에 있는 프로젝트를 내 컴퓨터로 가져오기
원칙적으로 자신의 리모트 레포지토리에는 자신만 git push를 할 수 있다.
만약 다른 사용자도 git push를 할 수 있게 해주려면 그 사용자를 해당 리모트 레포지토리의 collaborator로 지정하면 된다.
Commit
git log커밋 히스토리 볼 수 있음
git log --pretty=oneline커밋 히스토리 한줄로 깔끔하게 볼 수 있음
git show [커밋 아이디 (기니까 앞 4글자 정도만 적어도 됨)]어떤 파일이 어떻게 변했는지 확인 가능
옵션 m 없이도 커밋 메시지 남기는 방법
그냥
git commit치면 텍스트 에디터 (맥에서는 vim)으로 커밋 메시지 쓸 수 있음 (유닉스챕터에서 배웠던 것처럼 메시지 작성 후 저장)
복잡하고 긴 메시지를 쉽게 남길 수 있다.
최신 커밋 수정하기
git commit --amend수정하다, 고치다.
최신 커밋을 수정해서 다시 새로운 커밋으로 만들 수 있음
커밋할 때 알아두면 좋은 점
-
커밋 메시지 작성 가이드라인
(1) 커밋 메시지의 제목과 상세 설명 사이에는 한 줄을 비워두기
(2) 커밋 메시지의 제목 뒤에 온점(.)을 붙이지 말기
(3) 커밋 메시지의 제목의 첫 번째 알파벳은 대문자로 작성하기
(4) 커밋 메시지의 제목은 명령조로 작성하기(Fix it / Fixed it / Fixes it)
(5) 커밋의 상세 내용에는 다음과 같은 것을 적으면 좋다.
왜 커밋을 했는지
어떤 문제가 있었고
적용한 해결책이 어떤 효과를 가지는지
(6) 다른 사람들이 자신의 코드를 바로 이해할 수 있다고 가정하지 말고 최대한 친절하게 작성하기 -
커밋할 때 알아야할 가이드라인
(1) 하나의 커밋에는 하나의 수정사항, 하나의 이슈(issue)를 해결한 내용만 남기도록 해야한다. 다양하게 수정을 하고나서 하나의 커밋으로 남기는 것은 좋지 않음 하나의 커밋이 하나의 사실만을 갖고 있어야 나중에 이해하기 쉽다.
(2) 현재 프로젝트 디렉토리의 상태가 그 내부의 전체 코드를 실행했을 때 에러가 발생하지 않는 상태인 경우에만 커밋 하기. 나중에 동료 개발자가 특정 커밋의 코드로 실행했을 때 에러가 발생한다면 혼란을 줄 수 있기 때문
길이가 긴 커맨드를 짧게 줄이는 방법(alias)
git config alias.[별명] ['커맨드']
git config alias.history 'log --pretty=oneline'이렇게 쓰고 실행하고 나면 앞으로 git history라고만 써도 자동으로 git log --pretty=oneline을 실행하게 된다.
두 커밋 간의 차이 보기
git diff 커밋아이디1 커밋아이디2HEAD
어떤 커밋 하나를 가리킴
(보통 가장 최근에 한 커밋을 가리킴, 매번 더 새로운 커밋을 가리킴)
HEAD가 가리키는 커밋에 따라 working directory 구성
git reset
과거 커밋으로 아예 돌아가고 싶을 때
git reset --hard 커밋아이디HEAD가 과거의 커밋을 가리키게 할 수 있다.
working directory의 내용도 과거 커밋의 모습으로 돌아가게 한다.
staging area에 있던 내용들은 그대로 남아있다.
3가지 옵션
몇개의 영역까지 reset 하느냐
- --hard : 커밋 이후로 한 작업이 모두 사라짐 (3개 영역)
- --mixed : working directory의 모습은 안 바뀜 (2개 영역)
- --soft : repository만 바뀌고 나머지는 안 바뀜 (1개 영역)
git reset --hard 7f3d
커밋아이디로 가리킬수도 있지만 다른 방법도 있다.
git reset --hard HEAD^바로 이전 커밋을 가리킴
git reset --hard HEAD~2현대 HEAD가 가리키는 커밋보다 2단계 전에 있는 커밋
tag
중요한 커밋에는 커밋 메시지뿐만 아니라 태그라는 것을 담기도 한다.
git tag [태그 이름] [커밋 아이디]각 태그와 연결된 커밋이 보고 싶다면
git show [태그 이름]branch
하나의 코드 관리 흐름
on branch main : 메인 브랜치 위에 있다. (레포지토리를 만들고 커밋을 하면 자동으로 생기는 기본 브랜치)
브랜치 조회
git branch브랜치 생성
git branch [브랜치 이름]브랜치 이동 하기
git checkout [가고싶은 브랜치 이름]브랜치 삭제하기
git branch -d test브랜치 생성 후 바로 이동
git checkout -b [브랜치 이름]브랜치 merge 하기
merge : 병합하다, 합치다.
git merge masterconflict
머지를 하다가 충돌 발생
해결 방법
1. 컨플릭트가 발생한 파일을 연다.
2. 머지의 결과가 되엇으면 하는 모습대로 코드 수정
3. 커밋
머지 자체를 취소해도 된다. (이전 상태로 돌아감)
git merge --abort파일 여러개에서 conflict가 발생횄을 경우
파일 하나씩 conflict를 해결하고 git add [파일 이름] 커맨드로 하나씩 staging area에 올리거나(중간중간에 git status 커맨드로 현재 상태 확인하면서)
모든 파일들의 conflict를 다 해결하고, git add . 커맨드로 한번에 staging area에 올리고
커밋을 하면 된다.
HEAD와 브랜치의 관계
HEAD : 어떤 커밋 하나를 가리킴 (커밋을 직접적으로 가리키진 않고 브랜치를 가리킴)
branch : 코드를 관리하는 하나의 흐름 -> 커밋을 가리킴 -> 포인터
git reset을 할 때 HEAD는 같은 브랜치를 가리키고 HEAD가 가리키는 브랜치가 다른 특정 커밋을 가리키게 되는 것이다.
git reset을 한다고 그 이후의 커밋이 사라지는 것은 아니다.
Git 활용
로컬 레포지토리를 수정하는 동안 리모트 레포지토리에 변화가 생겼다면 바로 git push를 할 수 없다.
-> git pull -> merge conflict (생기면 저번에 컨플릭트 해결 했던 것처럼 수정 후 add, commit)
git fetch
브랜치를 가져오는데 merge는 하지 않고 가져오는 단계까지만 하는 커맨드
한번 더 검토가 필요할 때 사용
로컬 레포지토리에서 현재 HEAD가 가리키는 브랜치의 업스트림(upstream) 브랜치로부터 최신 커밋들을 가져옴(가져오기만 한다는 점에서, 가져와서 머지까지 하는 git pull과는 차이가 있음)
git blame
특정 코드를 누가 작성했는지 찾아내기 위한 커맨드
코드가 어떤 커밋을 통해 탄생했는지 알 수 있음
특정 파일의 내용 한줄한줄이 어떤 커밋에 의해 생긴 것인지 출력
git show->누가 이 커밋을 했는지 나옴
이미 Remote Repository에 올라간 커밋을 취소하고 싶을 때
특정 커밋에서 이루어진 작업을 되돌리는(취소하는) 커밋을 새로 생성
git revert [되돌리고 싶은 커밋의 아이디]여러 커밋을 취소할 수도 있음
git revert 커밋아이디1..커밋 아이디2git reflog
git reset을 하고 최신 커밋으로 돌아오고 싶을 때
git reflog->HEAD가 갈이켰던 commit들의 id 확인
git reset -hard [최신 커밋 아이디]커밋 히스토리 보는 다양한 방법
현재 있는 브랜치의 히스토리 뿐만 아니라 다른 브랜치의 히스토리도 보려면
git log --pretty=oneline --all--graph
커밋 히스토리가 각 브랜치와의 관계가 잘 드러나도록 그래프 형식으로 출력
git log --pretty=oneline --all --graphgit rebase
커밋 히스토리를 깔끔하게 유지하고 싶을 때 사용
merge : 두 브랜치를 합쳤다는 정보가 커밋 히스토리에 꼭 남아야하는 경우
rebase : 커밋 히스토리를 깔끔하게 유지하는 게 더 중요한 경우
작업 내용 임시 저장
git stash
최근 커밋 이후로 작업했던 내용은 모두 스택에 옮겨지고 working directory 내부는 다시 최근 커밋의 상태로 초기화
어떤 브랜치에서 하던 작업을 아직 커밋하지 않았는데 다른 브랜치로 가야하는 상황에서 작업 중이던 내용을 잠깐 저장하고 싶을 때 사용
잘못된 브랜치에서 작업하고 있었을 때도 사용
git stash로 스택에 작업 내용을 저장
git stash list- 올바른 브랜치로 가서 다시
git stash apply [작업 내용의 아이디]를 한다. - 이미 적용한 작업 내용 삭제
git stash drop [작업 내용의 아이디]git cherry-pick
자신이 원하는 작업이 들어있는 커밋들만 가져와서 현재 브랜치에 추가
git cherry pick 아이디여러 커밋을 하나의 커밋으로 만들기
없애고 싶은 자잘한 커밋 이전으로 git reset을 한다.
git reset --soft 아이디gitignore 파일
working directory 내에 존재하는 파일들 중에서
마치 존재하지 않는 것처럼
Git이 인식해야할 파일들의 목록이 적힌 파일
-> Git이 ignore(무시)하는 파일들의 이름이 적혀있는 파일
그 플랫폼에서 실행될 프로그램을 만들거나,
해당 프로그래밍 언어로 코드를 작성할 때
(보통 자동으로) 생성되는 파일들
버전 관리를 할 정도의 가치가 없고,
오히려 버전 관리를 하면 용량만 더 차지하고,
나중에 각 버전을 살펴볼 때 가독성을 떨어뜨리기만 하기 때문에 Git이 무시하도록 설정
gitignore이 무시한다는 의미는 add, commit 등에서 무시한다는 의미
