본문 바로가기
GIT

Git 정리

by 자바지기 2021. 10. 16.
반응형

git init : 현재 디렉터리를 Git이 관리하는 프로젝트 디렉터리로 설정하고 그 안에 레포지토리 (.git 디렉터리) 생성

처음으로 commit 하기 전에 깃에게 commit 한 사람 꼭 알려주기
git config user.name "이름"
git config user.email "이메일"

커밋하기 전에 git add 해야 함 
git add 파일 이름 (파일 이름에. 쓰면 바뀐 파일 모두 커밋)

git commit -m "커밋에 관한 내용"


git의 세 가지 작업 영역 
1. working directory: 작업을 하는 프로젝트 디렉터리
2. staging area: git add를 한 파일들이 존재하는 영역
3. repository: working directory 변경 이력들이 저장되어 있는 영역

 

현재 상태 파악하기
git status 

 

커맨드 사용법이 궁금할 때 
git help [알고 싶은 커맨드의 이름]  
또는 man git-[알고 싶은 커맨드의 이름]    -> 자세히 알아보기

 

파일 staging area에서 삭제
git reset [파일 이름]

로컬 레포지토리 내용 -> 리모트 레포지토리에 반영
git push  


리모트 레포지토리 내용 -> 로컬 레포지토리 내용
git pull  

 

깃허브 프로젝트의 레포지토리를 그대로 복제 
git clone "프로젝트 주소"   

 

로컬 레포지토리의 내용을 처음으로 리모트 레포지토리에 올릴 때 사용
git push -u origin master

 

커밋 히스토리 출력
git log  

 

커밋 히스토리 한 줄로 보여줌
git log --pretty=oneline 

 

바뀐 내용 보여줌
git show 커밋 아이디 

 

vim을 이용해서 복잡하고 긴 commit message도 가능
git commit  

vim을 이용할 때 커밋 메시지 작성 가이드라인
1. 커밋 메시지의 제목과 상세 설명 사이에는 한 줄을 비움
2. 커밋 메시지의 제목 뒤에 온점(.)을 붙이지 않음
3.  커밋 메시지의 제목의 첫 번째 알파벳은 대문자로 작성
4.  커밋 메시지의 제목은 명령조로 작성(Fix it / Fixed it / Fixes it     ->  Fix it)
5.  상세 내용에 왜 커밋을 했는지, 어떤 문제가 있었고, 적용한 해결책이 어떤 효과를 가지는지
6. 다른 사람들이 자신의 코드를 바로 이해할 수 있다고 가정하지 말고 최대한 친절하게 작성
7. 하나의 커밋에는 하나의 수정사항, 하나의 이슈(issue)를 해결한 내용만 남기기
    다양하게 수정을 하고 나서 하나의 커밋으로 남기는 것은 좋지 않다.
    하나의 커밋이 하나의 사실만을 갖고 있어야 나중에 이해하기 쉽다,  
8. 현재 프로젝트 디렉터리의 상태가 그 내부의 전체 코드를 실행했을 때  에러가 발생하지 않는 상태인 경우에만 커밋
나중에 동료 개발자가 특정 커밋의 코드로 실행했을 때 에러가 발생한다면 혼란 발생

 

최신 커밋 수정
git commit --amend   

 

log --pretty=oneline 가 기니까 history로 대신한다
git config alias.history 'log --pretty=oneline'    

 

두 커밋 간의 차이점을 확인
git diff (이전 commitId) (후의 commitId) 

HEAD: 가장 최근의 커밋을 가리킴

 

HEAD가 특정 커밋을 가리키도록 이동시킴

git reset 에는 --hard --mixed --hard라는 옵션 3가지가 있다

git reset[옵션] eea5 working staging  repository
--soft 안바뀜 안바뀜  HEAD가 eea5커밋 가리킴
--mixed 안바뀜 eea5커밋처럼 바뀜 HEAD가 eea5커밋 가리킴
--hard  eea5 커밋처럼 바뀜 eea5 커밋처럼 바뀜 HEAD가 eea5커밋 가리킴



HEAD^ -> 현재 HEAD의 이전 커밋을 가리킴
git reset --hard HEAD^

HEAD~2 -> 현재 HEAD가 가리키는 커밋보다 2단계 전에 있는 커밋
git reset --hard HEAD~2

태그 달고 싶을 때
git tag [태그 이름] [커밋 아이디]

태그 확인하기 
git tag

태그 보기 
git show [태그 이름]


branch

 

생성된 브랜치들 보여줌
git branch 

 

브랜치 생성 
git branch [branch 이름] 


해당 브랜치로 이동 
git checkout [branch 이름]

 

해당 브랜치 삭제
git branch -d [branch 이름] 

 

branch 생성 및 해당 branch로 이동
git checkout -b [branch 이름] 

헤드가 가리키던 커밋에 다른 브랜치가 가리키던 커밋을 합쳐서 새로운 커밋을 만드는 작업
merge 

 

현재 위치 branch에 master branch에 있는 내용을 합침
git merge master 

merge과정 중 conflict 생길 수 있다.
conflict 해결방법 : 
1. 컨플릭트가 발생한 파일을 연다, 
2. 머지의 결과가 되었으면 하는 모습대로 코드를 수정, 커밋 
또는
git merge --abort을 한다 (merge 취소 )

 

특정 커밋에 태그를 붙임
git tag [태그 이름] [커밋 아이디]

새로운 branch에서 commit 하기

git push -u origin (새로운 branch이름) 

 

HEAD가 commit을 직접 가리키게 하기
git checkout (commitID)
-> 과거 특정 커밋에서 새로운 브랜치를 만들고 싶을 때 사용
-> 새로운 브랜치 만들고 checkout 새로운 브랜치 하면 HEAD가 새로운 브랜치 가리킴


git push 하기 전에 git pull 해봐야 함 그러고 merge conflict 나온 부분 수정 후 다시 git push 해야 함

새로운 커밋을 만들지 않는 merge도 있다. 
fast-forward merge

3-way merge
base에서 갈라진 master branch와 premium branch가 있다고 하자
premium branch에서 master branch를 merge 작업하면 결과는 다음과 같다.

경우  base  master  premium  머지 결과
case1  A A B B
case2  1 2 1 2
case3  "hello" (공백) "hello" (공백)
case4  "bye" "fighting" "please" Conflict 발생!


3-way merge는 base에서 변화가 발생한 것을 우선 채택한다.


협업하기


git pull -> git fetch + merge

리모트 레포지토리에 있는 브랜치의 내용을 일단 가져와서 살펴본 후에 머지하고 싶을 때 사용 (점검용)
git fetch 

 

차이점 확인하기
git diff (현재 브랜치) (리모트 레포지토리 브랜치)
ex) git diff master origin/master


git merge (리모트 레포지토리 브랜치)를 하고 틀린 부분 고치기 

누가 썼는지 보려면?
git blame (파일 이름)
git show (커밋 아이디)

push 까지 한 거 되돌리고 싶을 때
git revert (되돌리고 싶은 커밋 아이디) 

->특정 커밋에서 이루어진 작업을 되돌리는 커밋을 새로 생성

여러 커밋 취소하기
git revert ([삭제하고픈 커밋의 이전 - 1 커밋 id].. [삭제하고 싶은 커밋들 중 맨 뒤 커밋 id]) 

commit 보기 (ref erence log)
git reflog  

->헤드가 이때까지 가리켜왔던 커밋들을 기록한 정보

커밋 히스토리가 각 브랜치와의 관계가 잘 드러나도록 그래프 형식으로 출력
git log --pretty=oneline --all --graph

 

새로운 커밋을 만들지 않고 커밋 히스토리를 깔끔하게
git rebase 


git rebase 진행 후 confilct가 발생했다면 conflict 해결 후 git add 후 git rebase --continue


merge와 rebase 차이 
1. rebase는 새로운 커밋을 만들지 않는다.
2. rebase로 만들어진 커밋 히스토리는 merge로 만들어진 커밋 히스토리보다 좀 더 깔끔
그러나 결과물은 같음

working directory에서 작업하던 내용을 깃이 따로 보관
git stash  

-> working directory 내부는 다시 최근 커밋 상태로 초기화

 

저장된 것 확인할 수 있음
git stash list 

 

저장된 것 다시 가져옴
git stash apply 
git stash apply stash@{번호} 

 

저장된 것 지움
git stash drop (stashID)

 
git stash pop   -> git stash apply + drop

 

특정 커밋만 내 브랜치에 가져와서 반영하고 싶을 때
git cherry-pick (가져오고 싶은 커밋 ID) 

커밋을 없애고 싶다? 
git reset --soft (없애고 싶은 거 전 커밋)
git add .
git commit -m (커밋 메시지)
==> working directory는 살아있으므로

반응형

'GIT' 카테고리의 다른 글

Git 원격 저장소 옮기기  (0) 2021.12.10

댓글