깃허브 2
git status를 보면
untracked와 tracked 상태가 있다.
tracked는 한 번이라도 add 된 파일
untracked는 한 번도 add 되지 않은 파일이다.
git은 add한 파일만 commit한다.
git commit -a를 붙히면 자동으로 add와 commit을 해준다.
이 때 tracked file만 add 되고 untracked file은 add 되지 않는다.
.gitignore 파일을 통해 무시할 파일을 설정할 수 있다.
.gitignore에 등록하면 status에서 아예 보이지 않는다.
.gitignore은 어떤 파일을 무시할 지 결정하는 일종의 프로젝트 정책이다.
.git file 안에 exclude 폴더에 무시할 파일을 설정하면 프로젝트가 아닌 나만의 정책을 설정할 수 있다.
.gitignore: 깃허브에 업로드해서 다른 사람도 동일하게 설정
.git/exclude: 업로드하지 않고 나만 설정
일반적으로 config 파일은 .gitignore에 등록하지 않는다.
만약 config파일의 형식이 필요하다면?
config.json.template 처럼 뒤에 template를 붙혀 어떤 형식으로 써야할지 업로드한다.
git log --oneline : 한줄로 요약
git commit --amend -m "template 추가"
: 마지막 커밋 메세지를 변경한다.
이 때 commit id도 바뀐다.
git commit id는 commit의 변경사항, 시간, commit msg 등을 모두 포함한 hash값이다.
amend는 커밋을 수정하는 것이 아닌, 커밋과 연결고리를 끊고 새로운 커밋을 생성하는 것이다.
git reset vs revert vs checkout
git checkout COMMIT_ID
해당 commit id 시점으로 이동한다. (master는 그대로, HEAD는 해당 commit id로 이동)
git checkout master라고 하면 다시 되돌아온다.
master의 commit id를 입력해도 되지만
새로운 commit을 했을 때, HEAD가 master를 따라가지 않는다.
HEAD와 master가 분리된 상태를 detached라고 한다.
어떻게 master가 C를 가르키게 할 수 있을까?
이 때 reset을 사용한다.
checkout은 HEAD를 움직인다.
reset은 head가 가르키는 branch를 움직인다.
git reset --hard commit_ID
git checkout master
git reset --hard COMMIT_ID
head가 master를 가르키는 상태에서 reset을 하면 해당 commit으로 head와 master가 이동한다.
이때, commit id가 완전히 삭제되므로 reset은 신중해야한다.
reflog를 이용해 복원할 수 있긴 하다
git reflog
지금까지 이동했던 모든 기록이 남는다.
이것을 이용해 완전히 없어진 commit으로 이동할 수 있다.
commit id를 이용해도 되지만 HEAD@(4)와 같이 헤드 번호로 이동할 수도 있다.
immutability:불변성
이전에 작업했던 모든 기록이 남아있다. 수정할 떄는 기존 데이터를 복제한 후 수정한다.
HEAD: working directory가 어떤 버전과 같은가.
master: 해당 branch에서 가장 마지막으로 작업한 commit
checkout: HEAD를 움직인다.
reset: attached state(HEAD->master) 인 경우 branch가 움직인다 (master 이동)
dettached인 경우 checkout과 동일(head만 이동)
master는 branch의 이름이다.
git branch를 이용해 branch를 생성할 수 있다.
git tag
특정 commit에 tag를 추가할 수 있다. 이 태그로 checkout하면 커밋 id를 몰라도 해당 커밋으로 이동할 수 있다.
또는 reset을 할수도 있다.
git reset --hard TAG
git checkout TAG
git push --set-upstream origin master
로컬 저장소를 원격저장소의 어느 곳에 push할 지 정할 수 있다.
짧게 git push -u라고 할 수도 있다.
git branch -D BRANCH_NAME
해당 branch를 삭제할 수 있다.
origin master와
local의 master는 완전히 다른 저장소.
git pull을 하면 자동으로 git fetch와 git merge를 해준다.
git fetch
git merge origin/master: 현재 HEAD와 origin/master를 병합한다.
revert
conflict
나의 작업은 HEAD, 원격 저장소는 origin/master로 표시되고있다.
https://github.com/egoingsb/offline/wiki/git 설치.
충돌이 났을 때 어떤 change를 accept할 지 정할 수 있다.
accept 후 commit 하면 병합이 완료된다.
충돌이 적을경우 vscode에서 바로 수정이 가능하지만
많을 경우 git mergetool을 이용해 작업한다.
이 때 .orig 파일이 생성되는데, 이는 백업파일이므로 삭제해도 된다.
rebase
rebase와 merge는 복잡도가 같다.
rebase를 자주해주면 쉽다.
git commit을 안하고 amend하면 commit msg만 바꿀 수 있다.
commit 후 amend하면 커밋 내용도 바꿀 수 있다.
rebase 할 때는 merge를 하면 안된다.
따라서 pull도 하면 안된다.
rebase란?
merge없이 모든 작업이 순서대로 작업된 것처럼 보이게 하는 것.
부모 commit을 변경하는 방식으로 작동.
회사마다 rebase로 할지, merge로 할지 규칙이 있다.
merge든 rebase든 병합된 결과는 항상 같다.
git rebase origin/master: local master가 origin master 다음 작업으로 인식된다.
일반적인 분기
rebase를 이용해 하나로 통합
git rebase abort로 rebase를 취소하거나
git rebase continue로 재개할 수도 있다.
git push --force: 강제로 push
revert
revert를 하면 해당 커밋에 변경되었던 내용만 취소할 수 있다.
v1
v2
v3
v4 의 커밋이 있고
revert v1을 하면
v2 v3 v4의 변경사항은 유지하고
v1의 변경사항만 취소된다.
단, v1에서 수정했던 사항을 v2,v3,v4에서 또 수정했다면 conflict 발생
pull request
feature/login에서 작업한 내용을 master에 병합하겠다라는 뜻
merge pull request: 원격 저장소에서 merge가 일어난다.
충돌 가능성이 있는 경우 pull request 페이지에서 충돌 여부를 알려준다.
